Project240.net

Introduction

I entered the 2010 SparkFun Autonomous Vehicle Competition with my AutoDrift vehicle which is my drifting dynamics research platform. Admittedly, I entered with far more ambition than preparation, considering my entry failed to make it around more than 25% of the way around the building. Even so, the event was tremendously enjoyable, both for the notable effort of the competitors and the outstanding organization from the SparkFun staff.

This page is an overview of my vehicle platform, control design, and competition experience.

Drifting
Autocross
Photography
Contact Information

Contents

1 - Overview

2 - Vehicle Design

3 - Control Architecture

4 - Practice Runs

5 - Competition Runs

6 - Competitors

7 - SparkFun Staff

8 - Reflections & AVC 2011

1 - Competition Overview

The SparkFun Autonomous Vehicle Competition (AVC) challenges roboticists to design a vehicle that can circumnavigate SparkFun's Boulder, CO facility in record time. This year was the second-annual event and divided the entries into air and ground categories. My initial hope was to compete in the ground category with an autonomous drifter, but several hardware issues and insufficient preparation precluded any such awesomeness.

Although my vehicle did not place very well in the race, the competition helped motivate the development process. Like the Retro Encabulator, AutoDrift has reached a high level of development and will serve as an autonomous research vehicle of science. The following sections describe details of the vehicle and control law design along with some of the challenges of implementation in competition.



Testing obstacle avoidance steering response is a bit of a hand-waving exercise

Adjusting steering tie-rods to trim neutral steering response

2 - Vehicle Design

Vehicle Platform

AutoDrift refers to one of two vehicle used in developing an autonomous drifting vehicle. My initial ambition was to enter the AVC with a drifter, but given my magnetometer issues this year, the drifter will have to wait until next year. Each of the vehicles can be configured for grip or drift driving.

The initial vehicle I used in developing basic navigation is a Team Associated TC-4 4WD touring car. I had the vehicle running waypoints in December 2009, but left the development in favor of the Traxxas Slash 4x4 short-course truck. The truck has larger diameter wheels and better suspension travel, both factors in navigating SparkFun's gnarly parking lot.

A hardware platform is mounted between the front and lower shock towers for each vehicle, providing installation points for the instrumentation and sensors. The platform for the TC-4 is made of 1/8" G10 sheet and is a bit too flexible. The Slash platform is made of foam-sandwich carbon-fiber, which is wrapped in fiberglass to prevent delamination.

Instrumentation

The instrumentation hardware is powered by an STM32 high-density MCU which has 10 external analog-digital conversion ports, 8 servo PWM output channels, 2 serial ports, 1 I2C port, and 2 SPI ports. The board has an ST LIS344LH 3-axis accelerometer, an ST LY530ALH yaw-axis gyro, an ST LPR530AL pitch/roll gyro, and a Honeywell HMC5843 3-axis magnetometer.

The board communicates on one serial port using an XBee 100mW wireless modem and on the second serial port receives GPS NMEA data from a San Jose Navigation 5Hz GPS. I use two Maxbotix XL EZ-4 ultrasonic sensors, mounted on the Slash just behind and to each side of the front bumper. The ultrasonic sensors can pan between 0 degrees and + or - 50 degrees each using a servo mounted in the front bumper.

Ground Station

The ground station software consists of a Matlab GUI which is used to configure the system (enable R/C Tx control, reset magnetometer, enable datalogging), set the control loops (steering, throttle, level1, and level2), and plot telemetered data.



Setting up speed and guidance commands just before second run

SparkFun score board. Final result: 7th of 13.

Checking radio-link and open/closed-loop switching at start line

Robots lined up at mass start, ready for carnage

First off the line at the mass start means nothing if you crash into the first curb

Elmo, in a fury of road rage, takes out another competitor. Nate is called in to calm him down.

3 - Control Architecture

Cross-Track Waypoint Navigation

The basic element of the navigation design is the cross-track waypoint following, which sets the desired path as the line connecting the previous and next waypoint. This differs fundamentally from the more common approach of a waypoint-direct navigation, which guides the vehicle in the direction of the next waypoint irrespective of the vehicle position. Whereas the waypoint-direct method provides the shortest path to the waypoint, the cross-track approach constrains the path taken to a corridor and will guide the vehicle back to the desired path should it be displaced.

Cross-track navigation is a direct extension of waypoint-direct and uses a course- correction term to achieve the line following. The desired heading is set to the bearing from the current vehicle position to the next waypoint plus a heading correction toward the cross track. If the vehicle is navigating along the track, the heading correction is obviously zero and desired heading is set directly toward the waypoint. As the vehicle deviates from the desired path, the heading correction is computed as the inverse tangent cross track distance error scaled both by a gain and by the ratio of the cross track distance error to the waypoint distance.

When the vehicle is far from the waypoint (waypoint distance >> cross track error), the inverse tangent provides a softened heading correction in response to cross track errors. For instance, a small error of 5 feet off course generates only a few degrees of heading correction, whereas a large error of 50 feet generates nearly 90 degrees of correction. For large errors, the desired heading is directly toward the track, rather than toward the waypoint.

In the case of the SparkFun competition, the cross-track method seemed to be a better approach given the narrowness of the parking lot course, particularly along the east side. I had some concern that an overshot turn could lead to navigation into a curb or the pond using waypoint-direct, but using cross-track would force the vehicle to compensate for the overshoot and return to the line connecting waypoints.

The proximity of the course to the relatively-tall SparkFun building meant that GPS shadowing could be a factor in the accuracy of the position fix. On the west side of the building, satellites low in the eastern sky are occluded, giving the vehicle access to half of a hemisphere of sky. Each side of the building causes satellite blocking in a different quadrant. The building corners permit access to 75% of the sky, blocking only one corner. Given this shadowing, my approach was then to set a waypoint from the GPS output at each corner and each midpoint of the building. Such an arrangement of waypoint accounts for all combinations of GPS shadowing - and conceivably the vehicle could transition gracefully between different groups of satellites while moving around the building.

Heading and Yaw Rate Tracking

Heading commands from the navigation outer-loop drive the heading and yaw rate tracking inner loops. The heading error (desired - measured) is scaled by the K_rc_psi gain to generate a yaw rate command. This yaw rate command is then limited by a kinematic filter which only allows rates that result in a lateral acceleration less than 1.5G. As the vehicle speed increases, the maximum allowable yaw rate decreases. The resulting yaw rate error is scaled by gain K_ds_r (itself scheduled on speed) and generates the desired steering servo command.

Speed Control

Speed tracking is achieved using a simple, single-gain reference tracking controller with GPS velocity used as a speed measurement. The commanded speed varies between the maximum setpoint, used between waypoints, and the minimum setpoints, used during turns. The commanded speed varies smoothly between the two setpoints in response to distance from waypoint and heading error. In the former case, the commanded speed begins to decrease from the maximum setpoint as the vehicle closes within a set distance threshold from the waypoint. The desired speed continues to decrease linearly with distance to waypoint and reaches the minimum speed at the waypoint.

Throttle command to the electronic speed controller is computed by scaling the speed error (desired - measured) by gain K_dt_V. For positive errors, where the desired speed exceeds the measured speed, the throttle is positive and the torque to the wheels is in the driving direction. During reductions in speed command on approach to waypoints, the speed error can become negative as the desired speed decreases below the measured speed. In such instances, the vehicle commands negative throttle, which is used for both braking and reverse. A 1-second limit on negative throttle is set to ensure that only braking is engaged. Beyond this limit, the minimum allowable throttle is 0 (neutral), which causes the vehicle to slow by coasting.

Desired speed is also reduced for large heading errors, preventing the vehicle from moving quickly in any direction except toward the waypoint along the desired cross-track. Two heading angle error thresholds, inner and outer, control the behavior of this speed reduction. For absolute heading errors less than the inner limit, the speed is set to the maximum value, since the vehicle is presumably heading in the desired direction. Between the limits, the speed command scales linearly with heading error between the maximum speed at the inner limit to the minimum speed at the outer limit. The speed command remains fixed at the minimum value for absolute heading errors greater than the outer limit.

In practice, the speed limiting appears to work well and provides a logical variation of speed throughout the course. As the vehicle approaches a waypoint, the controller brakes briefly, coasts until the waypoint is reached, then turns at the minimum speed to intercept the cross-track to the next waypoint. The speed limit on heading error applies to the combined bearing to waypoint plus cross track correction, which allows the vehicle to travel at the maximum speed when intercepting the cross track.

Obstacle Avoidance

Obstacle avoidance is the least developed of my controllers, as evidenced by my vehicle's tendency to crash into curbs. My initial goal was to use dual scanning ultrasonic sensors to build a simple model of the external environment and command the steering based on the distribution of passable and unpassable zones. I ran with simplified version of this, which uses two fixed ultrasonic sensors to detect objects slightly left and right of the vehicle centerline. A detection of any object within the defined threshold disables navigation and engages obstacle avoidance mode, which commands a steering angle equal to the scaled difference between the left and right sensor measurements.

Approaching a curb to the right of the vehicle would cause the right sensor to detect an obstacle while the left sensor detects nothing. The steering command would then be a left turn, which steers the vehicle away from the obstacle.

Obstacle detection also causes a reduction in throttle in proportion to the obstacle distance. The throttle command is computed simply as the obstacle distance multiplied by a gain, so the vehicle does not enter braking (positive throttle values only) and the throttle does not correspond to any desired speed.



Testing the obstacle avoidance steering response against the wall of the Team Pits room

Unpowered 'glide' test toward a curb, checking for proper obstacle avoidance response

4 - Practice Runs

Open-Area Waypoint Navigation

I tested the final version of the cross-track navigation controller in the mall parking the night before we left LA for Boulder. I had setup two waypoint at either end of the parking lot and set the waypoint mode to repeat. I had previously tested the steering component of the navigation, but this was the first proper test of the speed reduction on waypoint approach and the speed reduction for large heading errors. The results were beautiful, as the vehicle rallied from one waypoint to the other with excellent consistency in track.

On one pass between the waypoints, I put a pine cone in the vehicle track just as it went by to test how close it would come on the following pass. The vehicle hit the waypoint, went to the second, and hit the pine cone directly as it passed me! I stayed in the area and watched the vehicle make repeated circuits with tracks coming within +/- 1 foot. Obviously I need to add obstacle avoidance, but this seemed like an excellent starting point.

SparkFun Practice Run

Late on Friday, April 16th, Tasneem and I went to the SparkFun building to practice running the course. It took a while to setup the vehicle, ground station, and set all the waypoints, but we were able to get one run at 10 knots about 80% of the way around the building. The vehicle headed toward the inside curb just short of the final turn due to a code error with the waypoint loop handling.

I found the error and corrected the waypoint loop behavior, compiled, and reflashed the STM32. My laptop kept warning me about low battery, so I hurried to set the all the command and control parameters to run the test. Once programmed, the vehicle would not need the laptop, so I just needed a few more seconds...

I set the lateral mode to cross-track navigation and was just about to set the longitudinal mode to speed tracking when the laptop screen faded to black! Denied! The default mode for level 1 and level 2 throttle controllers was Standby, which fixed the throttle at neutral. I could now only command steering and throttle manually, or have steering active with throttle fixed. I suppose I could have carried the vehicle around the building and observed the steering behavior, but I already got 80% of the way around, what's the worry? ... Right?



Vehicle caught on overhanging drainage cover, ending first run

No style points unfortunately for doing a 40-foot curb grind during my second run

AutoDrift attempts to mount the curb, children scream in horror.

High-speed weather-proofing for the rainy 3rd run

5 - Competition Runs

Run 1

By decree of Peter Dokter, I received the pole position honor and was first to run. Tasneem and I had just gone around the building and set 10 waypoints, one at each corner, midpoint, and two extra for the finish. I had lukewarm confidence in the navigation, given the limited success on the previous day, but I was not running obstacle avoidance so the vehicle would be sensitive to any GPS error which lead the vehicle into a curb.

Tasneem and I set the rally speed to 10 knots with the waypoint speed at 75% (7.5 knots). We set the lateral controller to cross-track navigation and the longitudinal controller to simple speed tracking. I used the third channel on the R/C transmitter to enter and exit closed-loop control mode, necessitating that I run along with the vehicle to prevent the receiver from exiting closed loop control due to a weak/noisy signal. I setup the truck 10 feet away from the starting line and set the initial waypoint to the first corner.

On engaging the controller, the truck accelerated relatively quickly and tracked straight to the first waypoint. It intercepted the first waypoint and made a nice 90 degree right turn to southbound along with east corridor. We previously found some variation in the waypoint setting in this area, and our hesitance to put a waypoint in the pond led the vehicle to bear right toward the building. It hit the curb before the midway point and scrapped along for some distance until it hit and caught on an overhanging drainage cover. I hit the kill switch (3rd channel on transmitter) and signaled to Peter that my first run was officially over.

Run 2

I spent much of the time between the first and second runs programming obstacle avoidance and testing the steering and throttle behavior, both inside the pit area and outside along the curb. Walking alongside the inside wall, the steering response seemed to be scaled well in that as I approached the wall the steering progressively increased until it reached the maximum steer angle at around 2 feet away. The throttle reduced from rally speed to zero as the vehicle approached from roughly 10 feet away to 2 feet.

I tested the obstacle avoidance by 'gliding' the vehicle toward a curb outside. With throttle disabled, I rolled the vehicle toward a low curb at several incident angles and observed correct avoidance behavior each time. To be sure, my rolling speeds were less than 10 knots, but at least the behavior was in the correct direction and seemed to be scaled correctly.

The second attempt went much like the first. We initially loaded the same 10 waypoints used for run 1 but walked to the first several points and reset them. I again set the desired rally speed to 10 knots with the waypoint speed to 7.5kts. The truck accelerated across the start/finish line, turned at the first waypoint, and again headed right toward the building-side curb. The SparkFun crew retracted the drainage cover, so my car was able to scrap along the curb for some distance before somehow climbing the curb and getting high-center stuck. I watched the wheels spin with futility for a few moments before hitting the kill switch and ending run 2, only marginally further than run 1.

Run 3

On the final competition run, I used the pre-programmed waypoints instead of setting waypoints manually. I reduced the speed setpoint to 8 knots and disabled obstacle avoidance. The vehicle behavior on launch was the usual acceleration, then a northbound divergence toward the picnic tables. The slight uphill caused the vehicle to slow considerably relative to level ground, as the 30% maximum throttle with the proportional-only speed tracker meant that the actual speed was far less than 8 knots. It appeared to reach a waypoint near the picnic table and entered a slow, terminal turn. The vehicle continued to make small circles near the picnic table, presumably because the combined slow speed and tight turn radius meant that GPS heading was never reliable enough to determine actual vehicle heading. I had disabled the magnetometer earlier due to calibration issues in the western quadrant - perhaps I should have scheduled magnetometer/GPS heading switch with ground speed to give heading data, even if coarse, at slow speeds.

Mass Start

The vehicle performance during the mass start was a repeat of run 3. I used the pre-programmed waypoints with a speed setpoint of 10 knots. The vehicle made a fake to the northeast and headed toward waypoint picnic table. I killed the controller and recovered manual control before the vehicle hit the curb. Subsequent attempts at encouraging the controller to take over - driving the vehicle in the correct direction and engaging navigation - failed to produce much more than hearty progress toward waypoint pond.

It was clear that my control system needed further refining, so I recovered the vehicle and powered down.



Owner running after SharcBot while driving with controller

Robo-Cooler needs some higher-traction tires

6 - Competitors

Competitor Sites and Blogs

Team HellHound also used a Traxxas Slash platform, but apparently suffered as many issues with last-minute code changes as I did.

Autonomous Tools was preparing to enter an autonomous riding lawnmower, but unfortunately did not make it due to ESC issues.

Geeknight came from Victoria, B.C. to compete and has some interesting thoughts on the relative difficulty of the Air and Ground categories.

Team Buzzcut perhaps was the only team whose name was inspired by matching father/son haircuts. Used a Team Losi rock crawler as a vehicle platform and was able to ride over most curbs with little effort.

BlueBot was definitely the darling of the competition, being the smallest and slowest of the robots. BlueBot earned the rookie award and had the distinction of being the only robot who maxed out the 5-minute time limit on each run. The organizers kept sending robots after him, although I'm not sure if there was any robot-carnage.

Team Tobor won the competition with his extremely well-behaved old-school Tamiya Grasshopper. Rumors of using an Extended Kalman Filter for position estimates were true... Well done on the filter and control tuning.

Summary and Photography Sites

SparkFun's AVC Recap with some discussion in the comments about ways to make next year even better.

SparkFun's Flickr Photo Pool currently has about 350 photos from 10 sources.

Circuits @ Home has some beautiful shots of the winning robots.

Ustream recorded the live video stream from the competition.



Pete Dokter waits while Tasneem and Mujahid set the control configuration prior to run 2

7 - SparkFun Staff

It's difficult to describe the AVC experience without dwelling a bit on Nate and his SparkFun team. At the risk of sounding like a fanboi, I *really*, *really* like SparkFun and have a lot of respect for what they are doing for the electronics hobbyist community. My sister spent some time talking to one of the employees (apologies, forgot his name...) who described how the open-source ideology which attracts so many geeks also limits the lifespan of their products. It takes a lot for a company to give so much.... so thanks.

Although Nate certainly did much for the competition, what really stands out is the efforts of people like Peter Dokter, the Team Pits staff, the tour guides, and the announcer. All of them were amazingly accommodating and helpful.

And then there was the band... Miles Per Gallon (Volt) were astonishingly brilliant in narrating the competition and providing a soundtrack to all the best moments of AVC 2010. I really wish I had recorded all the songs they made, listed in order of decreasing hilariousness:

1 - AutoCrusher (so hysterical, particularly for the last ad-libbed section)

2 - Death by Pine Tree

3 - SharcBot

4 - SparkFun (We work at a place)

5 - Tinker Bell



Tasneem, ever patient, waits to deploy for the run 3

Mujahid can't believe the next competition is a full year away...

8 - Reflections & AVC 2011

My failure to perform respectably in AVC 2010 was entirely caused by poor planning amidst overzealous ambition. I set out to demonstrate functionality unrelated to the essential mission and ended up spending large amounts of time on these tasks. A better approach would have been to practice the mission before April 17th - not in an open parking lot, but around a building with narrow corridors, curbs, and obstacles. Without having previously demonstrated a successful mission, it is hard to expect much more than what I achieved (25%) during the competition.

My strategy during the competition can also be faulted for being a bit overly ambitious. I set the speed command to 8-10 knots for each run, but the competition was won with a speed closer to 5 knots. It is difficult to say whether a lower speed would have helped, as it would have improved obstacle avoidance time although could have been a detriment to GPS heading accuracy.

Despite the poor competition performance, I'm very happy with my vehicle, interface, and control system. My excessively broad focus led to the development of a very generalized command and control architecture, which can be applied very easily to other vehicle configurations and other maneuver types. The relative maturity of the platform, given the last several months of development effort, means that I may be able to enjoy a summer filled with controls experiments. Look for progress on the automatic drifting and wheel balancing soon...

My team (myself, my wife, and my sister) are stoked about competing in SFE AVC 2011 and have already picked a team name and a vehicle configuration. I'll spend more time ensuring that my robot is capable of achieving the base mission before getting lost and buried with irrelevant features.

Disclaimer: Some Yaks were shaved in the making of this robot.



Contact: Mujahid Abdulrahim - mujahid [at] ufl [dot] edu