1. Room Mapping
with the
IntelliBrain2
Chris Miller

2. Overview
Goal
Program the Intellibrain2 robot to autonomously move around a room taking measurements
Why
Map areas without human interaction
Practice working with ground based, moving robotics
My goal was to turn this little robot into an autonomous room mapper. It was mostly just for personal practice and entertainment. I knew I wanted to do something with a robot and this was the first doable thing that popped into my head. Or at least I thought it was doable at the time.
I actually still think of it as doable but not with this piece of hardware. I'm actually even more interested in doing something like this now when I can get a new piece of hardware because I've noticed more things you'd need to take into account the further you take this project. I didn't even get to things like making sure it wouldnt throw itself down a set of stairs or making sure it knows when it gets stuck when something like a small rock gets in front of one or both of the wheels.

3. Intellibrain2 Java Programmable 2 Servos for movement
Parallax Ping Ultrasonic Range Finger (Radar)
Nubotics WheelWatcher
Photoresistors
The intellibrain2 is a learning robot made by ridgesoft. Its programmable in java and uses 2 continuous rotation servos for moving. It has the radar range finder. Which I thought was going to be the most difficult part of the project, but in order for that to be the problem I had to get that far. To keep track of rotation and forward movement I was planning on using the wheelwatcher, but it didn't have a connector I needed to put it on the robot so I worked with other sensors instead. Which actually turned out to be a positive thing.

4. Movement
This is the state diagram I started out with and kept while trying to get it to move right. When I started I thought the only problem here would be the Find Range state and I was going to deal with that later in the program. The real problem that pretty much ruined my project was the determine angle state, though the move to new spot also throws some error into the equation.

5. Determining the Angle Original Plan Wheel Watcher – 32 Stripes
Missing proper connections
Would have been too small regardless
Plan Used
Photoresistor and Holes in Wheel – 8 holes/16 Stripes
Less precise
Bigger area to handle jolts
Also Tried
Timed Version
So as I mentioned I originally wanted to use the wheelwatcher but was missing the connectors to put it on the robot. Because there were so many stripes there it would have been a lot more precise on a good robot but because of other issues it wouldnt have worked here.
What I ended up using instead was just the photoresistor sensors behind the wheels which would tell if the wheel was blocking or not blocking the light at that time and keep a count of how many times it had changed between them. Same exact idea as wheelwatcher but only has 16 states instead of 32.
I also tried a much simpler timed version where I'd just find the average angle turned each time and add it everytime but that didn't work in the slightest either.

6. Determining the Angle
So this is the basic math on trying to determine the angle. The little wheel actually has 8 holes instead of 4, but I suck with paint.
*READ FROM SLIDE AS NEEDED*
So as the wheel is turning the photoresistor is keeping a count of how many changes in the light. When the robot is spinning in place the counts go in opposite directions and when its going forward the counts go in the same direction which keeps the difference in the counts the same.
So anytime you can just take the high count and subtract the low count and multiply it by that magic number and you have the current angle.

7. The Problem Random Jolt/Twitch at end of turn cycle
Problem in API or microcontroller
Can be in either direction
Unmeasurable
*Ruins the Counter*
So the thing that completely and utterly ruined my project was the this. The robot just suddenly … twitchs/jolts/whatever … at the end of a movement cycle. I thought at first that this was a problem with the servos and spent a couple hours taking apart the servos and making sure there wasn't a problem in there. When I couldn't find anything wrong with the servos I replaced it with another I had stripped from a different robot, but the problem persisted. At that point I decided it had to be an issue with the microcontroller or the API, so I started trying to deal with it in the software. The problem with that is that its not consistent. It might do it 100 times in a row or once in 50 turns. It goes backwords about 95% of the time or more, but once and awhile it jumps forward meaning if I were to add the photoresistor count like it was always backword, when it does go forward it would change the angle by 15+ degrees. This is why the photoresistor method turned out to be better since the jolts don't change the state as often as they would with the wheelwatcher.

8. Decent
So this is just a little screenshot of the plotting thing I wrote out, which I was going to use on the new part of the project. It currently just takes the points and 8 angles/distances from each point and plots em out
This is a quick run where it did an initial measurement at the start point, moved once, and did another set of measurements. This was just in a rectangular hallway to keep things simple while I tried to make it work.
*SHOW HOW IT ACTUALLY RESEMBLES THE RECTANGLE*

9. Bad
This was the very next run with NO changes made to my code. As you can see this time the 1's are all a decent amount lower on the Y axis which means the second red dot there probably was in reality near the X axis, but the counter didnt work as well this time. And this was only after ONE movement.

10. Worse
This is the same run as the previous slide with 1 more iteration. In reality the robot was somewhere much further to the right and facing an angle that was at least 45 degrees off from the angle determined by the counters.
Because of these inconsistencies I just couldn't get this thing to work.

11. The Rest of the Project
Supposed to take the previous images and take out the bad data.
Once you have proper walls its extremely easy to build a model of it.
So the part of my project that I thought would be most difficult (the trimming out of the bad numbers) I never even got to. I didn't really see the point of writing code for bad numbers because thered be no way to check them.
The basic Idea would have been to take these top 3 0's for example and drop the 2 outside ones because the radar was measuring the distance to the wall at an angle instead of straight ahead so the one in the middle would be closest to the actual distance.
Once I had determined walls I would have made it into little 3d model like the maze in graphics but once again I didnt get even close to that. And though it would have been the most obvious way of showing I actually got it to work it would have also been the easiest thing to do.