« February 2006 | Main | April 2006 »
After a day of playing with MATLAB's scoping characteristics, I was able to implement the PD controller in code (part 1a and 1b of the assignment). You can see that I was able to calculate an optimal pair of Kp/Kd coefficients (10/2) using my nifty Mathematica eigenvalue analysis. Here is the code, and here are the plots for Proportional and Proportional-Deriv control:
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) |
Check out this PDF from Mathematica I put together. I've extracted the eigenvalues for particular steering control laws, so we can calculate the optimal gain constants for our MATLAB simulation and eventually for our vehicle's microcontroller. Werd.
Control Law Analysis
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…