Mindboards

Being a big fan of Lego NXT robots, and Formula 1, I thought building line following robots that race at high
speed (relatively speaking), change lanes, and make pit stops would be a great project. It first turned into a great
challenge, then a MOC for BrickFair. The attached zip file contains my NXC program and text files with a description
of my race track. The file Kemmel_Read_Me_R02.txt gives more details of what is in the various files.

Videos of a high speed pass and pit stops are at and shown below
<http://www.youtube.com/watch?v=r8zh20PsiAI> - shows lane changing.
<http://www.youtube.com/watch?v=awrkmwdM1jc> - shows robot details.
<http://www.youtube.com/watch?v=H0g7U_GRUKc> - shows robots making pit stop.

For the robots, I started with the idea that I wanted a very stiff chassis to improve handling and thus improve line
following. Having 2 caster wheels at the rear resulted in a stiffer chassis and the sensors remaining vertical.
Combining ideas from several web sites and NXT books resulted in a working design. The robots use a color sensor
to read color markers on the track and a light sensor for line following.

I started with NXT-G, but this proved to be too slow, and couldn't handle all the choices at various points in the
program. Using NXC, I was able to write a multi-threaded program that executes fast enough. One thread monitors
the color sensor that reads the color markers on the track. This thread interprets the color marker, and writes an
action in a circular queue. The second thread thread monitors the light sensor, reads actions from the circular
queue (producer / consumer model), and controls the drive motors.

Although I'm very familiar with 'C' programming, and traditional (castle, space) Lego building, I'm a novice to NXT
robot building, so feedback is very welcome. One problem that I am still working on is wobble / over correction on
line following with the large wheel robot at high speed.

For anyone coming to BrickFair 2011, my 8 ft x 23 ft racetrack will be open to all registrants' robots for several hours each day.







Howard - TabbyCat Robots

I'd like to make a couple of suggestions for things that you could try in order to improve speed and performance.

I would mount the color sensor on a "sweep" motor that could rapidly scan the black line and look for color markings without having to move the whole car back and forth. This would give you a higher update rate which would allow you to drive faster and smoother.

I'd also try making a "real" car with a differential rear end and car style steering in front. This would not only look better, but could be easier to control since it would separate speed control from steering.

You should also make use of either the url or even better, the youtube tags to make it easier to look at your films. If you look up "stonehenge" on this forum, you can find an example of this. The film also shows just how fast and accurate the color sensor can be even with a lot of outside light.

Thanks for your post. I'm looking forward to seeing more.

I guess what rghansen means is this:

Here's how we did it a couple years ago. For us, the key was the gradient track, where robots could pick a different lane, by changing the shade they were trying to find.

http://www.youtube.com/watch?v=jRpx1FgTR7I




Steve

Thanks for the suggestions. I've edited and embedded the YouTube videos in my original post.

Regarding the robot moving back and forth, this is not to read the color markers, but at high speed, my line
following is not good enough. I still working on whether this is in my algorithm, my parameters for steering
correction, or if the NXT is just not fast enough when executing multiple tasks, and large diameter tires at high
speed are covering a lot of distance. Any thoughts on this are appreciated. I've read mention of custom firmware,
where task priority can be adjusted, but haven't tried it, and would prefer to use standard firmware. Has
anyone done any timing tests with the custom firmware regarding task switching times, i.e. is the extra
time given to one task lost to extra task switching time in custom firmware?

Regarding reading the color markers, after experimenting with various shades of tape and paint, marker length,
and red/yellow compensation, the robots aren't having problems with reading color markers.

Regarding building a rear wheel drive, front wheel steering race car, this is on my "gotta build" list after 2 other
projects. I'm expecting to "learn a lot about" ("have a lot of fun") building a differential and steering
mechanism. Initially, I didn't think a front wheel steering vehicle would not give tight enough turning for
what I wanted to do. But, I now think it is worth a try and it would result in a much better looking car.

Howard - TabbyCat Robots

hassenplug wrote:Here's how we did it a couple years ago. For us, the key was the gradient track.

how do you make a gradient track like that one?

An artistic mind, a steady hand, and a can of spray paint.

themindstormman wrote:how do you make a gradient track like that one?

That's the really tough part. It was done on a very large printer.

Steve

tabbycatrobots wrote:
I still working on whether this is in my algorithm, my parameters for steering
correction, or if the NXT is just not fast enough when executing multiple tasks, and large diameter tires at high
speed are covering a lot of distance. Any thoughts on this are appreciated. I've read mention of custom firmware,
where task priority can be adjusted, but haven't tried it, and would prefer to use standard firmware.

Howard - TabbyCat Robots

Although the NXT is rather slow, it's more than fast enough for this task. From my experience, task switching time shouldn't be a problem even with the standard firmware. Have you tried measuring the speed of your software? This is actually rather easy to do and will give you great insights into how your program is really spending its time.

Attaching new zip file of my code and specs. This is the code that I ran at Brickfair 2011. Code contains
corrections and additions, and the spec files are more complete.