Robotic Core

Well, I’ve hit the wall on this one. When I moved to my new base of operations deep in the Missouri Ozarks, I had 2 buildings: A small house, and a 30 by 40 foot Pole Barn I paid a crew to erect on the property.

A “Pole Barn” is a simple structure… a basic pole frame (The poles are 6×6 treated wood posts.) clad in a minimalistic steel skin. It has a concrete floor, but no insulation at all. In the summer, it gets HOT inside there, so hot and humid you can’t keep complex tools like a Lathe or Vertical Mill.

So what I keep in there is my Tractor, it’s accessories, and a lot of stored stuff… mostly tools. Tools I can’t use because all the space in the Pole Barn that isn’t Tractor or it’s accessories if full or stored stuff. Like tools. It’s a vicious cycle. I was able to free up enough space in the house for a couple small workbenches (Made in a previous post.) but I can only make electronics in that small space.

I reached the point where I need to be able to make machined metal parts long ago.

This left 3 possible courses of action:

1) Otherwise known as “Plan B”. That’s where I abandon the T1′s design goal of a custom fabricated chassis and drive system and buy a 1/10 scale RC car to use for the robot. There’s certainly no shame in that approach… There’s a whole new world of challenges to meet there, jamming all that stuff into that tiny chassis. But no. That’s not my style. I have to be true to my long term goals… and that means custom fabricated chassis and parts.

2) Pay huge money for a crew to build what I need. Hmm. I have to ask myself… “What would Goku do?” Would Goku pay a guy to fight for him? No! Goku would train until he could do the fight himself. How can I call myself a “Maker” if I turn to hired guns every time I need something made?

This leaves option 3.  Just like in the game “Doom”, “The only way out is through.”

3) Build a Machine Shop myself inside the Pole Barn that incorporates sufficient work space and includes a “Mezzanine Level” above for storage. This shop needs to be well lit, insulated, and climate controlled to support machine tools.

Option 3 it is! Only one problem… I’m a 52 year old Computer Nerd who’s spend his entire career sitting on his obese ass at a computer. That’s really not good training for building what I need to build.

But the only way out is through. What would Goku do? Goku would act as if and train as he goes along. In effect, “what does not kill you makes you stronger.”

Here’s where I’m at now:

This picture is from the Pole Barn’s door looking in. The Machine Shop is in the back of the Pole Barn, occupying a space 30 feet wide and 16 feet deep (As viewed in the picture.) Notice all the crap in boxes in the foreground. All that stuff was where the Machine Shop was before I started construction.

This is the left side of the new shop space. the entrance door (That huge hole for a double door in the previous picture.) is to the left, and the rear of the Pole Barn is to the right. See that brown space in the middle of the far wall? That’s one of the poles that comprise the Pole Barn. I integrated them into the structure of the Machine Shop. The wall that separates the Machine Shop from the rest of the Pole Barn is a 2×6 stud wall, the other walls are 2×4.

Looking in the other direction. You can see the huge opening for the entry door to the right. The entry door itself is tied to the stud wall ready to be installed… the door itself is a double door, made of steel, with the main door 36″ wide, and the side door 24″ wide. So it can open to a full 5 feet to allow huge pieces of equipment to get in. The header above the door is a beefy 3 deep 2×12 sandwich. If a tornado comes along, it’s gunna look at this and say “I can’t break this! I better look for a Mobile Home instead!” You know how tornadoes are.

That’s the entry door framing. I doubled up the Trimmers under the Header to better support the load of the storage area above.

This is the area directly over the entry door. You can see the 2×12 header for the door in the middle. The joists above are also 2×12, as they need to support the weight of all the stuff stored above the shop. Normally, a “Rim Joist” is used on the outside of the floor joists, but I used blocking between the joists instead. (That’s why you can see the end grain of the joists themselves.) Notice the double wide joists to the left and right of the door? Those are to transfer the roof load to the floor so I can cut out the center of the engineered rafter components, thus making room so I can get up there to store my stuff.

This is an enormous effort. I’ve completed the framing, and have moved on to roughing in the electrical. There are over 40 electrical boxes, and 1250 feet of wiring. This is huge.

The down side of all of this is that I’ve eliminated the possibility of competing in Sparkfun’s competition in June. The plus side, however… is that in the future I’ll be that much stronger.

The T1 is not cancelled. Just delayed until the 2013 competition.

I have all the parts for my small run of ArduNet boards in except for one. Apparently, I ordered the .1uF decoupling caps in the 0201 size instead of the 0603 size I wanted. I’m not sure how I did that? But  it was certainly my error, not Digi-key’s. I have nothing but good things to say about Digi-key. It’s easy to order parts, they pack that order FAST, and the parts ship right to your door. Even with the mickey mouse quantities of parts I order, they have a service department that looks out for you. Case in point, I have a wonky address. It’s on a Rural Route (I’m strategically located deep in the Missouri Ozarks, everywhere around here is a Rural Route.) If you don’t know how Rural Routes work, I’ll tell you. It’s not like a normal address… the format is “RRx BOX y” and then “City  State Zip” on the next line. “x” is the number of the route and y is the box number on that route. Rural Routes cross highway and road numbers, You can have a “Rural Route 1″ that covers… say… Highway 10, County Road 2, and County Road 3. The delivery driver just has to know what the actual mapping is.

Anyway, here’s the issue. The Postal service has a standard format they want people to follow. In the case of the Rural Route, it’s “RRx BOX y” with nothing after the box number. You can have a letter immediately after the box number, like “RR1 Box 100a” But not arbitrary text like “RR1 Box 100 Jill’s house” Here’s the problem. There was already no space between the numbers when my address was established a decade or so ago (Not by me, the property was split into 2 and a second address created.) Instead of just adding “a” to the existing number, the mail carrier added a 1/2 to the number, so it’s “Box 100 1/2″. Whoops. That looks like “extra crap” after the box number to the scanning system, and it’s balked at. I have no end of problems with this. Web sites try to “fix” my address for me, or give me limited shipping options. I hate that. So… to make a long story only slightly shorter, Digi-key has a nice web site, it suggests the “proper” address, but allowed me to easily use what I typed instead with no shipping restrictions. One of their service reps even called me to verify that I received my order and to make sure they had my address right. Nice!

Sorry about the rant! I just had to get that off my chest.

So! I have enough of the missing part to make a couple of boards, which works because I need to make one by hand first (without using the stencil) to verify the design and board layout. I need to do it without the stencil because I want to build the board in stages, first the power supplies, then the CPU, finally the UART chips. Testing the installed parts at each stage. I also upped the ante by using lead free solder.

Wow. lead free solder does NOT want to melt. I had to really boost the heat, and even then it was clear that flow isn’t nearly as fast as leaded solder, and it hardens a lot faster. MUCH harder to work with. But I need to develop the skills, so I used it.

The solder I’m using is from Sparkfun, Solder – 1/4lb Spool (0.020″) Special Blend It’s good stuff, I like it for the small diameter (.020) and the water soluble core. Used in conjunction with the flux pen, Liquid Flux Pen – Water Soluble you have an easy to clean board when you’re done. I also use a pair of tweezers to maneuver the parts, I got it at Sparkfun too: Tweezers – Curved but I only have one pair, I often feel I need another tool to manipulate the small SMD parts, so I think I’ll order some more of them. These tweezers have tiny, tiny tips and are quite precise. The times a second pair would come in handy is when you have to flip a part over, hold a part down because flux got on the tweezers and the part is sticking to it, or when you have to rotate a part to get it to fit better on the footprint. Which… is pretty much all the time, really.

Most of my discreet parts are 0603 size. The best way I’ve found to do those is to position the board such that the part is sideways before me, then flux the left most pad (My soldering iron is on the left side, as I’m left handed.) Then I add a tiny bit of solder the the pad I just tinned and reflux both that pad and the other. then I position the part with the tweezers, and while holding it down, reflow the solder with the soldering iron, allowing the part to settle onto the pad. Spin the board around so that the other pad is on the left, and solder the other pad with the soldering iron and solder. The part will be held by the first connection and won’t move or tombstone.

Once the 0603 parts are on, I solder on the larger caps and voltage regulators.

At that point I broke out the Reflow Skillet, which is just a rectangular electric skillet I got from Target. You want to pick one that goes as hot as possible, mine goes up to 420 degrees Fahrenheit. That seems to be enough. Sparkfun has a lot of tutorials on SMD soldering and one on using the Reflow Skillet… read them. They’re good stuff. Heating the board up in the Reflow Skillet at this point allows the solder to melt and allow the parts to ‘pop’ into alignment with the pads through the surface cohesion of the molten solder, it’s really nice to see the parts all line up! They were looking pretty scary after I soldered them!

So now I have the discreet components and the regulators on, but no other ICs. I soldered the power connector on and applied power to the board. Good! The regulators work, but the power LED (LED1) does not light up. There’s 5 volts across it, indicating it’s installed backwards. Oops. Checking the other LEDs by jumpering 3.3v to the LED’s current limiting resistor reveals that the green ones are fine, but all the red ones are all backwards. I’m glad I built only one board! I had to replace all 3 red LEDs with new ones, installed the right way, now they all work.

Next step! Install the CPU and it’s support connectors and load the bootloader. I switch to the hot air rework station for this. It’s possible to solder an ATmega chip with a soldering iron, but I’ll never be able to connect the upcoming UART chips that way. Your skills may be better than mine, I have to use the hot air. Anyway, the ATmega goes on, along with the 6 pin ISP connector and the 6 pin FTDI connector.

The next step is to load the bootloader. In theory? You can use the Arduino IDE for this. I, however, have NEVER gotten this to work. It refuses to use the Atmel ARVISP mkII due to driver incompatibility, and I’ve never gotten the “Arduino as ISP” method to work. I have no idea why, I have tried and tried. So I use Atmel’s AVR Studio to load bootloaders. I downloaded AVR Studio 5 (Geeze! Did Microsoft pay Atmel to bloat up the thing with Microsoft products? It’s HUGE!) All I want to use is the AVR programming tool, it’s under the Tools : AVR Programming menu. Specify your programmer (I use the AVRISP mkII) and you’re in.

This is, in my opinion, the easiest way to verify the chip works and get a bootloader onto it. Once you have AVR Studio 5 installed (You will likely have to upgrade the firmware in the AVRISP mkII) connect the Arduino to power, connect the ISP connector and go to Tools:AVR Programming.

Select the Tool, Device, and Interface on the upper left of the dialog. For this board, it’s “AVRISP mkII”, “ATmega328P”, and “ISP” respectively.

To verify that the chip even works, click the “Read” button under “Device ID”. The ID number of the device should appear. Click the “Read” button under “Target Voltage” and it should show you the exact voltage the ATmega is running under. If you can’t even get this far… there’s something seriously wrong with the part or the board.

There are 3 sections that need to be programmed for the bootloader to work, the bootloader itself, which is programmed in the “Memories” section, the Fuses, which are programmed in the “Fuses” section, and tje Lock bits, which are programmed in the “Lock bits” section. The “Fuses” section is where you can really mess yourself up… there is one fuse, SPIEN (SPI Enable) that enables the SPI part of the chip. It’s default is SET, but there is nothing stopping you from unsetting it and programming the chip that way… of course, the SPI is what is programming the chip, so if you disable it you prevent yourself from loading a bootloader onto it. Oops! Be careful. If you do that, you render the chip unusable. (Well, you can use “High Voltage Programming” to recover it, but that’s a bit hard to do with an SMD part.)

Program the Fuses first. Select “Fuses” and enter 0xFD, 0xDA, and 0xFF into the Extended, High, and Low registers respectively. That should set the following Fuses:

BODLEVEL 2V7, SPIEN checked, BOOTSZ 1024W_3C00, BOOTRST checked, and SUT_CKSEL EXTXOSC_8MHZ_XX_16KCK_14CK_65MS. All the rest of the fuses are unchecked.

Program the fuses with the “Program” button and reread the Device Id. The chip should still work. If it doesn’t, you’ve either bricked it by resetting SPIEN or have a bad oscillator.

Next, the bootloader itself. Under “Memories” you need the following file to be loaded under the “Flash” entry:

arduino-1.0\hardware\arduino\bootloaders\atmega\ATmegaBOOT_168_atmega328.hex

Where the file is will depend on where you put it when you installed the Arduino IDE. Use the “…” button to brouse around and find it. Press “Program” to program the bootloader.

Finally, the Lock bits to protect the bootloader from accidental erasure. Go to “Lock bits” and enter “0xCF” in the LOCKBIT register. That will set BLB1 to  LPM_SPM_DISABLE, and NO_LOCK in the other two fields. Click “Program”. You’re done!

You can now run the Arduino IDE and program the board using a USB to FTDI adapter. Here is where I ran into a problem. I had added c16, a .1uF cap to the reset line as per an Atmel Application Note to provide ESD protection on the reset line, but that’s not compatible with the auto-reset feature of the FTDI interface. I had to remove c16 from the board.

The next step was to solder the UART chips and their connectors onto the board and test them using the ArduNet self diagnostic. (If you connect an ArduNet cable between the two UARTS, it will verify each UART against the other.) Success! Both UARTS work. All that practice I got soldering and desoldering UART chips on the first prototypes paid off!

Finally, I soldered all the remaining headers onto the board.

All that remains is to clean the board. That’s easy! All the flux is water soluble, so all I need is a hot water bath. Filling the Reflow Skillet with water and turning it on to low works great for that. With the water just below boiling, and holding the board with a pair of needle nose pliers at one of the mounting holes, a toothbrush makes fast work of the flux remaining on the board.

Ardunet Verson 1.1

Here’s a picture of the hand soldered board. It came out great!

There is one fairly big problem with the board, and I can’t believe I didn’t see this coming… the UART and power connectors reach all the way up to the Shield board, making it problematic to have through hole parts on that section of the Shield. Oops! I’ll just have to deal with that.

Well, I spent today pounding my head against the wall that is the Beagle Board xM. I got one by UPS this afternoon, and have been trying to make a MicroSD card image for it since then. Yes, I know it comes with a test image of Angstrom, and Angstrom is what I’ll use on it, but I don’t want to connect a display and keyboard to the Beagle Board, It will be “headless” in use, so I want to do this right, by figuring out how to make the most effective MicroSD on a development system, and then plugging it into the robot.

It’s really complicated! And I don’t have “real” internet… I have satellite internet. (Remember, my top secret lair is deep in the Missouri Ozarks. Real Deep, so deep I have to have satellite internet!) So I can’t download Ubuntu all at once. LOL.

Anyway, I was pondering my predicament and I suddenly thought of something.

The common use for range detectors is to place them in a cone looking forward of the robot. I contend that that’s useless, that the info you get back is not really useful for avoiding collisions.

But. What if you oriented them to point to the sides? You’re not looking for obstacles, you’re looking for the curb, but ONLY in pipe sections where you know a curb should be on one side of the robot or the other. If your nav system is working, you should be traveling roughly parallel to the curb, making measuring it’s distance from the robot very accurate. If you knew in advance (And you do… the curbs don’t move.) how many feet you needed to be from the curb while you were traveling to the Arch, it would be easy to use a side scanning sensor to detect the curb and use that data to adjust your heading and distance from the curb.

I thought of this when I was looking at a picture of Pete Doktor pointing out the arch on the course. The curb was right there. And it was perfectly parallel to the robot’s course leading up to the arch.

Hmm. Use the terrain to your advantage. Don’t think of the course as a “black box” that you have to use a brilliant collision avoidance routine to navigate.

Oh, and of course, Once I crack the Beagle Board, I’ll post my findings.

I’ve researched the gyro and the accelerometer on the IMU enough to at least figure out how to get data out of them. The data isn’t accurate as I’m not bothering to set up the parameters on the chips beyond the minimum needed to get data. As I delve deeper into the intricacies of using the IMU as part of the navigation system, I’ll research it further.

However, one thing is clear right away, and that new knowledge will likely steer the direction the IMU design goes. This new knowledge is that the IMU is capable of a much higher data sample rate than is practical to transmit to the Linux computer for processing. However, there is a easy solution! Adjust and filter the raw values locally at the sensor. The easiest way to do this is to use a sensor that has a dedicated processor just for this purpose. Pololu has one that looks really good:

The big gun is the CHR-UM6 Orientation Sensor This one looks like the whole solution, you even get an ARM Cortex processor that takes the samples at 1 KHz and shoots out Quaternion and Euler values that are ready to use over TTL serial. Nice!

The other item Pololu has is a 9 degree of freedom IMU that needs to have the data processed by the cpu it’s connected to: MiniMU-9 Gyro, Accelerometer, and Compass I ordered a sample of each so I can evaluate all options.

There are other IMU systems, but I think these are sufficient to research at the moment.

So I have the minimum data coming out of the Navigation Shield: Compass heading, temperature, Gyro X,Y,Z, and Accelerometer X,Y,Z. It’s not really useful data at the moment, but it’s there. The next step is to build the basics of the T1′s data processing system to route that data to a Linux process where it can do some real work.

The T1 combines a group of Arduino boards called “Ardunet” boards that have a peer to peer network built into them, onto these go the shields that connect to the T1′s hardware. At the minimum, I see the need for 3 different shields: The gateway that connects to the Linux computer, the Navigation Shield, and 2 Motor Control Shields for the brushless motors and steering servos. The Ardunet connects to the processes on the Linux computer through the Gateway Shield, and those processes control the robot.

First, the Ardunet board. The gerbers for this board are in Sparkfun’s “BatchPCB” service, with no markup on my end. the link to the board is: http://batchpcb.com/index.php/Products/63219

You also need a schematic:

Ardunet ver. 0 schematic

Note that this is the prototype board, I’m currently working on a NEW board and will post the full info on it (including the Eagle files.) when it’s ready. The prototype has been modified slightly from this schematic: the battery charger chip is removed as well as the LED and resistor associated with it and VIN connected directly RAW. Here is a picture of the prototype board:

Prototype Ardunet board

And here are the two modules I have so far (Gateway and Navigation) with the shields on them.

WiFly Gateway and the Navigation shield.

The Navigation Shield is documented in this post: Navigation Shield And here is the schematic for the button and LEDs located on the WiFly Shield:

Wifly Gateway Shield

The two Ardunet boards connect together through the UART1 connector on each board, the schematic for the interconnect cable is:

Ardunet interconnect cable

Note that the TX  RX lines swap, as do the /CTS  /RTS handshaking signals. All the signal levels are 3.3v serial TTL. The transmission rate is variable, but normally is 460,800 baud. I’ve been experimenting with 6 pin ribbon cables for the comm cables, and as expected, they’re iffy. They work at lengths up to 3 feet, but error out once in a while. I’m working on automatic recovery, but the smart thing to do is use shorter cables made from discreet wires. The other UART connectors on the boards are intended to extend the Ardunet by daisy chaining more boards together. On the Navigation board, I stopped the chaining by dedicating UART2 to the GPS. But on the Gateway board, UART2 will connect to the first Motor Control Shield, and it… to the second.

Now for the software. There are 4 software packages, each build either an Ardunet Sketch or a Linux Process. Note that these are in NO WAY finished programs, they are works in process, and only serve to show current status. These links download .zip packages containing the code:

WiFly Gateway This is the Arduino sketch for the Ardunet board that carries the WiFly Shield.

Navigation This is the Arduino sketch for the Ardunet board that carries the Navigation Shield.

message_hub This is the Linux process that carries the message traffic between Ardunet boards and Linux processes that actually do the work in the robot. To compile it, use the Makefile that’s in the package.

t1_nav This is the Linux process that receives the test nav info from the Navigation Shield. It’s just a shell at this point, included to show how to get the data to a Linux process for processing.

The system essentially consists of two networks connected together by a bridge between the message_hub and the WiFly Gateway. I’m using WiFly for this right now because it allows the Ardunet boards to be physically separated from the Linux computer, this is very useful for testing. I’ll eventually implement the link as a hard wired connection.

On the Linux side of the bridge, the processes communicate with each other and with the Ardunet boards over TCP/IP, sending packets that contain status and routing data. The packet format is as follows:

[esc] [esc] [length] [type] [SID] [DID] [Data section, up to 57 bytes]

The header of the packet is made up of the first [esc] to [DID] and contains 7 bytes of data. Each element is one byte long except for [type], which is an unsigned 16 bit integer. all data is sent in Intel byte order, LSB first. The two [esc] bytes (literally ESC, 0x1B hex) at the beginning serve to isolate out “bad data” that may be on the line prior to receiving a valid packet. The [length] field in the header is the length of the data section plus 4, so it’s all data after the [length] field up to the end of the packet.

The [SID] field is the Source Id. It identifies the sender of the packet.

The [DID] field is the Destination Id. It identifies the intended recipient of the packet.

SID and DID are bytes, with the Ardunet boards starting at 1 and going up, and the Linux processes starting at 255 and going down. This allows for 127 addresses on either side of the bridge. By default, the message_hub is id 255, and the Ardunet Gateway is id 1. However, there is nothing stopping you from having more than one message_hub or Gateway. In theory, it’s possible to construct an Ardunet / Linux network of global scope.

The [Data section] is the payload of the packet. Sometimes, though, no data is needed. A packet that initiates an action just be being received needs no data beyond the 7 byte header. Hence, the minimum packet length is 7 bytes.

Packets can contain bytes (8 bit unsigned int), words (16 bit unsigned int), or strings (char strings that are prefixed with a length byte). Strings are transmitted as the length of the string +1 byte containing the length. To insert data into a packet, use the corresponding packing function, to read data once the packet arrives, use the corresponding parsing function.

The protocol is implemented in the “CommManager.cpp and .h” files on the Arduino side, and in the “lxsock.cpp and .h” files on the Linux side.

To actually run the Linux side, you need a runtime directory where you place the two executables after they’ve been compiled, and three other files: You make these files with a text editor, I use “nano” that came with my Linux distro. Be sure to set the two shell scripts as “executable”.

The first file is the configuration file used by both message_hub and t1_nav to initialize themselves. It’s called “hub_config” and goes like this:

[startup]
debug=0
log_dir=/home/bsellers/core/runtime/logs/
data_dir=/home/bsellers/core/runtime/

[message_hub]
addr=192.168.1.100
port=1200
maxusers=256

The “data dir” field does nothing. The others need to point to valid directories on the Linux machines or a valid address/port for the message_hub’s listen socket. As you can see, I just have the system running in my home directory.

The second file is called “start” and is a shell script that starts the two processes in the background:

#!/bin/bash

echo “Starting Message Hub”
./message_hub &
ps -ea |grep message_hub |grep -v grep

echo “Starting T1 Navigation”
./t1_nav &
ps -ea |grep t1_nav |grep -v grep

As it starts each process, it echoes what it’s doing, and reports the pid of the now active process.

The third file is called “stop” and kills the processes. It is also a shell script:

#!/bin/bash

echo “Killing Message Hub”
killall message_hub

echo “Killing T1 Navigation”
killall t1_nav

Logs are started in the directory specified in “hub_config”. I use these logs extensively to watch the processes run. The logs are named after the process and the date the log was started, if the date changes while the process is running, it automatically starts a new file. So, for example, logs made for the t1_nav process today go in a file called “nav.120104″. To view new entries as they are put into the log for that day, use the command “tail -f nav.120104″ from a terminal.

While I’m working on the system, I run a set of 4 terminals on my Windows computer using Tera-Term connecting with SSH. The first terminal I point to the the source directory I’m currently working on so I can compile, the second points to the runtime directory so I can run the start and stop scripts, and the last two are tailing the log files in the logs directory. I edit the code on my Windows computer using the Code::Blocks open source IDE and copy them over prior to compiling with samba. I use a simple batch file to copy the files. I keep a window up pointing to the directory where the files are so I can just double click on the batch file to copy the files over. The batch file looks like this:

cp *.cpp w:/t1_nav
cp *.h w:/t1_nav
cp Makefile w:/t1_nav

“w” is a link to the shared directory on the Linux computer. If you have been paying attention, you’ve probably guessed it points to C:/home/bsellers/core on the Linux machine.

My Linux machine is a bone stock Fedora 14 distribution with the following extra packages installed: Samba and hostapd. Samba was the biggest pain to install, but if you google “Fedora 14 Samba” you’ll eventually find what you need. I also had to disable the firewall… Yeah, bad. I know. I’ll eventually figure out how to get it to work, but the machine is safely behind another firewall on a subnet. There are no routes from the internet to my 192.168.x.x intranet.

If you’re brave enough… or foolish enough… to download that code and build a system, then I salute you, sir or madame! Here’s how to make it go:

Configure Samba (Or use sneaker net to get the files to the Linux machine… you could even just put them there in the first place, it’s your choice!) and get the source files into directories on the Linux machine.

Compile them and copy the compiled files to the runtime directory you set up. Notice that in the Makefiles, there is a “make install” section that copies the files to the runtime directory. Don’t forget to create the three extra files you need in the runtime directory… hub_config, start, and stop. (See above)

Run the start script. Note! You may need to type ./start instead of just start… depending on how your shell is set up. If they start… (The start script reports pids generated for the processes.) then go to the logs directory and start log tails. (See above.) You’ve just built a robot core capable of enormous expansion! Welcome to my world. This rabbit hole is very deep, and we will explore it!

Home again, home again, jiggity-jog!

For the second time in December, I had to drive all the way from my top secret laboratory strategically located deep in the Missouri Ozarks to Virginia, where I had business I needed to attend to. And attend to it I did!

1100 miles each way is a lot of driving! That gives me a lot of time to think… One of the issues I pondered this trip was the need for “Object avoidance” in the 2012 Sparkfun AVC competition. I also worked on a way to make a self driving car… but that’s for another day!

My conclusion? Object avoidance is like being able to drive in reverse. If your robot has to back up to get off a curb, you’ve already lost. Also, If your robot can’t follow its predetermined course well enough to require some kind of object avoidance system, then you should be spending the time working on better navigation rather than doing object avoidance.

In a word, (well, 5 words.) You don’t need object avoidance.

There is one exception to that: The hoop. Going under the hoop was a pure crap shoot last year. You HAVE to have at least one run go under the hoop to be competitive, and if you’re lucky, it’ll be the last run when you the robot is tuned to go as fast as it can. So a hoop detector would be a great idea, not only because of the 30 second reward you get, but the fact that if you can detect the hoop, and know when you are in it, you are GUARANTEED to have a hard position fix within 18 inches of your true location. The only other time you have that is on the starting line.

But avoiding barrels? Don’t run into them in the first place. What about other robots? Ask yourself, why are there slower robots in front of you? Well, there usually aren’t.

All of the things you need to avoid on the course like barrels, curbs, potholes, etc. are fixed in place. They will be in the same spot when your robot runs as they were when you walked the course setting up your robot’s path around the building. As such, your robot’s ability to navigate the course you set out for it far outweighs any ability you could give it to avoid obstacles.

What about the starting line? 5 robots all driving towards the first waypoint at once? Don’t you need to have it then? No. There are only 5 robots. Statistically speaking, 2 will veer off wildly and crash before the first turn (Or not even get off the line.) If one of those hits you, it’ll be a T-Bone you couldn’t avoid anyway. A third one will be really slow. If your robot is a contender, it will be one of the remaining 2. One of those, the faster one, has nothing to fear. So, the other has… nothing to fear either.

In the worst case scenario, you’ll be grouped with 4 other contenders, and all 5 robots will have working navigational systems capable of actually circumnavigating the course, but at slightly different speeds. Not much danger there, either.

As such, 50% of winning the competition is building a navigation system that is flexible enough to program the robot’s course during the initial walk through such that it avoids all obstacles by as much of a margin as possible, and accurate enough so the robot can just charge through the course blind, monitoring only it’s computed position and course it wants to follow. the other 50% is going through the hoop.

In order for going through the hoop to matter, you first must be able to reliably navigate the course. If you can navigate the course at a high speed on all three attempts, then you have a much higher chance of getting lucky and having one of the attempts go through the hoop. If you can actually detect the hoop, then you not only greatly increase your chance of going through it, but you increase your navigational accuracy at the same time. All of this is greatly improved by having the most accurate navigation fix to begin with.

So I constructed a strategy to guide my development of the navigation system.

First: Build and test the navigation system first. It’s the most important part of the robot… heck, if push comes to shove, you can buy an off the shelf 1/10 scale racer any time and drop your navigation system into it, but you can’t buy the navigation system that will steer it over the finish line.

Second: Test against a fixed reference point. Instead of driving around a parking lot and plotting where you THINK the robot is, run the robot on a fixed track and compare where the robot THINKS it is to where you KNOW it is. My first test platform will be a simple circular course, made by spiking one end of a 10 foot long pole into the concrete floor of my barn and putting a one wheel robot on the other end. The wheel drives it around the circle at a fixed speed. Since I know exactly how big the circle is, I know exactly to what extent the navigation system deviates from the actual course. And since the circular course starts and stops in exactly the same spot, long term accuracy is measured by going around multiple times.

Third: Don’t just use way points. Control the entire path around the course. To do this, I’m going to make a process for the Linux controller that builds the robot’s course out of “Pipe segments”, like it was a virtual pipe construction kit or something. I’ll write an application for my smart phone that lets me click on the pipe piece I want, and the robot will place that segment in it’s path and follow it, stopping at the end of that section and awaiting the next piece of pipe from the smart phone. In that manner, I can position the robot for optimal clearance of the barrels, curbs, and potholes on the course. My visualization is a “pipe” built out of 10 foot sections that are straight, turns, or jogs. (A ‘Jog” is when you steer the front and rear wheels in the same direction, allowing the robot to drift left or right without having to change it’s heading. Remember, the T1 will have 4 wheel steering.) Once the pipe path is complete, the program “compiles” it, computing the setpoint speed for every inch of the course by knowing the max allowed speed for each pipe segment (slow down for sharp turns, etc.) and applying acceleration and deceleration in the sections between turns. At race time, I just enter the max speed I want (in percent) it to run. The pipe is compiled, and I’m ready to press GO.

That leaves hoop detection. I want that! But I don’t clearly see a way to reliably get it to work. I have… one crazy idea. One I think is worth pursuing: (Places pinkie to corner of mouth…) Optical Recognition. The Beagle Board xM has a camera port and an on board mpeg-4 encoder. The hoop is red. It’s always 3 feet wide and oriented perpendicular to the robot’s axis of travel. (Yay 4 wheel steering!) It’s always sitting on flat ground, the same flat ground the robot is traveling on. So… grabbing one strategically located scan line from the camera image and looking for red pixels should be all you need  to do. If 2 groups of red pixels are on the scan line about at the distance you expect the hoop to be… you’ve found it! The hoop is already on the prerecorded pipe path the robot thinks it’s on, so it’s a matter of correcting the theoretical position to the actual position revealed by the found hoop. At the point at which you go under the arch, you’re in the pipe 5 x 5 at a known accurate location.

Today I’ll build the shield that holds the navigation sensor suite for the T1 robot. That’s the GPS, the IMU Breakout, and the Compass Breakout. The shield is intended to go on an Ardunet Arduino, which is an Arduino compatible board with two SPI UART chips integrated onto it. The UARTS, in conjunction with a software library form a peer to peer network of Arduino boards. The Ardunet board I’m using now is the first prototype. I’m laying out the second prototype of the board and will document it soon. The Ardunet is featured prominently in the T1, connecting all of the robot’s systems to the Linux computer.

Components for the Navigation Shield

Here are the components of the Navigation Shield. I’ve got a Sparkfun Protoshield, a GPS Module, a Compass Breakout, and an IMU Breakout. The 6 pin header sitting on the board is where the cable harness connecting the GPS module goes. The two small header strips with all but two pins removed are little standoffs I made to hold the unsupported ends of the two breakout boards flat. I’ll super-glue them to the module when I connect them. If you look closely, you can see  that I trimmed the pin flush with the plastic body, as there aren’t any holes in the breakout there. The header to the GPS connects with 2 single pin jumpers to one of the SPI UART connectors on the Ardunet board below the shield.

Navigation Shield Schematic:

Building the shield is straight forward. I had to be careful which way the Compass and IMU were oriented on the ProtoShield. The X axis on the IMU and “North” on the Compass are aligned in the robot’s direction of forward travel.

Wiring side of Navigation Shield

This is what the wiring side of the Navigation Shield looks like after connecting all the wires. The two blue jumpers extending to the right are the TX and RX lines coming from the GPS’ connector. They connect to the RX and TX of one of the Ardunet UART connectors. I used the holes of an unpopulated button on the ProtoBoard to tie the jumper wires down and act as a strain relief.

That all went together fairly quickly. All that’s left is to solder a 5 pin right angle header to the GPS Module (See the link for a tutorial on soldering that, it’s really easy.) and building the cable that connects the 6 pin header on the ProtoBoard to the 5 pin header on the GPS Module.

On the GPS side, this is the 5 pin header and these are the pins.

On the ProtoShield side, I got the parts from Mouser Electronics. This is the header, and these are the pins. The mating right angle 6 pin header is this one.

Completed Shield and the Ardunet Board it plugs into.

There’s the completed Shield. The other board is the first prototype of the Ardunet board. The two 6 pin connectors next to the switch (top of the picture) are the network connections that form a peer to peer network with other Ardunet boards. On this one, I’m using one of the network connections (It’s just a UART) to communicate with the GPS.

Now let’s test it. I’m not going to write any actual software for it today, just enough to test the components to make sure it actually works.

First, the easiest. The GPS. It’s easiest because all it needs is 3.3 volts and it should automatically link in with the satellites and start spitting out NMEA sentences out on the serial line. All I have to do is to connect the USB Logic Analyzer to the Shield and turn it on.

This Logic Analyzer is the BEST TOOL EVER for working with the Arduino. It analyzes Serial, SPI, and I2C connections as well as really allowing you to see the timing of the signals on your project. It’s an indispensable tool.

The test setup

Here’s the test setup. It’s easy to connect the Logic Analyzer. One clip to ground, 2 clips to the serial lines, and 2 clips to the I2C pins (They use analog pins 4 and 5.) then you just set up the easy to configure software and you’re off!

Well, the GPS works great. Just sitting on my desk it locked onto 8 satellites (And I have a metal roof on this building!) and started spitting out NMEA sentences every 200 ms just like it’s supposed to.

Next up, the Compass. To test it, I used the sample Wiring code (Also works for Arduino.. It’s actually the same thing.) find the sample code here. Obviously, don’t use the Wiring board’s pinout. Use what I put in the schematic above.

That worked right away. Lastly, the IMU.

Hmm. It looks like the IMU is a bit more complicated than the Compass, more complicated than I’m willing to get into this close to Christmas Eve. I need to go to Virginia next week, but I’ll be back to work more on the code after that, and get the data sent to the Linux computer for processing.

Even though I have not posted these last 6 months, I haven’t been inactive. What has happened is that I didn’t like where the blog was going. While I think the Rover 5 platform is a fine platform for what it is, a small radio controlled robot… that’s not where I want to go. The other problem is that my house in Virginia simply doesn’t have the zoning for what I really need to do… which is set up a real machine shop so I can build real robots.

So I sold the house in Virginia, and moved to the wide open spaces of the Missouri Ozarks where I can literally build whatever I want. Then I founded a company, Tesla Robotics. The goal of Tesla Robotics is to research and develop Open Source robotics using the Linux and Arduino systems.

Yup, the icon of my vision, my inspiration, is Nikola Tesla. A man I consider to be one of the greatest engineering minds ever. There’s no way I can ever fill those shoes, but that doesn’t mean I can’t have fun trying! If Nikola Tesla had the tools we have today? Wow.

Here’s what’s going to happen: Both of my current projects, the Tron robot and the Eyeborg are dropped. Both used the Rover 5 platform, and that’s not doing it for me. It’s time to reach a LOT higher.

The new project is called the T1. Yeah, that means “Tesla One”. Ok, I know that’s not original. In my mind, it’s the first in a series of autonomous, fully Open Source robots that will explore just how deep this rabbit hole really goes.

What is the T1?

The T1 is an autonomous robot equipped with an array of positioning systems and powered by 4 brushless DC motors, one at each wheel. It will also have 4 wheel steering, GPS, IMU, 4 wheel optical encoders for Odometrics, and a Magnetometer for compass direction. It’s goal is to win the 2012 Sparkfun AVC held in Colorado on June 16, 2012. Here’s a rundown of some of the components I plan to use:

Control computer: It’s the same as in This post. I’m currently using a Giada Cube with integrated WiFi. I’ve pimped it out with 4 gigs of RAM and a 50 gig SS Hard Drive. Hmm. I can’t find a link to it on NewEgg to link it. Anyway, I’m running Fedora 14 on it, and the integrated WiFi is running in Master Mode using the hostapd daemon so it’s it’s own WiFi Access Point. This computer is overkill, but it’s the easiest way to drop a Linux control system into a robot. Eventually I may investigate things like the Beagle Board for it’s replacement. But for the T1, this is the computer I plan to use. In future posts, I’ll delve into it’s configuration and how to set up your OWN Linux computer for embedded robotic applications.

Motors: Originally, I specced some wimpy 1/11 and 1/7 horsepower 12 volt motors for the T1. Those didn’t cut it. They were just too big and heavy to practically use in a 4 wheel drive, one motor per wheel robot. My plan originally was to power the robot with 12 volt lead-acid motorcycle batteries. Heh. That didn’t roll very far. This is my current thinking: This thing is a beast: Neodymium magnetics, 3 phase DC brushless, and it’s reasonably priced at only 33 bucks each! This motor is an “Outrunner” type, meaning the magnets are on the outside and the stationary coils are on the inside. There are also more magnets than coils, so the motor is constantly “out of phase” with one of the coils and the controller has to keep up by switching the current to the in phase coils. We’ll go into that when we research the motor better. Expect a motor to be taken apart and fully explored in a future post.

Batteries: What was I thinking? Motorcycle Batteries? I’m turning to Turnigy again on this one. The electronics package (Consisting of the Giada Cube computer and all the Arduinos controlling the motors, sensors, etc.) is powered by this battery The 25C part is overkill as the Giada requires 1.8 to 2.2 amps at 12 volts. The Arduinos… MUCH less. In testing, the Giada runs with as little as 11.25 volts, giving a 1 hour life on a single charge. That will work fine. The motors are more power hungry and I plan to use these. I expect I can use 2 of these total, running 2 motors on each one. Total weight of batteries? 4 pounds.

Motor Controllers: Arduinos networked to the Linux computer. I’m working on the third prototype now. The first prototype is in the first link above, and the second was a custom Arduino board with two SPI UARTS on it. The third prototype, which is the T1 candidate, will be documented in a future post. The actual motor driver will be a shield attached to that board. I’ll design it when I fully understand the brushless motors.

GPS: Watching the last AVC, and reading blog posts about the one before, two things were clear: First, don’t scrimp on the GPS. Second, don’t rely on it as your sole position indicator.

IMU: I’m not convinced I need an IMU, but I’ll add one as insurance. The need (Or otherwise) will come out in testing.

Magnetometer: This is a critical component. In conjunction with the optical encoders at each wheel, this forms the most accurate millisecond to millisecond position measurement in the robot.

Last year, Team Tobor won the AVC. They won the year before that, too. So I studied scott’s blog and went to school on it. I’ll be using the enhanced Kalman filter as he did, integrating all my positioning data into one “Best Guess” result to run the robot.  Unlike Tobor, T1 will have a Linux Computer to do the heavy lifting, enabling the servo solution for all 4 wheels to be computed independently with no CPU overhead problems. It will also have a similar power to weight ratio to his Tamia Grasshopper, but greater stability due to the 4 wheel drive and much bigger contact patch for the tires. My thinking is that my heavier, more powerful robot will be more stable at speed, giving it an advantage.

It’s on! The 2012 AVC awaits.