Compass Integration

Posted by on

After far too much pain and effort, the magnetic compass is integrated with the robot.  Calibration is a bit finicky, and I don’t think the SYNC signal is implemented properly.  But, the compass works, and the heading matches my mechanical compass.  Here are a few lessons learned:

  1. RTFM.  Set the pin data direction (DDRQS) because inputs don’t work well as outputs and outputs don’t work well as inputs.  The QSPI hardware will halt with “mode faults” if the pin directions are wrong.  Set the PORTQS register to the inactive pin state.  The slave select pins are active low, and don’t forget that when setting the PCS bits in the COMMAND bytes.
  2. RTFM.  The Vector V2Xe compass has a response timeout, and trying to write out a bunch of debug information in the middle of reading the response is ill-advised.  Also, the compass does not respond immediately, so look for the 0xAA synchronization byte.  The compass manual is, unfortunately, vague in a few areas.  The manual mentions the response delay for GetData commands but not for other commands.  Also, the manual does not give full timing specifications (e.g. setup and hold times) for the SPI bus or the SYNC signal.  The manual doesn’t say if the slave select may temporarily go inactive in the middle of a command or response.

I’m busy tweaking navigation and obstacle avoidance behaviors.  The Sharp IR range finders give false positive readings when moving into the sun, so the ‘bot can develop heliophobia.  I just finished implementing a simple low-pass filter for the IR ranges, and I’ll see if performance improves.  I’m considering the addition of tactile bumper — the IR filtering and the elevated sonar (to avoid ground reflections) make the robot blind to short obstacles.

I’m ready for the AVC.  Are you?

So much to do, so little time

Posted by on

Here’s a new video showing off obstacle avoidance. The robot manages to avoid walls, chairs, tables, couches, and a dog (although the dog usually runs away, probably because it knows the robot’s secret world domination plans).

Much work remains, and not enough time remains.

  • I’ve replaced the motors to increase torque.  The old, faster, lower torque motors tended to stall.  The new motors work well although they produce more electrical noise.  Next time I have the robot apart, I’ll add the vendor’s recommend filter caps to the motors.  As an interim solution, I limit the acceleration, which keeps to noise to a manageable level.
  • The wheels tend to fall off.  That would be embarrassing during competition.  I cannot get the set screws on the wheel hubs to stay put.  I’ll drill out the hubs a bit so the wheel sit further on the motor shaft.  If that doesn’t help, I’ll try a thread locking compound.
  • The micro-controller appears to radiate interference that affects the GPS receiver.  I experimented with tin-foil shielding and didn’t observe improved reception.  I added a 3.3V regulator dedicated to the GPS, and performance is now acceptable.
  • The software has grown substantially.  The robot sports an interactive serial monitor.  The monitor allows configuring various parameters and saving those parameters in battery-backed RAM, which allows me to tune behaviors without the time consuming compile/load cycle.  Also, the monitor permits checking sensor values, watching raw NMEA data from the GPS, and restarting the GPS.
  • Waypoint seeking and route following code is done and working.  Unfortunately, the GPS doesn’t provide reliable heading data at the robot’s typical speeds.  I’m not really surprised and planned from the beginning to include a magnetic compass, but I never got around to integrating the compass.
  • The tail wheel is too small and tends to catch on obstacles.  I have several new candidate wheels in the mail.

Next up:

  • Integrate the compass and update the navigation code to use the compass.
  • Replace the tail wheel with something less likely to get stuck.
  • Improve main wheel mounting.
  • Use the buttons on the top of the robot for something.
  • Implement a data logger to permit better analysis of robot performance.

Robot Websites

Posted by on

Here’s a compilation of links relevant to my Sparkfun AVC entry.

First off, here are several competitors with blogs.  Please let me know if you find more blogs, and I’ll amend this list.

Second, here are several interesting ‘bot websites:

Third, here are several excellent articles on odometry, dead reckoning, and navigation:

Robot’s First Steps

Posted by on

Lots of work is going into the software, and the robot has broken the surly bonds of my bench supply.  Here are a few new pictures with an Apple IIgs shown for scale.

Yes, the sonar is nearly falling off.  Let that teach me to use double-sided tape.

The bottom deck includes the motors, motor driver, and the power distribution board, shown here removed.  The power distribution board contains the battery holders, a main power switch, two separate fused circuits for logic and motor power, an external power connection useful for testing on the bench, and an emergency kill switch.  The kill switch is simple and reliable: a wire in series with the motor power supply protrudes from the back.  Pull the wire out, and the motors stop.  Logic retains power for testing and diagnostics.

The final photo shows the LCD on top of the micro-controller board.  There is an XBee for wireless programming, debugging, and telemetry.  Also, note the GPS, a small board for 3.3 VDC power distribution, and a level converter board.  The unconnected yellow wires are for hardware flow control to the XBee, but the XBee operates adequately without flow control.  I also have space on the top deck reserved for a Vector V2xe magnetic compass.

Not obvious in these photographs, I’ve added a remote kill switch.  Send a “CTRL-C” character over the wireless link, and the software disables the motor driver.  The interrupt handler for the serial communications interface checks for and handles this control character, so the robot should respond to the remote kill even if the most of the software has gone haywire.

I’ve switched over to interrupt driven serial I/O from polled I/O.  This change should improve software performance and make the rest of the software easier to write.

I’ve replaced the plated metal standoffs with 2″ Nylon standoffs.  They’re lighter and should help magnetic compass accuracy.

I’ve finished software to parse NMEA data from the GPS and software for basic tele-operation.

The software needs a lot of work still, but most of the low-level infrastructure is in place and working well.  Also, I’m dissatisfied with motor torque.  The robot works well on flat ground but grinds to a halt on bumps.

Check out the robot in motion on YouTube.

It’s Alive!

Posted by on

SIZE: 9″ (W) x 6″ (L) x 4″ (H)

WEIGHT:  About 2 pounds

BRAINS:  MiniRoboMind – A Motorola 68332-based 32-bit processor running at 25 MHz with 512KB RAM and 512KB Flash; Software written in C with GCC; An LCD for taunting competitors; An XBee radio for telemetry and diagnostics

BRAWN: Two Pololu Micro Metal Gear-motors with a TB6612FNG motor driver and 3.25″ R/C aircraft wheels

SKELETON: Expanded PVC, 1/4″

POWER: 8xAA NiMH, with separate fused circuits for the logic and motors; Emergency kill switch (the bane of all robots attempting to conquer the world)

EYES: 3 Sharp IR range finders, 1 Maxbotix sonar, and a Locosys LS20031 GPS receiver

It works.  Electrical and mechanical integration is complete.  The GCC toolchain produces working binaries.  The software reads all of the sensors and controls the motors.

GPS

Posted by on

The GPS is an amazing piece of technology.  Think about it.  For less than $100, you can determine your position within a few meters anywhere in the world.  One hundred years ago, you needed a compass, sextant, clock, and luck to estimate your position.  I’ve used a Garmin Etrex Vista extensively for field checking during orienteering, and I’ve been pleased with the reliability and ease of use of both my Garmin receiver and GPS in general.  However, the GPS has several limitations that you must be aware of whether building a robot or engaging in land navigation.

  • A GPS tells you where you are, not how to get where you want to go.  Sure, a GPS can tell you direction and distance to your destination, but the receiver knows nothing about the terrain and will mindlessly direct you over tall mountains, across deep canyons, or into alligator infested pits.  Many receivers have integrated street maps, but those are no help when traveling off road.
  • A GPS gives heading only while in motion.  Many receivers incorporate magnetic compasses to provide heading while stationary.
  • Most receivers provide heading relative to true north while compasses give heading relative to magnetic north.  The difference can be significant.  In the contiguous 48 US states, the difference ranges from about -20 to +20 degrees.
  • A GPS is sensitive to interference.  Buildings, trees, people, and clouds can and will degrade the accuracy and precision of the position fix, possibly to the point of preventing the receiver from getting any position fix.
  • Even with good reception, the GPS reported position will wander.  I’ve seen the position from my Garmin receiver jump hundreds of meters on a clear day.
  • A GPS receiver requires batteries.  This can be a big disadvantage in land navigation when power sources are not available and getting lost is potentially fatal.

A GPS receiver does not allow you to turn your brain off during land navigation.  Similarly, a robot using a GPS receiver requires design and software that can deal with the limitations of GPS.

I originally intended to use my Garmin receiver in the robot because I already own the receiver.  Also, the receiver has a built in magnetic compass and outputs NEMA data with the magnetic heading.  But, my robot is small, and this receiver is, in comparison, large and heavy.  Sparkfun sells many small and light weight GPS receivers.  The selection is rather overwhelming, even with the Sparkfun GPS Buying Guide.  As best as I can tell, nobody has done an objective hobbyist-level comparison of common GPS modules, so selection really is a shot in the dark based on availability, limited data sheets, and anecdotes turned up on Google.  Anyway, I’ll summarize my findings:

  • EM406 – Uses the well-respected although several year old SiRF III chipset.  Only supports 1 Hz updates.  Supports an optional binary protocol.  Detailed documentation.  Runs on 5V power supply, which is desirable for my robot.
  • LS20031 – Uses the less well known but still common MediaTek chipset.  This chipset is newer than the SiRF III.  Some folks report that the receiver is very good, but I cannot find a useful comparison to the SiRF III.  The latest revision (presently available from Pololu) provides 10 Hz updates.  Does not support a binary protocol.  Limited but adequate documentation.  Runs on 3.3V power, which is a disadvantage for me.
  • Venus – The specifications look very good, but I found an above average number of anecdotes about trouble getting good fixes.  Also, the Sparkfun breakout board for this requires an external antenna.
  • GS407 – Uses the uBlox chipset with 4 Hz updates.  This chipset is highly regarded on some UAV websites, like DiyDrones and Paparazzi.  But, the receiver is relatively expensive, has no on-board battery for quick startup using retained almanac and ephemeris data, and has a difficult to use connector.  Detailed documentation.  Also supports a binary protocol.

There are, of course, many more GPS modules.  Sparkfun seems to have the biggest selection and carry all of the modules popular with hobbyists.  I ignored some of the older Sparkfun modules simply to keep my search manageable.  Based on the limited data I’ve found, I purchased a LS20031 module.  The fast updates, low cost, and new chipset swayed my decision, but the EM406 and GS407 are strong candidates.  Another day, I might have chosen either of those.

I just got my LS20031 in the mail.  I soldered four wires to the VCC, TX, RX, and GND pads.  Then, I applied 3.3V from a bench supply and attached the TX line to my TTL-232R-3V3 cable from Adafruit.  The data sheet promises a 9600 bps 8N1 logic level serial interface, but my module runs at 57600 bps 8N1 ought of the bag.  The module has a red LED that flashes briefly at power on then flashes once per second after acquiring a position fix.  So far, I’m impressed with the module.  It’s small and light.  And, it got a position fix with six satellites quickly indoors where my Garmin cannot get a fix.  I didn’t measure time to first fix, but cold start is on the order of minutes and warm start is less than a minute.

Next up, I’ll interface the GPS module to my micro-controller.  Things are starting to come together, and my stack of parts should start looking like a robot soon.

Robot Mechanics

Posted by on

My build for the Sparkfun Autonomous Vehicle Competition continues.  Slowly.  I intended to be busy with system integration by now, but I haven’t even built the physical platform.

Mechanical design is difficult because there are many inter-related factors to consider.  For example, the motor selection partially determines weight which in turn partially determines motor selection.  And, motor selection determines battery selection which in turn determines weight which influences motor selection.  Both motor selection and battery selection affect physical size necessary to hold both components.  Never mind the matter of finding components with the desired specifications at a reasonable price …

The easiest solution is to buy an existing robot, like the fancy new Stingray, or repurpose a radio-controlled (RC) vehicle.  I’ve elected to build my own because I enjoy DIY, believe I’ll learn more, and need to control costs.

So, here are my requirements for the physical platform:

  • Carry the GPS receiver, magnetic compass, MRM micro-controller, motors, motor drivers, LCD, and batteries
  • Travel on paved terrain with sufficient clearance for speed bumps and pebbles at least 1/4″ tall
  • Have a chance of matching last year’s winning ground time of 1:32

The Society of Robots has an excellent introduction to robot dynamics and discussion of topics like torque, force, velocity, and acceleration.  After many hours with this page, pencil and paper, a scale, and a spreadsheet, I’ve decided on the following design.

  • Two Polulu Micro-Metal Gear Motors:  Last year’s winning ground entry was a retro-fitted RC race car that, by my calculation, must have moved pretty fast.  I estimate it moved at an average speed of about 7 mph.  Coming anywhere close to this speed is difficult with commonly available gear head DC motors and wheels.  A custom gear train is beyond my time, skill, and ambition at the moment.  I think the Pololu motors slightly over-volted will give adequate performance with a maximum speed only slightly lower (estimated at 6.8 mph) than last year’s average winning speed.  The weight of the robot will have to be low since the torque from these motors is low.  I’ll be happy if I can just finish the race, which is a significant challenge by itself.
  • Two Model Aircraft Wheels (3.25″ diameter):  I wandered around the local hobby store looking for fairly large diameter wheels (to increase speed) made of fairly firm rubber (because the robot is running on pavement).  These wheels seemed like the best choice, and I think the Pololu hubs will attach easily.
  • Three rectangular decks made from expanded PVC:  This material is light, inexpensive, and sturdy.  Plus, I already own enough.  The robot will grow up via additional decks rather than out due to limited size of the material I own, ease of transporting a small robot to Colorado, and reduced turning radius.  Plus, I like the look of multiple decks more than a single large deck.  I estimate that I’ll need three decks, each roughly 17cm square with sawed off corners, to hold the parts.

I haven’t solved weather resistance.  As is, my robot will have to stay home during inclement weather.  Based on photos from last year’s competition, I suspect many builders just hoped for good weather, too.  I might consider a plastic housing for the expensive electronics, just in case.

I think I’m ready to make a full size template of the decks and start cutting.

Mark Simonsen of Beagle Bros to keynote KansasFest 2010

Posted by on

From KansasFest:

KANSAS CITY, MO — December 22, 2009 — Mark Simonsen, employee number three and later owner of Beagle Bros, will be the keynote speaker at KansasFest 2010. At Beagle Bros, whose popular software products for the Apple II hobbyist demonstrated the publisher’s quirky sense of humor, Mark developed software including Flex Type, Beagle BASIC, Beagle Graphics, Triple-Dump, and Double-Take. In the early 1980s, Mark decided that he “wanted to work with the Apple for the rest of [his] life,” a statement that captures the enthusiasm and spirit of Mark, Beagle Bros, and many Apple II users.

Beagle Bros started in 1980 under the direction of Bert Kersey to provide software to casual users of the Apple II. A year and a half after graduating with a degree in computer science from Brigham Young University, Mark “fell in love with the Apple.” Mark published Flex Type through Beagle Bros in 1982, joined the company as a programmer in 1983, and bought it in 1987 at the age of 29.

Besides software like Shape Mechanic, GPLE, and DOS Boss for budding programmers, Beagle Bros produced books, posters, and even advertisements full of clever and useful tidbits demonstrating the capabilities of the Apple II. Later, the company produced highly regarded productivity software like Platinum Paint, BeagleWrite GS, and the TimeOut line of AppleWorks add-ons. Beagle Bros earned many loyal followers thanks to the combination of quality products, enthusiasm, and humor.

Mark sold the company’s product line in 1991 and 1992 to Quality Computers. Today, Mark helps save memories as the CEO of iPreserve, a company specializing in photo, film, video, and document preservation.

KansasFest 2010, the 21st annual Apple II conference, is set for July 20th through July 25th at Rockhurst University in Kansas City, Missouri. KansasFest was originally hosted by Resource Central and has been brought to you by the KFest Committee since 1995. Any and all Apple II and Macintosh users, fans, and friends are invited to attend this year’s “summer camp for geeks.” Registration details will be announced on the KansasFest Web site in early 2010. Please heed the warning from Beagle Bros and refrain from feeding your disks to alligators. For photos, schedules, and presentations from past year’s events, please visit the event’s official Web site at http://www.kansasfest.org/

CONTACT:
KansasFest 2010
http://www.kansasfest.org/
http://twitter.com/kansasfest/

If you’d like to read more about Beagle Bros and Mark Simonsen, I suggest checking out the following:

And, here are a few slightly less relevant but still relevant references:

SparkFun Autonomous Vehicle Competition

Posted by on

I’ve run off and entered the SparkFun Autonomous Vehicle competition in April.  The rules are pretty simple:

Create a vehicle that can autonomously navigate around the SparkFun building

Autonomous vehicles (robots!) fascinate me.  But, there’s a problem:  I don’t have a robot.  I have assorted parts and plenty of ideas but no robot.  My personal goals include:

  • Get the motivation to finally build a robot
  • Learn
  • Meet like-minded people
  • Maybe finish the course

Let’s decompose the rules into smaller, more frightening problems:

  • Mechanical:  Does the vehicle travel over land or through the air?  How?  For a ground vehicle, does the vehicle have wheels, tracks, legs, or something else?  How does the vehicle steer?  What’s the design and construction of the vehicle?
  • Sensors:  How does the vehicle detect and avoid obstacles, like cars, people, bushes, and lakes?  Cameras, IR range finders, sonars, and contact bumpers are leading contenders for sensors.  How does the vehicle find its way around the building?  Does the vehicle use a GPS, odometry, cameras, or something else?
  • Control:  Which micro-controller(s) do I use?  How do I design the control software?  What algorithms and architectures are appropriate?
  • Electrical:  How do I connect and power all of this?

I’ve decided on a three-wheeled ground vehicle with differential steering.  Several competitors last year retrofitted R/C cars or trucks, which is an easy way to get most of the mechanical design and construction done.  In the spirit of Do It Yourself and Not Invented Here, I’m building my own platform.  I’ve chosen differential steering because there are plenty of examples, websites, and books about this design.  Additionally, differential steering permits a very small turning radius.  Building Robot Drive Trains and Constructing Robot Bases are great references on mechanical design and construction of small robots.

I’m using the MiniRoboMind micro-controller because I already have one, and it’s a very capable controller (32-bit 68332 at 25 MHz with 512 KB RAM and 512 KB Flash) compared to more popular controllers for small robots.

Like most if not all of last year’s competitors, I’m using a GPS to navigate around the building.  The alternatives that I see, like cameras or an IMU, seem more complicated.  I may need to supplement the GPS with a magnetic compass and wheel odometry.

I’ll use an IR range finder as the primary method of detecting obstacles.  Sonar seems like a better choice with longer range, but a competitor last year had trouble with ground reflections disrupting sonar readings.  If time permits, I’ll explore sonars and contact bumpers.

Details on last year’s competitors are scarce.  Despite the requirement to document the build, I’ve only found technical details on Deathpod 3000, the winning ground vehicle.  RoboMagellan is a similar outdoor autonomous competition devised by the Seattle Robotics Society, and several RoboMagellan competitors have published very useful technical details.

I’m off to fret about motor and wheel selection.

Low-Res Life for the Apple II

Posted by on

Conway’s Game of Life is mathematical exploration into artificial life.  The game consists of a grid of cells, and each cell is either alive or dead.  A simple set of rules relate the cells alive or dead in the current generation to the previous generation.  The interesting thing about the Game of Life is that a simple set of rules creates surprisingly complex patterns and behaviors.  Wikipedia gives more details, including examples, a more formal definition of the game, and history.

I have implemented the game of life for the Apple II computer using the low-resolution (40×40) video mode and the Macrosoft macro language.  Macrosoft is a library of assembler macros that produce assembly language code.  I chose this language because I wanted to learn this unique language for years and to improve performance of the implementation.

Download the program with source.

Look for an article in Juiced.GS (Volume 14, Issue 3).

Screenshot