Here's a crude video of our first run. I don't have video of the second (winning) run; we'll have to get that from the school. This one resulted in a time (also fast enough to have won) of a little over 36 and a half seconds. The winning run video will come later.
This video requires QuickTime 7 to play.
We ran our best time at a PWM setting of 75, resulting in 34.072 s, for a computed average speed of 3.01 m/s (9.86 ft/s), a new competition record (previously set in 2000 by UCB team 4 at 9.82 ft/s).
Cal also took the number 2 and 3 places.
Official NatCar stats:
John and I managed to track down a bizarre error. We discovered that from revision 68 to 69, a change was introduced in the port configuration that revealed a manufacturing defect in the controller board PCB. One of PORTA's pins was shorted to one of the PWM output pins. Up until r69, PORTA had been configured as all-inputs, but when the software was changed to set PORTA to all-outputs, it was preventing the PWM channel from reaching 5 V (I'm glad we didn't damage anything).
This seemed to cause the motor to run rough up to a speed of about 4 increments on the joystick (PWM duty cycle value 20).
Anyway, we worked around that by not setting that pin to be an output, and then went on to find the actual code that had been used for Round 2—it was on my older PowerBook, and had not been checked in (bad Rick!), so it took a bit of finagling to get Subversion to accept it.
The next steps are to add in the derivative term, speed up the control loop, and tweak on the courtyard track in Cory. I also want to get our ZigBee link working, and I need build a new sensor board (I hate perfboard!). NatCar is on Friday, and we have a lot to do to be competitive.
Here's hoping the card keys still work…
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):
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!
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.
Awesome. Highlight of our day.
L-R: Quan Gan, John Breneman, Grant Imahara, Jamie Hyneman, Adam Savage, cute kid (Adam's son?), Rick Mann, Charlie Chiau, Tracy Wang
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!
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.
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.
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.
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.
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).
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).
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.
Just noting a part number for potentiometers on the sensor board. DigiKey: 3223W-1-204ECT-ND.
We use a HiTec HS-5925MG digital servo. Its specs are as follows:
| Speed: | 0.1 sec/60 degrees at 4.8V 0.08 sec/60 degrees at 6V |
|---|---|
| Torque: | 102.76 oz-in at 4.8V 127.7 oz-in at 6V |
| Length: | 1.55" (39.4mm) |
| Width: | 0.78" (20mm) |
| Height: | 1.48" (37.8mm) |
| Weight: | 1.97oz (56g) |
With some judicious last-minute tweaking by John & Bobby, the car was able to run the courtyard track successfully, for a check-plus. Below are two movies, the second at a bit faster speed setting than the first (the first ran at a setting of "9", the second at "11").
Click on each image for the movie.
This checkpoint is basically a repeat of last week's. We have to follow the figure-eight track in the lab, or the more elaborate track in the courtyard, preceded by a 1-ft drop test.
I've modified the firmware a bit to provide more proportional control (r43). Turns out we were not appropriately scaling down the value for the steering angle, and so it would always snap full left or full right. I also reduced the "lost" threshold quite a bit (from 3000 down to 1000), to allow better use of the proportional steering. It's still terribly non-linear, and we'll have to do something about that.
Currently it drives fairly smoothly along straights, and curves well in one direction, but not so well in the other. This is due, I think, to the input from the left & right sensors being so different.
The firmware behaves a bit differently now, too. Upon reset, it's not in tracking mode. This means that the steering servo won't change, even though the steering computation is being done. To enter tracking mode, press Enter (the joystick button). The green LED should light up. To exit tracking mode, center the wheels, and stop the motor, press the Cancel.
When the car gets into "lost" mode, it will steadily light either the red LED or yellow LED, indicating steering to the right or left, respectively.
To conduct today's checkpoint, press Enter to enter tracking mode, place the car on the track to ensure steering, then speed up the motor. Pushing the joystick forward increases the speed, rearward decreases it. Three or four clicks should be sufficient, although I had it up to five or six in testing. Make sure the E-Stop is disengaged.
The car doesn't handle step responses well. It steps well to the left, but occasionally misses a step to the right. However, it enters a loop the the left, and picks up the track after 360° (this is on the lab track).
As of r40, the Hall ISR is taking between 9.6 µs and 13.6 µs to execute. I ran the motor up as fast as I could (the car started making a pulse-quickening murmur), and determined that the Hall interrupts can come as often as every 260 µs. I'd be amazed if our car ever ran that fast in practice. (As a side note: I was about to stop pushing it faster when all of a sudden the whole thing shut down. I was shitting bricks. I thought I had burned something up again, but I immediately disconnected power, and nothing was even warm. Turns out, the power supply tripped into error mode, and cut power. Whew!)
With a transition every 260 µs, and a 200 Hz control loop, that's a maximum count of less than 20. This means our low-speed speed measurement is pretty poor, because we get a transition every 16 ms or so. We could probably do the speed calculation every 10th iteration of the control loop. Even this count, 200, would fit in a byte, speeding up the hall ISR. With a 200 Hz control loop, that would give us a new speed value at 20 Hz, which should be more than adequate. There's still a timer available, perhaps we can set up a separate control loop for the speed.
The Control timer ISR usually takes between 18 µs and 19.2 µs, but sometimes I see it take as much as 55 µs. I'm guessing this is some timing glitch, because it's all over the map, and happens relatively infrequently.
10 revolutions of the wheels is 478 Hall transitions, for 47.8 Hall transitions/wheel rotation. On the living room carpet, the wheel makes about 4.75 revolutions per meter (revolutions measured by eye), over a single meter, or about 14.2, measured over 3 meters (4.73 revolution/m). This gives 226.1 Hall transitions per meter.
If the math is right, a Hall transition (ht) every 260 µs means 1 wheel revolution (r) every 260 µs/ht * 47.8 ht/r = 12.43 ms/r, which means 1 s / 12.43 ms/r = 80.5 r/s, which is 80.5 r/s / 4.73 r/m = 17 m/s! That's 61.2 km/h (38 m/h)!
Obviously, it won't actually go that fast, except maybe downhill.
For the last few days, I've been having a really hard time getting the SparkFun BlueSMiRF radio to establish a link. At first I thought it was due to RF interference from the Power Board, but it had worked in the past.
After much trial and error, I narrowed it down to what I thought was this: merely initializing USART0 on the ATmega128 was enough to prevent a link from being established. If I commented out the initialization code, then ZTerm (or any other program) could make a connection to the BlueSMiRF and AT commands could be sent. I modified the firmware to allow me to initialize USART0 after establishing a link to the radio, and discovered that there was still code sending data. Once I cleaned that up (put it under the control of the global "send telemetry" flag), I could safely initialize USART0 as part of the normal startup, and subsequently connect.
My theory is that the BlueSMiRF's transmission buffer (from firmware to PowerBook) was filling up, and that somehow prevented its normal connection establishment. That, or simply writing to the buffer before a connection was established. Something along those lines.
In any case, it seems to be working well now, so hopefully we can get on with the task of improving our tracking code.
I'm wiped out. This will be brief. John & I got really ugly steering working. It was fairly proportional, within a narrow band right near the wire. When we built another (oval) track in the living room, the steering became very discrete (binary). In any case, the car was able to follow the track. We're gonna try on the lab's figure-eight track tomorrow. No telling how well it'll do. Hopefully we won't be too screwed, given all the trouble we had with the toolchain earlier (literally hours wasted, I think thanks to Apple's latest security update).
For now, enjoy this movie of our car (click the image for the movie). Sorry it's so dark:
Yesterday, Bobby and I succeeded in building an op-amp circuit to amplify and offset the tiny voltage produced by the sense inductor as it picks up the track signal.
Setting up the ATmega128 Timer 3 was a bit confusing, primarily because I was inadvertently enabling the wrong interrupt.
We use Timer 3 to set up a 100 Hz interrupt to drive the control loop. Speed and steering feedback control will be processed in this loop (at this time, ADC conversions will happen in their own loop, sequencing among channels and storing the values in global variables. Some kind of synchronization with the main control loop will likely be necessary, or at least, perhaps helpful).
The following is the code excerpt for setting up Timer 3 (fosc = 16 MHz):
// Output disconnected (we only want interrupts)
// CTC, TOP := ICR3
TCCR3A = (0 << COM3A1) | (0 << COM3A0)
| (0 << COM3B1) | (0 << COM3B0)
| (0 << COM3C1) | (0 << COM3C0)
| (0 << WGM31) | (0 << WGM30);
// Disable input capture noise canceler, edge select to negative.
// CTC, TOP := ICR3
// prescale: fosc / 8
TCCR3B = (0 << ICNC3) | (0 << ICES3)
| (1 << WGM33) | (1 << WGM32)
| (0 << CS32) | (1 << CS31) | (0 << CS30);
ICR3 = 9999; // 100 Hz loop
//ICR3 = 1999; // 500 Hz loop
//ICR3 = 999; // 1000 Hz loop
//ICR3 = 499; // 2000 Hz loop
// Reset the timer
TCNT3 = 0;
// Enable Timer 3 overflow interrupt
ETIMSK |= (1 << TICIE3);
The interrupt handler is defined like this:
ISR(TIMER3_CAPT_vect)
{
// Blink an LED so we can
// measure the frequency
PORTC ^= (1 << kPinYellowLED);
}
We succeeded in passing today's drop & run checkpoint. The car was required to execute an open-loop (no speed or steering feedback) figure-eight. The motor had to be running as the car was dropped from a height of about 30 cm. Nothing could fall off the car, and it had to proceed to complete the pattern. The "figure-eight" was allowed to be sloppy; each turn had to exceed 360 degrees. This checkpoint was done with the brushless motor!
People liked the look of the car, enough that one team took pictures of it (click the images for larger versions).
Overall car, with JTAGICE connector going off to the right.
The VersaLaser-cut acrylic mounting plate.
The mounting plate positioned upside-down for adjustment.
Closeup of the purple mounting blocks.
Closeup of the purple mounting blocks.
Closeup of the purple mounting blocks in front.
Front-end mounting blocks in right-side-up position.
One option for routing the BLDC power wires.
Side view of mounting plate, BLDC and boards.
Rear quartering view of mounting plate and power board.
Earlier today we had our power board fail in the same fashion as before. This time, the AND gate IC smoked dramatically. It seemed to take out the LDO, but the ADC seems okay (assuming it draws 50 mA in normal idle operation).
My new theory is this: the output cap on the LDO was 10 µF. According to the data sheet, any cap less than 1 µF can be used; if you want to go over 1 µF, it should be a cap with an ESR of at least 0.1 Ω. I don't know about the 10 µF cap I had on there, a Panasonic EMK212BJ106KG-T 16 V ceramic 0805 cap. I've replaced it with a 0.1 µF cap (I couldn't find a 1 µF cap), so hopefully that'll work.
I base my theory on this: Just after replacing the LDO, with lots of liquid flux still on the board, I powered it up. The new reg. was outputting over 5 V, and it kept climbing. I disconnected power around 6 V, for fear of damaging the ADC. After rinsing, the regulator performed well at 4.944 V, but I wonder if the 10 µF cap was causing it to go unstable, and to then output higher voltages, frying the AND IC.
Sigh…
P.S.—The other LDO is no longer regulating. It just puts out about what it gets. What the fuck is going on here? I'm going to try replacing the output cap on that one, see if it makes a difference. What a piece of shit LDO. I'm never using it again.
Replacing the cap didn't help. This means my theory is probably wrong, and it's something else that's FUCKING shit up.
I sure hope I didn't fuck up the ATmega128 running it at ten fucking volts for a few seconds. It seems to be running, but who knows what peripherals I've fried? Fuck.
Fuck. Fuck. Fuck. Fuck. Fuck. Fuck. Fuck. Fuck. Fuck. Fuck. Fuck. Fuck. The fucking MCU is fried now.
The ADC was bad, too.
I've replaced them all.
I'm exhausted. I'll do the open-loop 8 in the morning-ish. Here's hoping work doesn't need me…
According to John, we passed the stall & steer checkpoint without any problems. The motor was stalled at 50% duty cycle, while the steering servo was commanded left and right. The TA also pushed against the servo to make sure its supply didn't suffer.
John reported some perceptible vibration or glitching in the stalled motor when the servo was pushed. We'll have to investigate that further.
I've made some progress, but not much. The motor runs with all three phases connected, but it doesn't run smoothly. If I get up to about 40% power, it start to slow down, and changing from 20% to 30% results in a sluggish increase in speed.
At first I thought perhaps the Hall sensor interrupt was taking too long, and that it wasn't completing before the next Hall state change, but that's not the case. At the lowest setting (1/26th or so), the time between Hall state changes is about 5.36 ms, and the interrupt handler time varies between 6.8 and 8.8 µs, three orders of magnitude faster. So that's not it.
It either has to do with the nature of our MOSFET switching (the low side is on whenever the high side is off), or the sequence is still off. My inexperienced inclination is toward the latter.
Okay, I think I'm dumb. Here's what I did: I switched the drive phases, so the MB's A was connected to the motor's B, MB's b to motor's C, and MB's C to motor's A. This seemed to work better so I pushed it higher and higher. It started to have trouble near the top end, and that's when it dawned on me: I'm hitting the power supply's current limiter. So I upped that, and sure enough, the motor ran better. It topped out at the power supply's max of 3 A, so I think that's it. I'll need to get confirmation from Novak about the Hall sensor ordering.
Bad News: I've fuX0red something badly. The MB board won't run (it draws a LOT of current), even with nothing connected. The MCU board doesn't work if I apply power to Vin (it also draws a lot of current), but if I put 5 V downstream of the LDO, it works. I think it's time to call it a night. I hope I can salvage this. Fuck.
The MOSFETs have stayed ice cold throughout all of this, and the BLDC motor runs off less than an amp, unlike the brushed motor we used for the last stall test checkpoint. Running at high speed (rather, near the maximum speed setting on this sketchy controller), the Hall state change interval is about 380 µs.
The board with two 4-channel scopes set up to look at both the motor phase energization and Hall sensor state.
A wider view of the same thing.
A few seconds of the Hall state. The fourth channel is motor phase A/U.
A movie showing a few seconds of the motor phase sequencing. I think the scope is causing the flashing (it's kind of a POS). The fourth channel is Hall sensor 1.
I finished populating the Motor Board, and decided to take a stab at the BLDC driver. It doesn't quite work, but it does work a bit. If I connect only phases B and C, or A and C, and give the motor a twist, it runs (although it sounds terrible). If I connect A and B, then I get a high-pitched whine in the motor and the current limiter on my power supply kicks in.
I only have a two-channel 'scope, so I'm going to haul the rig down to the lab, try things out on the 4-channel 'scope there. I really wish I had the MSO6032A right now. Sigh…
Here's the rig:
This is what the boards look like (minus power) when I'm writing code for them.
I was able to do some basic (read: synchronous) TWI/I2C communication with the AD7993-0 4-channel ADC we have on the Power Board. In the process, I discovered that it has a really stupid limitation, but we can work around that in software. In any case, I'm pretty stoked about this. Now I have to do a little work on the telemetry app to actually put that data to use (it's damn hard to read hex streaming in a terminal window). I used a synchronous TWI library from Peter Fleury. However, the site appears to be in Switzerland, and stopped responding shortly after I downloaded the code.
The AD7993 has a mode of operation where it will cycle through any combination of the 4 analog input channels, automatically converting. However (stupidly), it only has one conversion result register, so each new channel conversion result overwrites the previous channel's conversion result. This makes the automatic cycling mode much less useful. To use it, you have to synchronize reading the ADC with its notion of which channel is in place (or just get the values randomly, as your reads at a frequency different from the conversion cycle).
The workaround will be to use Mode 2, Command Mode, and explicitly request each channel's conversion. It may be sufficient (although less elegant) to do this synchronously (that is, without relying on TWI interrupts), because the rate at which we want to send telemetry is pretty low.
I had some trouble after I first assembled that portion of the circuit, because we don't have the 0.047 µF or the 0.0047 µF 0805 caps. I tried it with 0.01 µF and 0.001 µF, but that didn't work. Then I found a 0.047 µF through-hole cap, bent and trimmed the leads, and it worked.
I also didn't have the exact resistors for R1 and R2 (43.5 kΩ and 6.19 kΩ, respectively), so I used 47 kΩ and 6.8 kΩ instead (20% tolerance). This results in a no-load output voltage of about 10.8 V, after it stabilizes. Initial voltage is much higher, but I suspect that's due to the no-load condition. When the MCU is connected, the boost converter's output stabilizes at about 10.05 V. The Fluke 111 DMM can't pick up the initial over-voltage in the time it takes to stabilize (I have not looked at it on the 'scope).
There's less than 50 mV of ripple (on Vpwr) at the MCU power input, and less than 20 mV noise after the LDO on the MCU. There's less than 200 mV of noise just after the DC-DC converter, although it increases a bit as you travel out along the trace, never more than 200 mV.
After the LDO on the MCU board, there's a clear 100 mV spike at 500 kHz.
Good job, John & Bobby, on designing the board!
I've stuffed most of the components on the MCU board:
The look great, and they passed the basic continuity tests.
Advanced Circuits has emailed me saying there will be a one-day delay in getting me the new boards. Grr.
So, I got a call this morning from a tech at Advanced Circuits. He verified the problem, and has put in the order for a 1-day turn. They will ship it out Tuesday UPS Red, so it should be here by Wednesday, the day I originally expected to receive them.
Way ahead of schedule. I had expected them to be here next Wednesday, but they got them finished yesterday, then sent them out (late that night), and they got here in one day! Amazing.
Unfortunately, they were bad. When the technician corrected the issues earlier, he inadvertently caused a bunch of pads to short to the ground and power planes. I've discussed it with another tech in the CAM Hold department, but we can't do anything about it 'till Monday morning. I sent Michelle (our sales rep) and email.