Friday, June 29, 2012

Prototyping Circuit Boards


Someone recently turned me onto prototyping circuit boards from dipmicro.com and wow! Awesome!

(So you know, I am in no way affiliated with dipmicro, I was just really impressed)

Yes, that's right, I'm excited about prototyping circuit boards. Let me tell you why, then let me show you my ATtiny13 ESC adapter circuit I built for Pokey my Robot Firefighter.

Monday, June 18, 2012

2012 Autonomous Vehicle Competition (AVC)

Data Bus. Photo: Susan brady
The Dark Days Before

A few days before the competition my chances were in the toilet. My robot kept crashing into curbs, totally inconsistent, unable to navigate the course at any kind of decent speed. I flashed back to the embarrassing AVC disaster of 2011.

A year of slaving, theorizing, simulating... all seemed in vain, a waste of time, zero progress made. Then on Thursday I made a discovery: the entire problem traced to the heading estimation at the start of the run. I changed the code. And, little did I know, everything changed....

Saturday, June 16, 2012

AVC: Ready to Race!

Fellow AVC competitors: Good Luck!

(I know I'll need a fair share myself)

Thanks to all for the well wishes, advice, input, comments, and more over the past many months. It's all been a big help on this very long journey.

For those of you that want to tune in, Sparkfun is doing a live stream of the event. Check their website.

I'm pleased to say that a minor miracle occurred on Thursday and the changes I made helped. More on that later (I'd rather keep it under wraps until after the competition).

Unfortunately I've run into some snags tonight, primarily with I2C communication between the mbed and the camera board as well as the IR ranger board so no camera and no IR rangers tomorrow. I wasn't able to figure out what's wrong; I'm just too worn out and crumpled under the pressure.

I've added a revised cow catcher / deflector / prerunner bar thingy to Data Bus to hopefully increase its chances of bouncing off of barrels and jumping over curbs versus simply crashing.

Thursday, June 14, 2012

AVC: Still Doomed

A messy workplace means a messy mind... 
Things are going just peachy. Lesson learned: testing in similar conditions to the race location is crucial.

I had tested my robot on a small scale course, half that of the race course. I didn't test the robot driving between buildings. Here's what I mean....

Wednesday, June 13, 2012

AVC: Test Runs, Propeller Serial to I2C


Test runs went a little better last night. I went in a little earlier tonight and left earlier too. The drive in was a little spooky with the smoky haze from the fire near Boulder.

The good news? The robot made it around twice in a row! However, during the last several runs the robot was back to drifting into curbs. I'm still analyzing why and what I can do to improve the estimation.

Meanwhile, on the obstacle detection front...

Tuesday, June 12, 2012

AVC: Midnight Hacking


As the days count down to the Sparkfun AVC, I thought I'd share a little bit of my insane world with you. Things are going just ducky right now.

I drove up to Boulder last night to do some more trial runs. At 10pm. I had planned to try my approach of smoothing out the turns to see if it would help.

Of course, I forgot to compile the code just before I left. So that's bad. But I'm now finding out that the code I was going to compile had an evil bug lurking within it. So it's good that I forgot.

Had I brought that code to Boulder, the robot would've followed a swoopy, loopy path, like this... so... pretty... the gentle curves of failure...

I had made one little change to a variable normally used only for logging... not realizing that the vital steering routine depended on it for calculations. Really? What idiot wrote this code?!

The number of days left before a deadline is inversely proportional to

  • the number of bugs introduced, 
  • the difficulty in accomplishing anything, and 
  • the time required to do even the most rudimentary tasks. 
  • It's also directly related to the success rate of anything undertaken.

So I have, full force, entered a crazy-zone, the kingdom of Murphy, who's Law makes sure not even the tiniest little thing goes right, so as to wear down every last nerve and further shred every tattered semblance of sanity to which I cling with feeble, keyboard-worn hands that regularly introduce more problems than they solve.

Ah, good times. You should try entering this AVC thing.

But I will not be beaten that easily. Nay, I am not going down without a fight. I shall bend this robot to my will. I shall unleash the rubber chicken charms to fend off evil bugs, and I am going to kick this gyro bias problem to the curb. The very curbs that Data Bus keeps crashing to.

So there.

Monday, June 11, 2012

AVC: Weekend Fiasco and Doom


The weekend's testing had ups and downs. In balance, I'm doomed.

I'm not giving up but basically what happened is that on Saturday, I crashed more than I made it around. I did make it fairly consistently through the first 3 turns. Going into Sunday I had a tiny bit of hope that I could fix what I thought was the problem: gyro bias. I was wrong. The robot never made it past the 2nd corner. But I think I know what's wrong. Maybe.

Friday, June 8, 2012

AVC: Scrambling and Hacking

This week I added obstacle (barrel) detection sensors onto Data Bus. That's pretty much the same thing I was doing in the final weeks before the 2011 AVC except this time the sensors are sending back good data. At rest. Moving is another story.

I'm sort of laying track in front of the train, now. I've long since used up the careful planning that went into the rest of the robot. Now it's hack time with prototyping boards and a rats nest of wires jammed in next to the somewhat neater existing installation.




I've mounted two very long range Sharp GP2Y0A710K 550cm IR sensors and a Maxbotix LV EZ1 5m sonar ranger. I've built an Arduino-compatible prototype board to read analog voltages from each ranger and report back through I2C to the mbed. The code on both sides is written and appears to be working properly.


What isn't working is the moving sensor data. The IR rangers aren't putting out anything usable, just a lot of spikes. The sonar is dropping out, bouncing between what might be a valid signal and 0. Point being, there's clearly a lot of work to do on the obstacle detection system.


As for machine vision, the AVRcam is now mounted on the Bus and I've written a serial-to-I2C interface using, of all things, a Parallax Propeller (the ATmega328P version didn't work out). Now I just need to etch and populate a board so I can start collecting data and figuring out what I can do with it.

With this menagerie of microcontrollers, maybe my robot will win for "Most Kludgey" or "Biggest Mess of Microcontrollers on a Single Robot". I've got an ARM, a Propeller, and three ATmega processors. Does the Sparc processor on the Venus GPS count?

The last and hardest parts (as if just getting usable data weren't hard enough) involve fusing all this data to reliably detect an obstacle and reliably ignore non-obstacles, then take evasive action to avoid collision.

But hey, I've got a whole week to perfect it in addition to fixing my steering and navigation issues and whatever other myriad bugs and problems crop up. No problem...

Tuesday, June 5, 2012

AVC: My Steering Algorithm Sucks

Sunday testing went... um... sub-optimally.
The latest Data Bus update is that I'm hosed if I don't get the robot navigation nailed in the next day or two so I can work on barrel avoidance. The Sparkfun AVC is in less than two weeks.

Here I thought I had this clever little steering algorithm that worked oh so well. As it turns out, it sucks rocks. The robot keeps driving into curbs.

It even knows full well that its going off course, but it doesn't correct its course.

Strange? Yeah.

Well, here's what's going on...

Friday, June 1, 2012

AVRcam Resurrection

AVRcam right, my SMT version lower left, OV6620 camera.
If you've never heard of it, the  AVRcam tracks multiple color blobs, up to 8 colors simultaneously, at 17fps. It uses an ATmega8 processor. By contrast, the CMUcam1 with a 75MHz SX28 only tracks a single color and a single blob at 17fps.

John O., maker of the AVRcam, was kind enough to send to me what I believe to be the last unpopulated AVRcam on Planet Earth. So don't bug him for more. Meanwhile, I've gotten it working and created a much smaller SMT version.

Wait a second... What?!  An ATmega8 with 1K of SRAM running at a molasses slow 17MHz spanks the snot out of the famous, lauded, widely used CMUcam and it's 75MHz processor?!

How is that possible?!