Robocar: Unmanned Ground Robotics
The Association for Unmanned Vehicle Systems International (AUVSI) sponsors a yearly robotic vehicle contest. Schools from around the world gather to see whose vehicle will navigate an outdoor course the fastest and the farthest. Vehicles have no prior knowledge of the layout of the course.
The course track is defined by white or yellow lines painted on the grass, and the robot must stay within these lines. Obstacles of various sizes, sand traps, deep grades and sharp curves occur along the way to keep things exciting. The difficulty increases as the robot progresses down the course. In addition to navigating the pathways, the robot must carry a 20 pound load and cannot exceed a speed limit of five miles per hour. Each robot has three tries at navigating the course, and the winner is chosen based on the time used and distance traveled. Penalties are assessed for crossing lines and hitting obstacles. So far no team has successfully navigated the full length of the course.
This year's contest was held at Oakland University in Rochester, Michigan on May 31st, June 1st and June 2nd. Rules for the 1997 contest can be found on the Web at http://www.secs.oakland.edu/SECS_prof_orgs/PROF_AUVSI/rules97.html.
Figure 1. Diagram of the Race Course
Robocar is the University of Colorado (CU) at Boulder's entry in this contest. Starting with a child's electric car, our team added basic sensing and control equipment as well as two computers running Linux and software specifically designed for the AUVSI contest. Over the four years CU has entered this contest, Robocar has changed significantly. This article documents the various systems of Robocar in this year's incarnation, its software architecture and navigation algorithms.
The basic frame of Robocar is a kid's vehicle, hacked apart—the kind of toy one or two children can sit in and drive. We ripped out the wimpy motors that came with the original toy and replaced them with big, beefy ones with chains and gearing to improve drive power. We substituted computer controls for the steering wheel and pedals and augmented its body structure. Not much remains of the original vehicle except some framework and the outer plastic shell.
An inverted metal “U” was welded to the car body above the former location of the windshield and two cameras were mounted to it. The original windshield was not used because it was too low to the ground and did not provide a large enough field of view. A metal box used for housing various circuits is also attached to the metal “U”.
Batteries fit snugly into the former seating area of the vehicle. Covering the batteries is a wooden board which holds the competition load. Likewise, a wooden platform has been added to the back of the car to carry our main computer, a conventional desktop machine with a big monitor. Additional equipment, including our smaller second computer, is stashed under the hood in place of the original battery.
Overall, the car measures 30 inches wide, 54 inches long and 62 inches high and weighs in excess of 200 pounds. Actually, the car's body has become a huge, heavy hack after three years of adding features. We'll probably rebuild it from scratch next year using lighter materials.
Robocar must withstand a fair amount of stress while traveling across the bumpy course (grass, sand, simulated pavement, wooden ramps). Vibrations need to be dampened to get clean, useful video—try driving down the road while looking through a jiggling video camera some time, and you'll get a fair approximation of Robocar's vision of the world. Besides, we don't want the hard drives bouncing around all over the place; therefore, all four wheels have shocks to help reduce the vibrations, and our mechanically fragile equipment is mounted on foam.
Finally, we replaced the slippery, stiff plastic wheels that came with the car with inflatable rubber tires to improve traction on the grass and the ramps. Robocar plows right through sand traps on these tires. Running with the tires slightly deflated helps absorb shock.
Figure 2. Picture of Robocar practicing. At this time we were using wall power to conserve batteries and a joystick to manually select the motor power. It really is following the lines by itself though. Our practice lines are impossible to miss compared to the more subtle effects of spray paint on grass.
This year, Robocar has large marine batteries that can easily power it for seven or more hours of operation. The batteries are used in pairs and power all the actuators, sensors and computers. These are deep cycle batteries; that is, they are designed to withstand numerous complete draining and recharging cycles. Each 12 volt battery can source 550 amps. Even though each battery lasts a long time, we keep two spare sets on the sidelines for backup. Unfortunately, the batteries are quite heavy—adding an extra 40 pounds each. The weight trade-off is well worth the power gain, which should enable us to climb the ramp that caused us so much grief in previous years.
Figure 3. A close up of one of the shocks
We have two circuits in the car: a 12 volt circuit and a 24 volt circuit. Power for the noisy drive motors and CAN-AMP servo is provided on a separate circuit from the digital devices. Relays switch the drive motors from forward to reverse as well as cut power to the motors in emergencies. The diagram of the electrical system provides more information.
If Robocar should ever go wildly out of control, a quick slap on one of the two emergency stop buttons (one of which is a remote control) will quickly bring it to a halt by disconnecting the motors from the batteries. Even though the car is moving at a mere 5 miles an hour or less, it can still do a lot of damage to objects and people. I have scars to prove it.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- RSS Feeds
- Readers' Choice Awards
- Tech Tip: Really Simple HTTP Server with Python
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




2 hours 42 min ago
3 hours 14 min ago
5 hours 38 min ago
5 hours 41 min ago
5 hours 42 min ago
10 hours 7 min ago
11 hours 58 min ago
17 hours 11 min ago
20 hours 23 min ago
22 hours 38 min ago