Let's Make Robots!

MY AGV development platform


I decided to do this as a blog as I plan for this to be a long term test platform as I mess around with different tech along the way.

OK I started by buying this RC truck chassis on eBay:

It uses a 7.2v NiMH battery and powers the motor using an ESC that delivers a few AMPs of 6v through a BEC to power a transceiver and the steering servo. Instead of a transceiver, I am hooking up an Arduino Fio and various components, housing them in a project box:

I said earlier that it uses an NiMH battery and you can see a LiPo here. that's because a smart charger and another NiMH battery are on their way and I am waiting to recharge the primary NiMH until I have the smart charger. On the right is a connector I made that can connect up to 3 servos or ESCs. It is connected to one ESC and one servo. Their data lines go to PWM pins on the Fio, the grounds are commoned (as are all grounds in all cases, so I will quit detailing that). The power line has voltage coming in because of the BEC on the ESC and it is 6v. It goes onto the the mini breadboard and is connected to VIN of the Fio. It also powers the "5v" power bus on the second breadboard by going through 2 diodes on the way there.

On the larger (but still fairly small) breadboard, I have a GPS powered at 5v and I run the Fio's 3.3v VCC to power a compass. I currently have a BluetoothMate that I plug into the FTDI on the Fio to receive some simple commands for RC operation so I can see that things work and it reports GPS locations. The compass is I2C and is currently not working. I need to swap it with an identical unit being used on another project to make sure it is good and then psych that out if so.

I have xBee modules that I will do some of my testing with, again wiring to FTDI on the Fio and I have some Nordic chips.  It's likely the breadboards will never go away on this unit.

Right now, it will move around as an RC vehicle. As soon as I get the compass working, I have code from another project I need to do some testing with which seeks a potentially changing GPS point (very similar to what Patrick did; in fact it would be even more similar had I found his before I started mine :) ).

Anyway this is my test ground vehicle. I will update as I try various things and hope to add a video as soon as it starts seeking...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

That's a couple of Nordic modules (super low power 2.7G transceivers) I picked up on clearance at SFE. They are clearing then out  because they have an awful pin spacing, but the breakout boards (I have 3 on the way along with a 3rd module) are only about $1 each. I want to try these as an alternative for short range (at SFE, testing indicates I should get over 100m LOS) RC.  Bluetooth is unforgiving of temporary loss of signal and xBee (the 900 Pros I use) has an awesome range but sucks batteries.

My gender confused BlueTooth Mate module is also in the picture. I do that to testing modules that are FTDI pluggable - add a female header to go over FTDI pins and a male header for breadboarding. If you look close at the compass, you will see it has that also, but that is for a different reason. I expect it to be on a breadboard or in a socket, but then a 4 pin cable could be plugged in to extend I2C to another device.

The mailman just brought my new NiMH battery and smart charger, so I may get a video later, running down the new battery


Stupid human! I read this page too fast:


There is a spot that says:


    http://arduino.cc/en/pub/skins/arduinoUno/img/bullet.gif);list-style-position:inside;color:#555555;font-family:Georgia, 'Times New Roman', Times, serif;font-size:14px;line-height:23px;margin:0px;">
  • I2C: 4 (SDA) and 5 (SCL). Support I2C (TWI) communication using the Wire library.

But before you jump to the conclusion that means the pins labeled 4 & 5, you have to read the text above it:

The Fio has 8 analog inputs, each of which provide 10 bits of resolution (i.e. 1024 different values). The analog inputs measure from ground to Vcc. Additionally, some pins have specialized functionality:

They are the only 2 pins on that page not referred to explicitly as labeled on the board.

Frustrating, but behind me. Hopefully I will test GPS seeking tonight!


It remote controls as a "regular" RC car fine and it has GPS homing functional (but still needs tweaking). Near term future plan is to put a "lazy susan" style disc on the plate between the front wheels and attach it to the steering servo. That way an ultrasonic mounted there would be able to "look" right or left when I turn the wheels.


Using the GPS in the unit, it is seeking the GPS in the base (the remote control box).

I started a thread with questions that is turning into a running monologue:


I probably should have just rambled about that here, but I was hoping I might get more discussion starting a thread.

The red markers are locations that the beacon transmitted and the AGV reported as where it was when it went into or came out of a tight slow circle pattern. The blue circle is my observation of the area it stayed within. I had to step out of the way several times. I was able to let it run freely for several minutes without it hitting any of the obstructions, so I think my circle is pretty accurate. I can probably tighten the circle by limiting how many degrees off I allow before forcing a slow turn instead of a slight correction.

In a Previous post I had this video:


of what I consider a partially successful test. I stopped the car a couple of times in the video when I was afraid it would hit something, but it was never running off without turning back. The concept and design works, but I needed to tighten the circle it operates in, and not just to keep it from crashing. When this is used on a boat, it may need to cover all the water inside the smallest area I can accurately determine contains the target. The smaller the area, the less time that will take.

I didn't do a video this time as I was going alone at daybreak (so I could use a really open lot) and I wanted to be ready to stop the car if things weren't working. The improvements I made since the video were to go to the first waypoint sent before accepting different waypoints (cut down the jitter in the sending unit), make it go into a slow tight circle anytime it detected that it was very close and to stop and wait for a GPS update if it was using data that wasn't under a second old. The map above represents what effect those changes had. It still does loop around a lot but that is by design; it doesn't get to just decide it has arrived; it has to physically encounter the target. I hate using "target" because the main project that I can't give details on is absolutely NOT a weapon; it is pretty much the opposite. But when it thinks it is close it circles slowly now and the insistence on fresh data keeps it from overshooting quite so far before turning back.

I am following your progress with interest. I have also read (and bought the board) Patrick's tutorial on his AGV. Finally I asked a friend in Florida to buy for me that cheap GPS, so I will have something to play with in a few weeks. Now I need to find a used truck chassis at Value Village that I can convert for this project. I always wanted to participate in a Robo Magellan type competition, so I guess we can make a challenge where participants can have their own course and video the robot following it. The challenge should follow the rules of the original Robo Magellan competition, so the robot is not remote controlled.

My robot answers to another uC - does that count as remote control? The real challenge has been to get 2 GPS units to read the same. I need to take some new pictures. I swapped out the Fio and now have a JK Devices MiniMega 1280 in there. The other project I am sharing code with uses a MEGA 2560 to control a boat and by getting a unit that has the same number of serials and pins I am able to share code better. I have several tabs in each project and they can share most of them. The file for motors is different, the boat has an OpenLog that I don't have on the AGV and right now the AGV has a "sensors" file that isn't on the boat, while I try to figure out radio homing to get the last few feet. The boat will hopefully be a commercial product so I can't say much about it (I am under an NDA with the guy who designed it).

I am trying to home in as quickly as possible, which introduces some other issues, most notably lag time. When you spin quickly, you can't wait for the exact heading because the motors are not instantaneous. In fact, using an ESC introduces some delay, mostly because of safety features. Another lag time issue is that when you are cruising along pretty good, the GPS coordinates are offset by the distance traveled in the time it takes to transmit and receive them.

Instead of the Fio, I now have a JK Devices MiniMega 1280, which is software compatible to the old Mega 1280 and to the newer Mega 2560 for most projects. I also went to a big breadboard and "real" jumper wires. The breadboard has 4 power buses. On the upper left, power comes in from the 6v BEC and I have a decent size cap because it will surge with motor use. If you look close, you will see that I bridge to the next power bus with a diode so it is only slightly over 5v and use it as my 5v bus. The bottom power buses are not fed now, but will likely be 5 or 3.3v .  the compass module has a rep for not liking much power, so it is fed through a diode that puts the input down around 4.5v. The xBee is on a an xBee Explorer, which likes 5v, and the GPS also deals well with 5v. the mini breadboard on the upper left has a 434MHz receiver that I am working with to try to get radio homing for the last few feet. The purposefully weak transmitter for it just sends 'U's at 2400 baud and I count how many in the last 100 characters received to figure whether I am getting closer or further.