pathfinder

Thanks to John for pointing this out. c|net came and covered the Maker Faire, and we've got a few seconds of our car running the laps. The video timer counts down, but check time 2:25 (click the image for the video page):

Posted by Rick at 10:25 PM | Permalink | Comments (0)

Our professor (Ron Fearing) did a very nice thing for us tonight after Round 2: he took us all out for pizza. Fairly rare (for a prof. to do so), and very nice. Thank you, professor!

Posted by Rick at 12:22 AM | Permalink | Comments (0)

Sigh. We missed first place by about 0.6 seconds. We had a lap time of 43.9x seconds, the other guys were 43.3x (something like that).

Starting at around 1pm I re-tuned the sensor board, and re-wrote the linearization code to compute 1-over-right minus 1-over-left, and just tweaked the values 'till the car did something right. There was still no time to add the derivative term.

We might've been able to run the last lap a little faster, but we just ran out of time to do so.

So, next steps are: 1) catch up in all my other classes (HA!), 2) prepare for Natcar. Sigh.

Posted by Rick at 09:46 PM | Permalink | Comments (1)

Awesome. Highlight of our day.

We asked them to bless our car, so Jamie rubbed his head on it and they all signed the MCU board. We're sure to win Natcar now:

Many thanks to Bobby for manning the fort while we went to play!

Posted by Rick at 01:15 PM | Permalink | Comments (1)

Charlie and I (almost) finished setting up the track a while ago. I'll post pictures of the space, and tomorrow a better entry showing the booth.

Posted by Rick at 08:06 PM | Permalink | Comments (0)

Okay, I've been beating my head against the BlueRadios wall all weekend, and I think I finally came up with enough of a solution.

Sending Telemetry

First off, I've written a buffered, interrupt-driven packet transmit API. One packet can be assembled and queued while another is being transmitted. The calling context only blocks for the time it takes to assemble the packet (and possibly copy it to the send buffer, if no packet is currently being transmitted).

It does not yet respect the RTS signal, because I don't have a good way of restarting transmission when RTS comes back. Ideally, RTS would generate an interrupt, but RTS and CTS are connected to port G, and on the ATmega128 there's no interrupt-on-change on Port G (oh, how I long for the ATmega1281…).

The alternative is to set a timer to go off and try again in some short period of time, but that solution is inelegant. I've opted to ignore the problem for now. The firmware doesn't send data until after a connection is established and data is requested, and it doesn't send it so fast that the link gets saturated. Note that as the range increases, so do transmission errors (we were unable to run in the courtyard at 76,800 bps, had to drop to something terribly slow to get it to work), and the risk of saturation is much higher. I've ordered the new BlueSMiRF module which can accommodate a better antenna, hopefully that will help guard against range issues.

BlueSMiRF Send While Receive

I was having a very serious problem sending data to the car while it was sending back telemetry. I think I've managed to solve it, thanks to some hints dropped on the BlueSMiRF forums. Basically, the BlueRadios part is overwhelmed trying to parse the input stream, and can't send data in both directions when it's busy. Switching it into "fast data mode" stops the parser, allowing overall faster transmission speeds, and seems to allow data to go both ways. The drawback is that settings cannot be changed in this mode, which means the mode cannot be exited if permanently set.

So, the Java app will do this on connect: Send +++\ratmf\r. This will put it into fast data mode until power is lost. It's the best we can do.

Posted by Rick at 10:07 PM | Permalink | Comments (1)

In preparation for tomorrow's (today's?) checkpoint, we gathered some data from the car. The graph below shows the car's computed error and velocity over a period of about 3 seconds.

This graph shows the car's computed position error against the actual error (distance from the track).

Posted by Rick at 11:51 PM | Permalink | Comments (0)

Given a Kp=2 (with kSteerScale=256) in our C code units, the real-world value is Kp = (7*pi/180)/0.03 = 4.07 rad/meter. That's a map of about times-two in the linear region.

Posted by Bobby at 09:44 PM | Permalink | Comments (0)

I wrote a simple 8-tap moving average, and some code to spit out values for the left-minus-right error, filtered error, and steering command. The steering command range is very small, so it doesn't show up like much on these graphs. The graphs are over time, with each data point coming in at 200 Hz, or every 0.005 s.

Click each graph for a larger version.

This graph shows a section from 1000 to 1500.

This graph shows the filter startup (you can see the initial value is zero, and it ramps up).

Posted by Rick at 09:03 PM | Permalink | Comments (2)

Today was round 1 of class competition. We had the fastest lap time of 33.99 seconds, using proportional-only control, a speed of 6, and a Kp divider of 135. These numbers don't mean much, I know, but in the cp20060407 branch, they make sense.

Video to follow later.

Posted by Rick at 09:01 PM | Permalink | Comments (0)

Just noting a part number for potentiometers on the sensor board. DigiKey: 3223W-1-204ECT-ND.

Posted by Rick at 06:32 PM | Permalink | Comments (0)