Autonomous Vehicle - Part 4 - Mechanical, Firmware
04/09/10 16:49 Filed in: Autonomous
Vehicles
Synopsis: This is a
status update on the autonomous vehicle I’m
preparing for the Sparkfun AVC 2010 just two
weekends away (April 17 is race day.)
I’ve made a lot of progress on the vehicle’s firmware and also the mechanical side of things. Here’s the vehicle as it will look on race day:
Mechanical Progress
I have the vehicle package completely ready, wired, and buttoned down for race-day. I didn’t want to get to race day and still be trying to figure out good wire routing and tucking things in. I wanted a nice, clean package that was still easy to access, disassemble, replace batteries, etc.
Using the Team Associated 18R chassis discussed in Part 1, I cut some plexiglass in a slight wedge shape and used that as the mounting platform for the electronics. I drilled four holes in the plate for mounting on the four body standoffs on the chassis. These rest on adjustable cotter pins so the normal TA body can be fitted, but they worked perfectly for bracing the bottom side of the platform. The platform is held in place by the same long cotter pins that you would use to hold the standard R/C body down. This makes it easy to pull two pins and remove the entire electronic assembly in one unit so it could be reprogrammed or tweaked race-day.
The RAD-GPS board I designed which has the ATMega128 ET-AVR, FSA03 GPS, and XBee Pro 900 all on one board is screwed to the plexiglass with 1/4” standoffs and 4-40 screws. It’s bolted down nice and snug but still would be easy to remove if need be.
The XBee and processor are both socketed so they can be easily replaced if needed, also. Finally, I have a complete backup RAD-GPS board ready to go as well, firmware flashed and up to date. So, lets say the car careens completely out of control crashes into the curb, and cartwheels down the lane, I have another board I can replace and run again...I won’t be out of the comp.
I even have a spare TA 18R car I’ll be taking with me. Since I didn’t end up hacking or cutting any wires on the R/C car, just unplugged them from the 18R radio system and plug them into my adapter board, I can easily replace the entire mechanical platform.
Firmware Progress
Besides getting the Ragel-based GPS NMEA parser up and running on the ATMega128, I’ve written a command processor so I can send the car commands to pull diagnostic data from the processor and even load waypoints into the system dynamically all via the XBee wirelessly.
Currently, the command set for the vehicle’s firmware is:
Using a Sparkfun XBee regulated breakout board and an XBee Pro 900 on the Mac side I can use the OS X screen command to talk with the vehicle:
Once I’ve established contact local XBee radio I can do a quick $wake command and get back an “OK” from the vehicle to test to make sure I have comms.
Using the command console, I can load waypoints into the vehicle by using:
to set a latitude, longitude coordinate at index number 1. I have made space for up to 30 waypoints, but I don’t think I’ll be using anywhere near that many. We’ll see as testing gets further along.
Using a script, I can load any set of waypoints into the vehicle I would like.
To clear out a waypoint set, I can issue the command:
Alternatively, I can have the vehicle itself help set waypoints. I can pick up the vehicle, walk it to a waypoint on the course and then issue the command:
This will automatically record the current location into the waypoint array at the next index and increment the index. Using this techinique, I can walk the course and set waypoints along the course and they are stored as I go.
Later, I can dump the current waypoint set by issuing this command:
It will dump a list of waypoints and their completion status. After an autonomous mission starts, each time I get within the proper vicinity of a waypoint, I will mark it complete in the firmware. At the start of a mission, all waypoints will be incomplete and the listing of the waypoint set will look something like this:
Anytime I want to see the current location data and gps status, I can issue this command:
It will immediate respond with a JSON data structure that would be suitable for ready by a client application and looks like this:
This JSON location data structure is exactly what was presented in the article “Porting a Ragel GPS NMEA Parser to the AVR ATmega128“ and shows it working in the context of a command interpreter.
I can manually control the vehicle by sending it commands $forward, $backward, $left, $right, $straight, and $stop. To start a mission, I can issue the command:
at which point the firmware will check a few things like whether there are any waypoints initialized and whether there’s a good 3D lock on the GPS before it will begin. If it can’t get a good lock, it won’t start the mission and immediately abort.
Once the mission has started the only commands the firmware will respond to are within the rules of the Sparkfun AVC 2010 - basically monitoring. It will respond to status commands like $location and, of course $kill.
The $kill command does as it sounds - it instantly aborts the mission, turns off the car’s motor, and waits for the next command. After the mission has been killed, the firmware goes into a manual mode. There’s no way to resume a mission without starting over.
Navigation Software Status
I have all the atomic control functions working including waypoint management and monitoring, so the next major bits of functionality are the actual autonomous navigation. Given a waypoint, it must navigate to it. This could well be the most difficult portion of the project, I don’t know yet, but I have the foundation in place to be able to quickly debug issues and monitor what’s going on. As much as I’ve wanted to just hardwire some navigation code into it, I felt it would be quicker to work through the autonomous issues if I had a good base in place for monitoring and tweaking.
Remote UI
In the next article I will cover the remote user interface for monitoring and communicating with the autonomous vehicle. I’ve got some cool stuff brewing that I think you’ll like.
Landon Cox
www.ESawdust.com
Other articles in this series:
Building Bots with Kids
Autonomous R/C Car - Part 1 - Reverse Engineering Signals
Autonomous R/C Car - Part 2 - Taking Control
Autonomous R/C Car - Part 3 - GPS
Autonomous Vehicle - Part 5 - Race Day
I’ve made a lot of progress on the vehicle’s firmware and also the mechanical side of things. Here’s the vehicle as it will look on race day:
Mechanical Progress
I have the vehicle package completely ready, wired, and buttoned down for race-day. I didn’t want to get to race day and still be trying to figure out good wire routing and tucking things in. I wanted a nice, clean package that was still easy to access, disassemble, replace batteries, etc.
Using the Team Associated 18R chassis discussed in Part 1, I cut some plexiglass in a slight wedge shape and used that as the mounting platform for the electronics. I drilled four holes in the plate for mounting on the four body standoffs on the chassis. These rest on adjustable cotter pins so the normal TA body can be fitted, but they worked perfectly for bracing the bottom side of the platform. The platform is held in place by the same long cotter pins that you would use to hold the standard R/C body down. This makes it easy to pull two pins and remove the entire electronic assembly in one unit so it could be reprogrammed or tweaked race-day.
The RAD-GPS board I designed which has the ATMega128 ET-AVR, FSA03 GPS, and XBee Pro 900 all on one board is screwed to the plexiglass with 1/4” standoffs and 4-40 screws. It’s bolted down nice and snug but still would be easy to remove if need be.
The XBee and processor are both socketed so they can be easily replaced if needed, also. Finally, I have a complete backup RAD-GPS board ready to go as well, firmware flashed and up to date. So, lets say the car careens completely out of control crashes into the curb, and cartwheels down the lane, I have another board I can replace and run again...I won’t be out of the comp.
I even have a spare TA 18R car I’ll be taking with me. Since I didn’t end up hacking or cutting any wires on the R/C car, just unplugged them from the 18R radio system and plug them into my adapter board, I can easily replace the entire mechanical platform.
Firmware Progress
Besides getting the Ragel-based GPS NMEA parser up and running on the ATMega128, I’ve written a command processor so I can send the car commands to pull diagnostic data from the processor and even load waypoints into the system dynamically all via the XBee wirelessly.
Currently, the command set for the vehicle’s firmware is:
Using a Sparkfun XBee regulated breakout board and an XBee Pro 900 on the Mac side I can use the OS X screen command to talk with the vehicle:
Once I’ve established contact local XBee radio I can do a quick $wake command and get back an “OK” from the vehicle to test to make sure I have comms.
Using the command console, I can load waypoints into the vehicle by using:
to set a latitude, longitude coordinate at index number 1. I have made space for up to 30 waypoints, but I don’t think I’ll be using anywhere near that many. We’ll see as testing gets further along.
Using a script, I can load any set of waypoints into the vehicle I would like.
To clear out a waypoint set, I can issue the command:
Alternatively, I can have the vehicle itself help set waypoints. I can pick up the vehicle, walk it to a waypoint on the course and then issue the command:
This will automatically record the current location into the waypoint array at the next index and increment the index. Using this techinique, I can walk the course and set waypoints along the course and they are stored as I go.
Later, I can dump the current waypoint set by issuing this command:
It will dump a list of waypoints and their completion status. After an autonomous mission starts, each time I get within the proper vicinity of a waypoint, I will mark it complete in the firmware. At the start of a mission, all waypoints will be incomplete and the listing of the waypoint set will look something like this:
Anytime I want to see the current location data and gps status, I can issue this command:
It will immediate respond with a JSON data structure that would be suitable for ready by a client application and looks like this:
This JSON location data structure is exactly what was presented in the article “Porting a Ragel GPS NMEA Parser to the AVR ATmega128“ and shows it working in the context of a command interpreter.
I can manually control the vehicle by sending it commands $forward, $backward, $left, $right, $straight, and $stop. To start a mission, I can issue the command:
at which point the firmware will check a few things like whether there are any waypoints initialized and whether there’s a good 3D lock on the GPS before it will begin. If it can’t get a good lock, it won’t start the mission and immediately abort.
Once the mission has started the only commands the firmware will respond to are within the rules of the Sparkfun AVC 2010 - basically monitoring. It will respond to status commands like $location and, of course $kill.
The $kill command does as it sounds - it instantly aborts the mission, turns off the car’s motor, and waits for the next command. After the mission has been killed, the firmware goes into a manual mode. There’s no way to resume a mission without starting over.
Navigation Software Status
I have all the atomic control functions working including waypoint management and monitoring, so the next major bits of functionality are the actual autonomous navigation. Given a waypoint, it must navigate to it. This could well be the most difficult portion of the project, I don’t know yet, but I have the foundation in place to be able to quickly debug issues and monitor what’s going on. As much as I’ve wanted to just hardwire some navigation code into it, I felt it would be quicker to work through the autonomous issues if I had a good base in place for monitoring and tweaking.
Remote UI
In the next article I will cover the remote user interface for monitoring and communicating with the autonomous vehicle. I’ve got some cool stuff brewing that I think you’ll like.
Landon Cox
www.ESawdust.com
Other articles in this series:
Building Bots with Kids
Autonomous R/C Car - Part 1 - Reverse Engineering Signals
Autonomous R/C Car - Part 2 - Taking Control
Autonomous R/C Car - Part 3 - GPS
Autonomous Vehicle - Part 5 - Race Day
asdfasdf
