The Journey Robot

jBot in the woods

David P. Anderson and Mike Hamilton

An Autonomous Six Wheel Off-Road Robot with Differential All-Wheel Drive, All-Wheel Independent Suspension and Static/Dynamic Stability.




31 March 2008: DPRG Outdoor Robot Challenge
26 March 2007: jBot's Programming
27 July 2006: jBot's IMU Odometry
08 January 2006: "A Geocaching Robot"
12 August 2005: jBot's Build Log
This website was "slashdotted" on 01 August 2005
Journey Robot is featured in the O'Reilly book The Makers.



The Journey Robot is an outdoor robot designed to run offroad in unstructured environments. It was inspired by the DARPA Grand Challenge and built as a prototype vehicle for that competition, in collaboration with Ron Grant and Steve Rainwater of the Dallas Personal Robotics Group, Mike Hamilton, Mark Sims and myself.

jBot is a fully autonomous, self-guided, mobil robot, capable of navigating on its own to an arbitrary set of waypoints while avoiding obstacles along the way.

The concept for the robot was hashed out over the summer of 2004 in a series of RBNO meetings at the warehouse of the DPRG. The platform was designed by Mike during the fall and winter of 2004 and I built the vehicle in my home machine shop in the spring of 2005. jBot moved under its own power for the first time on April 9, 2005 (3.5M mpg),

The robot was designed to meet the twin requirements of off-road stability and zero turning radius. The present platform is a differentially steered 6-wheel vehicle, with all-wheel drive and all-wheel independent suspension. Power is provided by two Pittman 24 Volt DC gearhead motors and a 24 volt, 4 amp/hour NiMh battery pack. Total robot weight is about 20 lbs.

The robot's tires, wheels, and suspension were scavanged from a Traxxas E-MAXX 4-wheel-drive 1/10 scale R/C monster truck. These are very nicely engineered suspension and drive parts, with a full set of factory parts available, as well as lots of after-market components from various manufacturers. Mike designed a custom drive train to interface with the suspension parts, giving us an all-wheel-drive vehicle with zero turn radius and full independent suspension. The only aftermarket parts used were the addition of MIP CVD steel constant velocity joint drive shafts to replace the factory plastic parts, which were not able to handle the torque, and a set of aftermarket Road Rage tires.

MRM Board The robot's "brain" is a Motorola 68332 micro-controller running in one of Mark Castelluccio's Mini Robomind controller boards. The current suite of sensors includes quadrature shaft encoders on the motors, an array of four Polaroid (Senscomp) sonar transducers, a Microstrain 3-axis inertial measurement unit, and a Garmin Etrex GPS receiver. A pair of Devantech H-Bridge intelligent electronic speed controllers are used to drive the DC gearhead motors.

The robot's operating system and control and navigation software were developed and written by the author based on algorithms originally developed for the SR04 and the nBot robots.

The robot uses a small cooperative multi-tasking executive to run a set of behaviors. The behaviors are prioritized in a behavior-based or "subsumption" architecture. The powerful TPU subsystem of the Motorola 68332 provides interrupt-driven hardware interfaces for user I/O, motor drivers, quad encoders, PID speed controller, sonar array, and radio PWM decode for a remote emergency override. It also supplies four RS-232 communication channels for the control terminal, IMU, GPS, and an optional serial video camera.


jBot Robot
Here's a nice potrait of the assembled jBot chassis. It was taken by Dave Ellis on stage at the Dallas Science Place April 2005 DPRG monthly meeting. This was before the electronics and sensors were installed on the platform. Click on the image for a high-resolution version.




MPEG Videos of jBot in Action

The following videos feature the robot navigating to a set of waypoints using inertial navigation rather than GPS. They are in chronological order, oldest first, and, as sensors and capabilities were added to the basic platform, the robot gets "smarter" in the later, more recent videos.




Inertial Navigation

The wooden mast in the pictures below is a temporary addition while I test the inertial measurement unit. The IMU is the black box mounted on top of the mast. These videos test the inertial guidance algorithms in the absence of any other obstacle detection and avoidance sensors.


jBot Robot

Autonomous Pied Piper (9M mpg)
. I took the robot to a local park to test the new position/location software by having the robot autonomously drive around a 100 foot square, clockwise and counter clockwise, like the Borenstein UMBMark.


jBot Robot

IMU Odometry (15M mpg)
. 100 feet out and back. Note the skid marks in the dirt where the robot turns around. It had already returned to the same spot three consecutive times before I thought to turn on the video camera.


jBot Robot

Odometry over curbs (15M mpg)
. Using the white and red stripes painted on a parking lot as giant graph paper for testing the robot position error after climbing over a curb. And also after climbing over 2 curbs (6M mpg),



Navigation over Uneven Terrain

jBot Robot

Odometry over rough terrain (5M mpg)
. Short back and forth over broken ground, 20 feet.

jBot Robot

Odometry over more rough terrain (6M mpg)
. 100 feet out and back over broken ground.



Obstacle Detection and Path Planning

jBot Sonar Array
Sonar array


An array of 4 SensComp sonar detectors gives the robot total frontal coverage of about 60 degrees out to about 30 feet. These sensors drive multiple behaviors including obstacle avoidance, path planning, and perimeter following. In the following videos, the robot is navigating to a single waypoint and back, as before, with the addition of these behaviors.


jBot in the Garden

Navigating with Sonar and Odometry (12 Meg)
. Attempting to drive in a straight line to a point 100 feet away and return, repeatedly, as in the previous videos, but now through a garden on the campus at SMU, using the sonar array to avoid obstacles along the way. Here is a bigger version (24M mpeg) of the complete run. Note that on the last leg one of the sensors malfunctions (bad solder connection) and the robot appears to carefully home in on (and climb) a tree and two light poles. In these cases the "escape" behavior is triggered when the robot senses an approaching unstable angle of the platform base.

jBot perimeter following

Following a perimeter(6.2M)
The robot uses it's sonar array to follow the perimeter of part of the Law School complex at SMU.



Navigating Through the Woods

jBot in the woods

Navigating through the woods (10 Meg)
First of four legs of navigation through the woods at a tent-campsite on Garza-Little Elm Reservoir. The robot is seeking to a point 200 feet away through the woods, and then back to the starting place, which it repeats 4 times for a total exceeding 1600 feet, about 1/3 mile. Total accumulated error for the entire test was about 20 feet, rought 1.25% position error. For those with the bandwidth and patience, here (50 Meg) are all four legs of the complete test.

jBot Hat Trick

Here are two "hat trick" videos. In each, the robot is set to seek through the woods to a point 500 feet away and return to the starting point, which is marked with a straw hat. In the first hat trick video (19M mpg) the robot returns within about 5 feet of the hat. For the second hat trick video (21M mpg) the robot returns directly to, and runs over, the hat.



SteadyCam Videos

jBot on Steady Cam

I built one of these steadycam supports for my video camera and it works remarkably well for chasing jbot through the woods. Here are my first attempts at using it. steadycam 1 (20M mpg) is a trip through the woods to a point 500 feet away and back, using the steadycam to follow the robot. steadycam 2 (20M mpg) is a similar trip through the woods, but on this one I remembered to "drop the hat" so as to have a reference mark for the origin. Both trips are over 1000 feet with a total accumulated position error of about 5 feet (I think).

jBot on the steps

New Shoes: jBot has a new set of 7.5 inch IMEX "Rock Crawler" tires which give it a little more ground clearance and top speed. These tires don't do as well in deep grass as the others. But on concrete and gravel and curbs they are a nice improvement. Here is a video of jBot climbing the stairs (20M mpg) of Dallas Hall on the campus at SMU. Here is a low resolution stair-climbing video (5M mpg).

The video is a composite of two runs, one up the stairs and one down. There are a few frames missing where I kicked the camera near the top of the stairs (still getting used to the steadycam mount). The original frames are here (23M mpg) but they include a very annoying noise burst on the audio track, the reason for editing them out. I include them here at the suggestion of our friends on slashdot, who had some doubts. It also has a funnier ending.

jBot in the Colorado Rockies

jBot spent part of the 2005 summer in the Colorado Rocky Mountains, clearly the most challenging out-door terrain that the robot has encountered, and "Papa" had to bail it out of trouble more than a few times. Here are a couple of videos of the robot navigating through the forest, and along a forest service road.

jBot in the high countryjBot in the high country (9.3M mpg). The robot navigates over and around obstacles in the Colorado Rockies at about 11,000 feet elevation, to a way point 500 feet away, and back to the starting point (minus about 8 feet).



jBot climbs a hilljBot climbs a hill (11M mpg). The robot navigates up a steep hill over rocky terrain, and back down again.



jBot in Creede ColoradojBot in the high country (16M mpg). The robot navigates over and around obstacles in the Colorado Rockies to a way point 500 feet away, and back to the starting point (minus about 12 feet). Deus ex machina comes to the rescue when the robot flips over on it's back.



jBot in the Colorado RockiesjBot on the road (10M mpg). The robot navigates to the top of a steep forest service road and back down. The curious circling at the top of the road are a result, I think, of the camera man (cough cough) getting in the robot's way as it attempts to reach its waypoint.





Getting Unstuck

jBot getting unstuck

Unlike my other robots, the Journey Robot has no physical bumper that it can use for collision detection. A physical bumper is problematic given the design of the 6-wheel drive and independent suspension. Further, most objects that jBot collides with, it just climbs over. So the definition of a collision becomes more complex in an offroad environment.

Other common methods for detecting a collision include monitoring the motor current for excesses, or using some sort of accelerometer to deduce the platform's motion. Both of these approaches are difficult for an offroad vehicle which is subject to shocks and sudden large torque requirements in the normal course of its operation.

For jBot, the basic question is not if platform has had a collision, but rather whether the robot is stuck. This could happen, for example, if the robot is high-centered, has become entangled in brush or barbed wire, or has fallen into a crevice. The robot has a suite of behaviors for escaping from entrapment, but the first step is to know that it is trapped.

jBot getting loose jBot uses three different methods to detect states in which it must deploy its escape strategies. The first just monitors the wheels to be certain they are turning (at more-or-less the speed that is being requested). This is somewhat like monitoring the motor current and detects when the wheels are jammed and unable to turn. The second method uses the robot's angle sensors to know when the robot platform is approaching a dangerous angle, either too steep or canted too far left or right. It then uses the orientation angle and sonar array to attempt to choose the correct method of recovery. That method is illustrated in a couple of clips from the following video.

The third method seems to work very reliably in determining that the robot is trapped. It takes advantage of the fact the jBot tracks its movements with an inertial orientation sensor and also with more traditional wheel odometry . The robot compares the rate-of-change of the orientation angle calculated from the wheels to the rate-of-change of the orientation angle measured by the IMU. If they are very different, and continue to be different for several seconds, it signals that the robot is trapped.

This works because the robot, when trapped, is almost always trying to turn in order to escape, and because of the light wheel loading, the wheels usually slip and are not jammed. The amount of turn that the wheels measure and that the IMU measure are therefore very different, and the robot can know that it is stuck. Robots without a fancy IMU orienation sensor might apply this same technique with the addition of a single vertical rate gyroscope.


jBot getting unstuck
jBot getting unstuck (48M mpg)
. This video is a collection of clips of the robot detecting that it is trapped, and performing escape maneuvers. In each case, the robot detects that it is stuck using one or all of the three methods outlined above.

Here is a higher-res version of jBot getting unstuck (202M) mpg)

Here is a low-res mpg(16M) and windows media (5.6M wmv) version of the same video, and here is an even lower-res real media (4.8M rm) version.


Journey navigation and perimeter following.

I have been studying the problem of dealing with dead-end cul de sacs in route to a waypoint. In these cases, the navigation technique of the robot simply steering the shortest path toward the destination results in the robot being trapped in the cul de sac. The more generic difficulty is described in some robotic text books as the "concave vs. convex" maneuvering problem, sometimes also referred to as a navigation "singularity."

jBot in its current enlightenment attempts to solve this problem by switching between waypoint navigation mode and perimeter following mode. When it "determines" that it is in a cul de sac, it switches to a perimeter or wall-following mode, and continues in that mode until it "determines" that its path to the next waypoint is no longer blocked, at which time it returns to waypoint navigation mode.

As might be obvious, the big problem here is how the robot "determines" when to switch between the two modes. I am still working on this, but the current method is quite simple. The robot switches on wall-following when/if it finds itself heading directly away from the target waypoint. And it switches back to waypoint mode when/if it finds itself heading directly toward the target waypoing.

jBot at Texas Instruments Circum-navigating the TI building (31M mpg). This image shows an ariel view of the start and ending waypoints for an attempted half mile trek across the campus of the Engineering School at the University of North Texas. jBot is navigating to a single waypoint on the far side of the old TI building, and it starts the journey pointed directly into a dead-end cul de sac. The video has lables where the robot switches between waypoint navigation and wall-following modes.

Here's a higher-resolution (85M mpg) and here is a low-res windows media (16M wmv) version of the same video, and here is an even lower-res real media (9M rm) version.


jBot at SMU

Circum-navigating Dallas Hall (9.4M mpg). This ariel image is of the starting and ending waypoints for a journey of 2000 feet across the campus at SMU, including a detour around Dallas Hall. After initally thrashing around in the ground cover behind the building, jBot switches to wall-following mode and follows the perimeter around to the front, where it returns to waypoint navigation mode. Here is a low-res windows media (4.7M wmv) version of the same video, and here is an even lower-res real media (2.4M rm) version.




This site was "slashdotted" on 01 August 2005 at 9:08pm EDT.

At the height of the excitement our little two-headed web server smoothly sustained about 50,000 hits and 27 GB of data per hour. Comments on slashdot suggest that many readers thought jBot was an R/C car, controlled by a human, and were correspondingly unimpressed, although a few perceptive individuals seemed to appreciate the effort. The overall event lasted more than 40 hours, generating nearly a million hits and moving about 335 Gigabytes of data. Amazing.


My other robots



last update: 18 January 2012 dpa
(C) 2004-2011 David P. Anderson

Valid HTML 4.0 Transitional