Jul 282011
 

— Update: Digilent got back to me and they are sending out a replacement board. Very quick and positive response. Way to go Digilent! —

I was planning on reviewing and the new chipKIT Max32 board and comparing performance to the Arduino Mega 2560, so I downloaded the modified Arduino environment and downloaded the blink demo to the board. Everything seemed to be OK, but there was no blinking light. This is pretty much the simplest program on the Arduino and all it does is toggle digital pin 13 high and low with a two second period. Most Arduino boards have a LED on pin 13.

Time to debug.  Probing around, starting at the socket for pin 13, I saw that the digital line was toggling, but I was getting no LED action. Let’s take a look at the chipKIT schematic. Here is the LED driver on the chipKIT. They use a transistor to drive the LED instead of driving it directly as on the Arduino.

The chipKIT LED driver for pin 13. They don’t load down the I/O pin. Nice.

OK, so let’s see what’s going on over at the LED driver.

Q2! Where are you?

What a bummer. Q2 is missing! I sent a note off to Digilent’s tech support and got a response in just a few minutes. I’m hoping that this is a one-off mistake and that they aren’t saddled with hundreds of bad boards. Did somebody forget to load a reel? I wonder who is making the boards for Digilent.

Anyhow, how about some benchmark action?

Let’s look at the time required to invert a 5×5 single-precision floating point matrix. The time for an Arduino Mega 2560 is 3.2 ms while the chipKIT only takes 260 us. That’s a speed up factor of 12.3. Not too shabby.

My intention for the chipKIT board is to upgrade Tobor’s brain for next year’s Sparkfun AVC with minimal effort. I can drop a Tobor shield onto the chipKIT, keep all of the Tobor code unmodified, and add a ton of processing headroom. That’s the theory, at least. Not all of the Arduino libraries are working on the chipKIT. Currently, (I think) I2C, interrupts, and servo need work. 

 Posted by at 5:00 PM
Apr 182011
 

So my obstacle avoidance last year was a total last minute hack. This year, I left things to the last minute again, but I still have time to replace a major hack with something that’s at least reasonable. The jittery steering when obstacle avoidance is turned on is due to the fact that I’m feeding the scaled sensor values directly into a steering offset. Noise in the sensors ends up as noise on the steering servos. And the sensors are pretty noisy.

I’ve implemented a simple first order system to smooth out the obstacle avoidance error signals and it seems to work well. The other thing I’m adding is a bank of pots on the outside of the car. I’m going to use them to adjust some of the system gains so I can run the car, stop it, turn a knob, and re-run the car. I’m hoping that this will increase my iteration rate so I can dial in on a collection of gains that work. Once I have it working, I’ll take the pot values and hard code them into the car. The more system tuning I can do without re-compiling, the better.

Time for bed.

 Posted by at 9:10 PM
Apr 182011
 

Sarah and I drove down to SFE HQ on Sunday afternoon. I was hoping to spend most of my time optimizing the new obstacle avoidance system that uses three Maxbotix LV-EZ4 sensors along with the Sharp IR range finders from last year. Unfortunately, the trouble started as soon as we got there.

First off, my Mac didn’t go to sleep when I put it in my bag for the trip down the hill, so it was toasty hot when I pulled it out. I gave it a reboot and it seems to be fine.

Then I started putting the lid back on the bot and loaded up some test code. I smelled burning electronics and sure enough, there was a tendril of smoke rising from one of the Maxbotix sensors. I cut power and checked everything. Nothing seemed wrong so I replaced that unit with a spare and everything seemed to work.

That component just above the ROHS label got pretty hot. As a bonus, you get to see the ultrasonic transducer. I’m guessing that the little dish on top of the piezo element sets the beam width.

When I got home I shot an email off to Maxbotix and they are going to do a replacement for me and try and figure out what caused the problem. So far they have no idea about what would cause things to fry like that. Quick response!

Anyhow, I started off with an attempt to repeat last years run using the same code, parameters, and waypoints. I might have made it around the building if all the cars were gone, but it was not an impressive test. Turing on the sonar system just resulted in jittery steering.

Finally, I gave up and decided to do an open loop drive around the course. One lap hugged the inside and the next lap followed the outside edge of the clear course. Here’s what the output of the Kalman filter looks like.

Position estimates form the car’s Kalman filter. Red dots indicate locations where the car velocity was zero. 

I stopped at each course corner, places where curbs stick out, and the two lamp posts (near the lake and turn #1 and the one in the northeast corner of the parking lot). From the size of the red blobs, you can get an idea of my Kalman filter performance (or lack, thereof). I think it could use a lot of improvement. Take a look at the track on the right side of the graph: the inside track crosses over the outside track!

I’ll have to go back and do a few more runs where I log the sensor data as well as the estimator state output. I think I can improve things.

Finally, there were quite a few other teams there testing. Nobody had much time to chat because we were all too busy chasing bugs. I’m looking forward to trading stories at the Dark Horse after the AVC.

 Posted by at 2:08 PM
Jun 162010
 

I got a question about the speed control and motor on my robot. Here are the details:

  1. Motor. The Grasshopper comes with a stock Mabuchi 380 motor instead of the 540 motor that’s typical in most 1/10 RC cars. The 380 motor is plenty fast for the AVC contest and as a bonus, you get much longer run times. This was a big selling point back when these cars ran off of low capacity (by today’s standards) NiCd packs and charging took a while. 
  2. Electronic Speed Control. The new Grasshopper reissue kits come with a Tamiya branded ESC. It’s a relatively low-end unit, but it works fine.
  3. Motor interface. I wanted to leave the car essentially unchanged so my computer talks to the steering servo and ESC by generating PWM signals just like the RC receiver does. I used the Arduino Servo library and the commands to set the motor speed are generated in an open loop fashion. In fact, I set the ESC command once and the car will go until I switch to manual control (or run into something). The actual servo values that I use to set the car speed were determined by some brief trial and error.
The Arduino Pro Mini uses an interrupt routine to read the PWM from the third channel on the RC receiver and based upon this input outputs a high/low signal that controls a multiplexer chip (74LS157) that routes the desired PWM commands (computer/remote) to the ESC and steering servo.
 Posted by at 1:44 PM