Ivalde, A exploration robot Options

[Leon]

As a kick off for a larger project me and my course mates spent a few days with NXT. The goal was to make a robot that was capable of exploring and mapping an unknown area and this is what we achieved.

The robots (prototype and final)


The area to explore


Screenshot of the program

The robot to the left is our prototype, Ivalde Rev B, while the one to the right, Ivalde Rev L, is the final version that we used to generate the map (there's a story to the names, but due to unaccountable reasons we can't tell it ;)). In the beginning we were hoping to use two robots collaborating to explore the area but in the end we didn't have the time.
The robot is controlled by the program through bluetooth, everything is done on the host computer and nothing on the actual robot (we were experimenting with RobotC in the beginning but we had some problems with getting nxt-pc bluethooth communication working so when we found mindsqualls we went entirely server side). The program was written in C# using the mindsqualls.net libs for communication (in the screenshot it was run on Windows XP with a Mac shell, which is why it looks like a Mac program).
The map in the screenshot was made by manual operation of the robot (by simply clicking on the map, it's also possible to move by using the go to button but that's much more cumbersome and mostly for debugging).
The plan was for the robot to be completely autonomous but we didn't have the time to finish the ai based on frontier exploration before we had to move on. There is an ai, runable by pressing the iThink button, but it's not very smart, it tends to visit the same area several times and can manage to paint itself into a corner.
For navigation we're using dead reckoning and as can be seen on the pictures the scanning is done with the ultra sound sensor that rotates 360 degrees in order to do a scan. The reason for the rounded walls is that the US sensor doesn't handle scanning walls that's not perpendicular to it very well (it reports those distances as much closer than they are, thus the rounded walls).

For more info see our website, there you'll find the entire source code, more pictures and a movie of the robot in action using the iThink ai.

[Andy C]

Nice robot that uses the turntable improvement suggested for the JennToo Radar. I hope to copy this project someday.

Is it possible to do all the work on the NXT?
Was the robot taking any reliable US readings while moving and turning?

[Mick]

Looks nice! I don't see much of a difference between the final and prototype. I noticed that the track is very twisty and could be hard for a robot to follow.

[Leon]

I guess most if not all of it could be done on the nxt (although it might be hard to get ai like fronteir exploration working on the nxt due to limited computer power), however we wanted the map on our pc and when we didn't manage nxt-pc bluetooth in RobotC we decided to go entirely server sided (we're not allowd to do this on our real robots, but the idea with the nxt was for us to get a feel for the task at hand and not to work around limits with nxt).
We didn't try gathering sensor data while moving the robot but it should work decently as long as you keep track of where you were when the data was gathered. The reason we went for a rotating sensor tower rather than rotating the robot was that it was much easier to get the tower to rotate exactly than it was to get the robot to do it (at leas in the begining before we added high gear to the wheels). Intrestingly enough we found that RobotC was far better at precission turning that mindsqualls (aka normal lego firmware), our navigation guy (that would be me) was rather anoyed by the switch for quite a while before the high geared wheel setup was made.
The main diffrence betwen the Rev B and Rev L is that L got a more stable wheel base and tower setup (Rev B had problems with the wire geting caught in something casusing the tower not to turn).
We didn't know how the test track would look like but we were told that we couldn't expect it to be too nice with straight angles and such, which is why we opted out of exploring strategies like wall folowing and such.

[Andy C]

I shot off an idea to mindsensors.com seeing if an untangler is possible. I wish that I knew how to look at your code.

Did you use some kind of mechanical guide to align the US turret? Or was that sensor angle triangulated after some scans?

Looking at rev L, would the sensor tilt affect readings?

[Leon]

If you're on windows you can use Visual Studio Express Ediditon, it's the free version of Microsoft's development enviorment. If you're not using windows might be able to run it on Linux (maybe even Mac?) with Mono, although we haven't tested that.
We keep track of the sensor angle with dead reckoning (using the tacho meter in the egine), due to the high gear any error will be rather small and since we alter betwen clockwise and counter clockwise turing we found that it mostly evens out (although if operated over a long period of time it is possible that the error would build up to significant levels).
The important thing about the sensor placement is that it's centered on the rotation center of the robot. If it's not then one would have to take the heading of the robot in consideration when doing a scan (the distance to an object would be larger when scaned with the robot in one heading than it would be if the robot rotated 180 degrees).