« January 2006 | Main | March 2006 »
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:
I've been mulling over the math behind a possible track learning control strategy. The way I see it, there are three stages: positional tracking, track learning, and predictive control (braking) interrupts.
Positional Tracking:
We'll be using our favorite rotation group SO(2) for this. Our unit orientation vector D begins with initial condition [1, 0]. We update this vector whenever the microcontroller obtains a new value for the servo angle Theta (whether this be from instructions given to the servo or from feedback via the ADC). Upon receiving a new Theta, D = R_z(Theta)*D. This requires 4 multiplies and 2 additions since we are in SO(2).
Using D and absolute velocity v (converted from angular velocity from brushless motor), we maintain our global position X = Integrate[D*v,dt] where X is 2x1 with initial condition [0,0]. This should run at every time-step, which requires 4 multiplies (orientation*velocity*time for 2x1) and 2 additions.
Track Learning:
We record a list of straight-aways, ListSX, each element being a pair of initial and final global positions corresponding to begin and end-points of straight-aways. This can be done by maintaining a position variable StraightX with initial condition [0,0]. If the servo angle is beyond a certain threshold angle, and the current global position X is less than a threshold distance away from StraightX, we discard the previous value and update it with current X. If the servo angle is beyond a certain threshold angle, and X is more than a threshold distance away from StraightX, we record (StraightX, X) at the end of ListSX and update StraightX with X.
This is repeated until X goes within a threshold distance away from our initial position [0,0] and D is within a threshold offset of initial orientation [1,0] (this is in case we have a lap cross-over near the origin). This flag signifies the end of a complete lap, at which point we want to begin using our track information.
Predictive Control Interrupts:
The primary PD servo and P braking controller must complete the first lap. Once this is done, this controller still serves as the primary guidance system. However, whenever the global position X goes within a threshold distance of the begin-point of the ith pair in ListSX, the predictive controller interrupts the braking control to instruct the motor for full torque. As soon as X approaches a threshold distance from the end-point of the ith pair of ListSX (this threshold must be larger because the whole point is to predict the end of a straight-away), the predictive controller will again interrupt the braking control to instruct braking proportional to the current speed v. The index is incremented by one to prepare for the next straight-away, until the end of the lap is reached and the index is reset to zero.
This might be a lot of math for the microcontroller to handle at every "timestep" (whether that be a cycle or every several cycles). Rick, how many operations do you think the microcontroller can handle? You guys have any comments on this strategy?
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!
Today we had our motor stall test checkpoint. For this test, we were required to build a single-MOSFET motor driver, and be able to drive a brushed DC car motor at 50% duty cycle, from the battery, with the wheels clamped, for 10-15 seconds. We passed with flying colors, even at a 20 kHz PWM frequency (they're recommending to everyone else to run at 100-200 Hz), so he offered us extra credit: a "check-plus" if we can pass the same test at 90% duty cycle.
We tried it. The MOSFET had no problem, but the motor started to smoke! We stopped as soon as we saw that. We got the check-plus, too.
I've stuffed most of the components on the MCU board:
The look great, and they passed the basic continuity tests.
For an ATmega128 running at 16 MHz, timer 1 in Fast PWM mode
TCCR1A = (1 << COM1A1) | (0 << COM1A0) // All three PWM outputs | (1 << COM1B1) | (0 << COM1B0) // Set at TOP, clear on compare match | (1 << COM1C1) | (0 << COM1C0) // | (1 << WGM11) | (0 << WGM10); // Fast PWM, TOP = ICR1 TCCR1B = (0 << ICNC1) | (0 << ICES1) // Disable input capture noise canceler, edge select to negative. | (1 << WGM13) | (1 << WGM12) // Fast PWM, TOP = ICR1 | (0 << CS12) | (1 << CS11) | (0 << CS10); // prescale: clk(i/o) / 8
With a divide-by-8 clock, counting to 0xFFFF takes about 32 ms (or about 30 Hz).
Phase-correct PWM, with clear on up and set on down, and ICR1 = 400d seems to do the trick (20 kHz).
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.
The site is a place to collect quotables from IM/chat conversations. Their Top List is a good place to start if you have a solid 20 minutes to waste.
One of my favorites, and so apropos for this blog (punctuation added):
<Patrician|Away> What does your robot do, sam?
<bovril> It collects data about the surrounding environment,
then discards it and drives into walls
When doing 2 oz copper, they can't go down to 5 mil spacing. With 1 oz, it's 7 mil min. The solder mask at 8 mils was too big, exposing traces (I noticed this on other boards). Instead, it should be 3 mil, which gives them a total of 6 mils, meeting their req for 5 mil minimum. The vias needed pads of 10 mils min. They also need 10 mils clearance from the edge on inner copper layers.
This is what came back from my Osmond submission.
The guy was able to fix it all without me resubmitting a file. Awesome.
I'm waiting on information on how to thermally link the regulator heat sink copper area to the ground plane. I need vias that have no spacing on layers 1 & 2, but spacing on layers 3 & 4. Then I'll be done. Otherwise, here are screenshots of the layers. A neat thing to do is open each image (click on them for a larger version) in another tab, then switch between tabs to see them laid out on top of each other). Oh, and if you spot any mistakes, let me know! This is going to fab tomorrow (today?)!
Here's the schematic for the board laid out in the previous post.
I'm almost done with the main controller board layout. Here's a screenshot of what I've got so far. Barring mistakes, the only thing left is to add a power connector.
