GPS

Originally, the EB-85A (now the MV-M8) was the popular choice. Particularly useful was the 115,200 bps serial transfer rate and the feature that allowed settings to be saved to flash. On the down side, the Speed Over Ground (SOG) and Course Over Ground (COG) did not update at speeds less than 7 knots. In order to use COG, SOG had to be checked to determine if the COG was valid. It was anticipated that the robot would not be traveling over 7 knots much of the time.

The EB-85A was replaced with an EM-406A that seemed to work better. With either GPS it appears that performance is increased if the GPS unit is mounted on the carbon fiber chassis plate instead of the perforated circuit board. I do not have a good theory for this and am still experimenting in this area.

The ARCTAN function is particularly difficult for microcontrollers to calculate. After several attempts, a crude approximation technique was used. The results of the calculation appear to be within 2 degrees, do not use up a full cog, but take about 7 msec to run.

Servos

Originally the servos were connected to the Propeller with Optical Isolators. Experiments indicated that the optical isolators were not needed. Now, just a 4.7 K ohm resistor is used between the Propeller pin and the servo signal line. No problems have been encountered with this arrangement.

The original Traxxas 2056 servos were replaced with Traxxas 2075 digital servos (Ebay) so that the pulse rate could be varied between 20 msec and 40 msec without impacting servo performance.

For the rear steer, a Futaba S9351 digital servo was chosen for its high torque and compatibility with the Traxxas servo horns.

Resources

All of the cogs are being used. A spare cog would be available if the R/C receiver was not used. A second cog could be freed by using a slower uSD read/write function

The RCOut Cog uses about 10 msec of the 20 msec between servo pulses. If the servo pulses are stretched to 40 msec, then a substantial amount of time is available to perform more functions.

The GPS NEMA Cog uses about 15 msec every second. Even with a much faster GPS update rate, there is still an enormous amount of time available for additional functions.

The program, written entirely in Spin, uses about 67% of the available RAM.

Although the program is fairly complex and probably rather inefficient, there is still substantial resources available on the Propeller for many more features.

Sonar

Three Maxbotix LV-EZ1 ultrasonic proximity sensors are used. The sensors are configured such that the Propeller triggers the first sensor, measures its pulse width output. Then the first sensor triggers the second sensor and the Propeller measures its pulse width output. Finally, the second sensor triggers the third sensor and its pulse width is measured. Only two pins are required. One pin is used to trigger the first sensor and a second pin is used to read in all three pulses.

The Propeller counts the pulse width using a factor that results in the final count being the distance to the detected object in decimeters. If the pulse width is longer that 70 decimeters distance, the counting is terminated and the sequence is reinitiated. This is done to prevent locking the cog.

The results of the sensors do not directly control the steering or speed of the robot. The results limit the maximum right or left turn and the maximum allowable speed. Using this technique, there is little interaction between the navigation functions and the obstacle avoidance functions.

Speed Control

The Traxxas EVX-2 electronic speed control was initially used. There were two major problems with this control. First, going from forward to reverse was not reliable. Sometimes reverse would run and sometimes brakes were applied. Second, when reducing speed, the robot coasted down to the new speed. Much more reliable control was definitely required.

Based on excellent experience with AX2550 and AX2850, a RoboteQ AX500 was tried. Unfortunately, the AX500 also allowed coasting during speed changes. Apparently, it is the only RoboteQ product that does.

Finally, a RoboteQ AX1500 was installed. That provided specs well in excess of anything that this robot would experience.

Satisfied with the AX1500, a polycarbonate housing was built to provide a little protection from moisture.

Pulse width was used to control the AX1500 because it required the least amount of microcontroller resources.

Compass

The first compass was a tilt compensated three axis digital unit from OceanServer. The PC software that came with the compass was very impressive. The serial output could easily be adjusted for rate and format. Even update rates and digital filter factors could be changed. It was all a lot of fun to play with.

Unfortunately, when transversing uneven ground, the sideways movement of the compass produced major heading changes. Lowering the compass in the chassis and playing with the filter parameters helped, but a straight course could not be obtained.

The PMI V2Xe was tried next. The major difference was that the V2Xe used a form of SPI communications. There were problems with the update rates and responses, as well as variable headings over uneven ground.

Finally, a Honeywell HMC6352 was used. At last there was reasonable directional control. This is not a tilt compensated compass. One big advantage is that there is an operating mode called the “Query Mode” that is very fast and allows compass updates every 20 msec.

It should be noted that there is a magnetic hazard at the Chibots RoboMagellan site. The present mast height of 22 inches is not sufficient to avoid the hazard.

Chassis

When the RoboMagellan project was started, Traxxas was just introducing the new E-Maxx 16.8V monster truck. One was ordered as soon as they were available from Tower Hobbies (December 17, 2007). It arrived December 19, 2007 and the fun began.

A .062 carbon fiber plate was added to the stock body mount posts and all of the electronics were mounted on a perforated circuit board on the plate. The front mount was later modified to allow the sonar sensors a clear view of the surface ahead.

Initial running indicated that the stock springs were not capable of handling the additional weight, so a local hobby shop provided the heaviest springs in stock. Additional spaces were added to level the chassis.

Initially, the turn circle was 75 inches diameter. This may be reasonable for an R/C truck, but not a robot. Rear steer was required. No kits were available to provide rear steer and the Traxxas people at the iHobby show said that it was easy to do, but didn’t plan to introduce a kit. So a simple aluminum block was added to the rear suspension to hold the third servo and the stock servo saver and tie rods. It took four tries before the correct dimensions for the block were obtained.

The front steering provides all of the control for the first 75% of the control range. The last 25% of the control range is all done with the rear steering. At speeds over 4 or 5 mph, all of the steering is done with the front steer.

Chassis weight is about 13 pounds.

Motor

A typical R/C truck is way too fast for RoboMagellan. So, initial modifications were concerned with reducing speed. One motor was removed and the smallest pinion (12 tooth) was installed before the robot was first run. The stock 68 tooth spur gear was retained.

Even with the reduced gear ratio, the speed was too high and had to be limited with the microcontroller. Also, low speed performance on hills in thick grass was a problem, so a lower gear ratio was needed. To that end, a two speed transmission was added with the low speed gear engaged. Finally, speed and torque were in a reasonable range. The two speed gear change uses a simple dog arrangement for engagement. That setup produced a lot of drive train slop, especially when changing directions. The gear shift parts were removed and gears were machined to provide no slop at the low gear ratio.

Also, at that time, the Traxxas encoder gear was added to allow for potential future encoder use.

Encoder

A Lynxmotion encoder was installed into an old Lynxmotion motor housing and bolted into the second motor location. A large pinion was used to slow down the encoder speed.

The encoder delivers 120 cycles per revolution or 480 quadrature changes per revolution. Mounted on the robot, the encoder produces 3,103 counts per decimeter robot movement. Although this seems excessive, rollover with a 32 bit microcontroller isn’t a problem. The robot would have to travel about 85 miles before the encoder counter would reach maximum value.

A standard encoder function in the Propeller was used to produce distance travelled and rate of travel (speed).

At the second RoboMagellan contest in Chicago, the encoder stopped working. Apparently, there was too much axial movement in the encoder. The problem was rectified by replacing the stock bushings in the motor case with ball bearings, and using precision spacers to control sensor wheel to encoder distance.

Latitude and Longitude

Latitude and Longitude numbers produced by the GPS unit are very intimidating. In order to ease the calculations and produce numbers more readable, a “local origin” is chosen just southwest of the RoboMagellan course. The Latitude and Longitude of the local origin as well as the degrees per decimeter for Latitude and degrees per decimeter Longitude are entered into the program as constants.

For each new location, Google Earth is used to determine the local origin and an online program is used to calculate degrees per meter for Latitude and Longitude.

During ASCII to integer conversion of the NEMA sentences, only the difference between the actual readings and the local origin are calculated and converted to decimeters. Decimeter GPS distances are unrealistic, but sonar and encoder decimeter readings are reasonable and having two different standards of measurement in the same program would be very confusing.

Kill Switch

The rolling code remote that has been used in many of my sumo robots was installed. Because the distances are greater in RoboMagellan that sumo, a vertical antenna on the receiver is required. The distance of the remote is several hundred feet, so the operator doesn’t have to stay reasonably close to be effective.

If any button on the remote is pushed, the motor is immediately stopped, but the rest of the programs continue normally. A second button push releases the motor to run normally. That way, the robot can be paused for any reason and restarted exactly where it left off.

Purpose and Goals

During October, 2007, I received an Email from Steve Hassenplug. Steve was trying to get the Chicago robot club (Chibots) to hold an annual RoboMagellan contest. Steve needed some more entries, so I committed to build a robot for the spring, 2008 competition.

The first goal was to learn the Propeller. All of my fun with robotics has involved the Basic Stamp for about seven years. I did experiment with other microcontrollers (SX, AVR, PIC, and Propeller) without much success (or lack of motivation). By the end of 2007, the Propeller Object Exchange was large enough to be useful and some learning tools were becoming available. Now the RoboMagellan was the motivation to take the time to learn.

The second goal is to play with technology. GPS, compass, encoder, sonar, etc. sounded like fun. Also, new devices were coming on the market. I just needed an excuse to buy them, make them work, and incorporate the functions into a robot. It is all a lot of fun and has been a constant obsession ever since. I do get distracted often.

After two contests, this robot has not found anything useful.

To Do List

Display distance traveled in decimeters, not counts.

Do reversing turn in two directions and develop logic to select direction.

Limit steering by actual (encoder) speed.

Remote “Dead Man” kill switch.

Use “offset” from specific start position to correct for GPS drift.

Use uALFAT with FDS4 to save a cog.

Faster brake application.

Turn away from objects sooner when detected by side sonar (speed dependent).

Test different sonar units and mounting configurations.

Speed limited by nearest sonar detection, not just front sonar detection.

GPS SOG to determine lack of movement.

GPS COG to refine compass direction.

Increase encoder accuracy on different types of surfaces.

Manipulate data points with pushbuttons and LCD screen.

Complete weatherproofing.