Archive for October, 2010

Hardware road map

After my experience last year working on blizzards hardware design I’ve learned a lot. One of the most valuable lessons is that even if you build a robot with a lot of cool sensors on it they may not be used. This is simply because there is a difference between having the raw sensor data accessible and having usable processed data.

As a result, this year I will be writing code that goes along with all of the sensors and integrates their outputs into a simplified format for every one working on the navigation software to use. The sensors will mainly be used to allow for imputs of just the velocity and desired direction to be used by the navigation team.  rather then having to worry about how much a hill will slow them down or what their servo outputs will do they can focus on getting the robot to run. To do all this I plan to have quite a few more sensors than last year.

This is the list of sensors that every robot will have. They will also have LIDAR, cameras and inferred distance sensors, (but that’s more up to the sub-teams to decide).

3 axis gyroscope
3 axis accelerometer
3 axis magnetometer

Encoder wheel
DC generator tachometer

battery voltage sensors
battery current sensors

and possibly a Gps

My plan with these sensors is to find the orientation, velocity and distance our robots travel. Most of our robots will be using an Arduino (avr 328) microcontroller. I am using a Directional cosine matrix algorithm to find the robot’s orientation.

In brief this is how it will work. the gyroscope is the most important sensor in this setup. It measures the robot’s rotation, but it has a slight drift.  Thus, over time there will be an error of a few degrees per second. To compensate I measure the force of gravity and the magnetic field.

Unfortunately accelerometers don’t directly return the force of gravity.  The accelerometers’ output is complicated by the centripetal force and the forward acceleration. To calculate these forces I need a way to measure instantaneous velocity of the robot.  While encoders are good for measuring displacement, they aren’t the best to measure velocity. Yes, they work, but they have problems. for example they have problems finding zero velocity and calculated accurate acceleration. Therefor, I plan to measure the voltage produced by asmall motor produces that is mechanically linked to the drive train.  With the velocity I can use the z gyro value to counter the centripetal acceleration and I can derive the forward acceleration as well.

So far this does a good job countering the roll and pitch, but what about yaw?  The compass(magnetometer) is good for yaw, but needs to be corrected for pitch and roll.

With the data processed in this way I will be able to apply PID control to take simple commands from the navigation software. If this is implemented properly it could have it run down a straight road on its own with only initial commands.


Installing ROS on Gumstix Overo running Ubuntu 10.04

ROS logoSnowbots users ROS as the software platform for our robots. Since deciding to experiment with Gumstix to build smaller, nicer looking vehicles we have been looking for a way to run ROS on it so we do not have to modify any of our other code to make our robot work.

After figuring out how to install Ubuntu 10.04 on the Gumstix Overo, installing ROS became trivial. Ubuntu has all the required dependencies for ROS so all that was required was to compile ROS. Following the ROS Installing On Ubuntu from SVN instructions located here worked perfectly. This solution does work perfectly but it does require compiling the code natively which can be quite slow. It took nearly 2 hours to compile ROS itself. I was also able to get add-ons like OpenCV to work correctly as well, but compiling code for it was extremely slow. I have yet to performance testing

Now that ROS is installed, the only thing remaining to drive our robots with a Gumstix is to interface our hardware with the Gumstix.

Videos to come when we get everything working