Using Kevin's PWM outputs for a quieter drive system.

[Kevin Sevcik]

Originally Posted by Kevin Watson

It's been on the back burner for a while and someday I'll get around to finish coding it, but a really neat trick is to not measure the number of encoder ticks per unit time, but to measure the amount of time between ticks instead. Using your example, you could use the internal 10MHz timer to give you a one part in a thousand resolution in velocity at a control rate of 10KHz!. If you don't need to control at 10KHz, you can forward predict the number of ticks to accumulate for a, say, 100Hz control rate, which will give you an incredible velocity resolution of about one part in 100,000. I've used this technique in a few applications for my day gig, with pretty stellar results. Pretty cool, eh?

-Kevin

To continue my recent trend of totally sidetracking threads...

I've thought about going that route myself, actually, but I've been put off by the inherent difficulties of measuring slow speeds with that method. Resolution at top speed is actually lower than resolution at slower speeds. If your top speed is 10 RPS and you've got a 100 pulse per rev encoder, the time between pulses would be 1 ms. So you prescale your timer to count at, say, 10 microseconds. That means your time to speed conversion is 1000/ticks = RPS. So at 100 ticks, speed = 10 RPS, at 101 ticks, speed = 9.9 RPS, 1 tick difference = .1 RPS. At 1000 ticks, 1 tick difference = .001 RPS. And at this conversion rate, the slowest speed you can measure (easily) is 1000/65536 = 0.015 RPS. That's a pretty good range, provided 1% resolution at your top end is adequate. The main problem with the concept as a whole is that your update rate slows down the slower you're moving. At 1 RPS, you'd be updating every 10 ms. Or once a control cycle if you're working at 100 Hz. At .25 RPS, it's once every fourth control cycle and so on. So I think it'd be optimistic to expect a PID based off this to maintain 0 velocity.

Programmatically, my main problem is that unless you've got extra logic in there, things get screwy if you're moving at less than 0.015 RPS. If you roll over the 16-bit timer, it suddenly looks like you've only taken 1 microsecond between pulses and you're suddenly traveling at ludicrous speed. So you'd have to have extra logic tracking how often you've rolled it over, etc. And, of course, the encoder jiggling while you're at rest would make it look like your robot was traveling at a fair clip as well, and etc, etc, etc.

So, mostly, it'd be a fair amount of effort to work up this code, I think. At least it would be to get it efficient and fast. That plus the prospect of a totally new and different control system next year has pretty much completely sapped me of any will to work on it. Except, of course, that composing this post already started the process of hammering out the logic and structure and working around at least some of the problems.... I'm actually pretty sure you could make it work fairly reliably off your Port B Encoder jiggle-resistant logic.....

[MWagon]

Inquiring minds want to know:

Which of you Kevin's originated Kevin's PWM code: Sevcik or Watson.

OK, I didn't search. So shoot me already. Wait......

[Kevin Sevcik]

Originally Posted by MWagon

Inquiring minds want to know:

Which of you Kevin's originated Kevin's PWM code: Sevcik or Watson.

OK, I didn't search. So shoot me already. Wait......

I can't believe one of my own team mentors doesn't know this.... heh. Sadly, this doesn't mean I get to take credit. As far as I know, Mr. Watson is responsible for the all the "Kevin" labeled code around FIRST parts. So much so that I default to it in advising anyone wanting to use MPLAB to program their robot, since it just works. For the version I used during Aim High, I adapted some code posted by.... Someone I can't seem to search up at the moment. It didn't have Dubya's fancy gains, offsets, and range expansion, however.

And yes, that will be the first and last time I'll refer to Mr. Watson that way. It does get a might trying giving programming workshops and noting that, no, I didn't write the code. Nor am I in possession of the kevin.org domain name. Unless Watson foolishly forgets to renew his registration by... ummm... 05:00, March 27th, 2017. Cause, yeah... I know I'd never remember something that far in the future.

[Tom Bottiglieri]

Kind of off topic, but related to my previous post:

I think I may have found another error in the control scheme I suggested before. It seems I was oversampling the ADC a bit too much and getting some slow readings.

motor = setpoint + ( amps * gain ) ;

To debug and tune we set the motor to a certain base fake velocity, and tuned the gain so that when we applied friction to the wheel it would keep the same real velocity. The problem that arose was the wheel would keep the velocity it needed, but would take about .5 seconds to "spin up" when the friction was applied and another .5 to "spin down" after the friction was released. At first we attributed this to the 40Hz control frequency (which im still partially blaming), but now I'm guessing I can attribute this to the laggy ADC readings.

Kevin^2, any comments?

[Kevin Sevcik]

I'm going to say it's not related to your ADC oversampling. Blaming it on the ADC oversampling implies that the ADC code is taking a moving average of the analog input and thus damping the current feedback signal, but this simply isn't how the ADC code works. I think you're just seeing the mechanical dynamics of the system coupled with a slow control loop and delayed response from the Vics. I'd say you can compensate by increasing the PWM loop rate like we've been talking about and very carefully bumping up your gains. IR compensation is a little tricky since the electrical dynamics of the system are an few orders of magnitude faster than the mechanical dynamics. If you increase your gain too much, the IR compensation starts overshooting and you get chatter in your motor and it sounds even worse than they usually do. So I'd say speed up the loop and tweak up your gains till things start sounding off, then back them down a little and just assume that's the best you're going to do.

[PhilBot]

Since I stared this thread, it has been interesting to watch and learn.

Something that I have learned while playing with the "IFI" vs "Kevin" PWM outputs is that there is appreciable less delay between request and response with the Kevin code.

Case in point, at the beginning of auto mode, my code starts setting the position of the steering motor. On the bench (since I didn't have a feedback pot hooked up) the RC called for motion on the steering motor right away.

I just had a Victor hooked up and I was looking at the indicator LED.

I am using the process_gyro() loop to detect when new feedback is available, and I was setting BOTH the pwm5 and pwm15 at the same point in the code.

So, with the victor plugged into pwm5, I click on Auto mode, and a heart-beat later, the Victor light goes off. However with the victor plugged into pwm15, the victor light goes off almost instantly after I click auto on (no perceivable delay).

The difference seems much longer than anything associated with a fraction of a normal OI update cycle (perhaps as much as 100-200ms) , so I'm confused but pleased. I think our steering will be tighter in the future using pwm15. I even decided to move 2 of our 4 wheels controler to the upper range as well.

[PhilBot]

I finaly stumbled across the reason for my noisy drive train.

The problem ended up being caused by noisy throttle inputs on the OI.
The noise that was being seen by the OI was bouncing the motor speed in and out of the deadband of the Victor when a slow speed was being requested.

My joystick deadband logic may have been part of the problem...

I first check to see if the input is outside the deadband, and if so,I subtract the deadband from the current reading. This then gives me a speed signal that is continous all the way to zero.

Unfortunately, this also makes the output to the victor continous from zero up, so any noise on the joystick can bounce the victor in and out of it's minimal activation signal, thus causing the motor to start and stop based on the joystick noise. This rapid on-off action was being transmitted into the gearbox and causing all sorts of ugly noises.

Rather than re-offsetting the levels, and possibly changing the other characteristics of the signal, I now just pass the joystick requests through a FIR filter (like oversampling the RC inputs), and so the victor doesn't see the noise. Suddenly I have a MUCH quieter drive system.... YAY...

Phil.

[Qbranch]

As a note:

I have played around with the victors to figure out what the highest update rate is, and have found for some older Victors the 100Hz rate is pushing it a little. The drives will occasionally give you random motor outputs at this rate.

We have been using high update/high resolution pwm for a few years now, with much success.

As to the 100Hz/120Hz thing: If I remember right, the IFI advertised maximum signal input is 100Hz and the chop output is 120Hz regardless of input frequency.

Anyhow, here's my question, and I'm hoping someone can answer it for me as I've asked IFI before: IFI offers only one drive, the Victor 883, with a 2KHz chop frequency. One common thread between many FIRST robots is their angry buzzing noise (from the 120Hz chop) that they all make, as opposed to the more intelligent sounding high frequency hum common among industrial servomotors and the like.

What I'm wondering is, why doesn't IFI use a higher chop frequency? Also, why not allow shorter pulses for the PWM input to get a higher update frequency? The microchip timers are capable of doing shorter pulses without any loss of accuracy/resolution. Alternatively, perhaps using PWM as an interface to the motor drives isn't the best idea for rapid updates anyways. Maybe some kind of simple serial bus? Since the victor's don't have to give any feedback, it could be as simple as a dip switch on each one to specify an address, then just use good ol TTL serial. (At 115200baud, at maximum capacity you should be able to send 4800 24-bit values/second (8-bit address and 16-bit data), or, run 16 victors at an update rate of 300Hz)

The major advantage of higher frequency chopping (2KHz+) with very low output duty cycle capability would be the ability to finally do high speed variable dynamic braking, without the robot looking like you just threw a wrench in it.

-q

p.s. I'm not saying you can't do dynamic braking with the current drives, our robot does this this year and I'm sure others do as well, however, I would like to be able to do it more smoothly than is currently possible with the victor drives.

[Mike Bortfeldt]

Phil,

The difference in delay between the "IFI" PWMs and "Kevin's" is because PWMs 1-12 are generated by the master processor, while PWMs 13-16 are generated by the user processor. The master processor PWMs will only occur after the communication has taken place between the two (roughly every 26.2 milliseconds), while the user processor PWMs are generated immediately. More details about this delay can be found here.

Mike

[Al Skierkiewicz]

Phil et al,
I feel a need to go back to the original line of questions. The 120 HZ Victor output repition rate more closely matches the brush timing on the many of the motors we use. Previous versions of the Victors had a higher rep rate. This design then allows a smoother control of the motors due to the averaging of current in each winding in the motor as it contacts the brush assy. This is especially true at low speeds where everyone wants the greatest control. A higher output frequency (2kHz with the 883) gives relatively short pulse width for the brush timing at low speeds. Often the pulse could occur during the transition from one commutator segment to another. This gives a much more erratic response at low speeds. As long as the drive system uses a pulse to drive the motors there will be some noise. Remember that a variable DC current (no pulses) needs to be at a certain voltage level to just get the shaft turning. That level may be too fast for the kind of control you require. The full +12 volt pulse starts the motor turning and still gives you relatively low drive current (speed) with a short duration pulse.
As to lubing the Banebot transmissions, I am sure there are some people who would disagree with the addition of heavy or thick lubricants as the efficieny starts to drop with this type of lubricant. Remember that an intermittant application like ours, does not allow the transmissions to reach full operating temperatures for which those lubricants were developed. I think I would rather have a loud and efficient transmission than a quiet one in this application.

[Kevin Watson]

Originally Posted by Kevin Sevcik

To continue my recent trend of totally sidetracking threads...

I've thought about going that route myself, actually, but I've been put off by the inherent difficulties of measuring slow speeds with that method. Resolution at top speed is actually lower than resolution at slower speeds. If your top speed is 10 RPS and you've got a 100 pulse per rev encoder, the time between pulses would be 1 ms. So you prescale your timer to count at, say, 10 microseconds. That means your time to speed conversion is 1000/ticks = RPS. So at 100 ticks, speed = 10 RPS, at 101 ticks, speed = 9.9 RPS, 1 tick difference = .1 RPS. At 1000 ticks, 1 tick difference = .001 RPS. And at this conversion rate, the slowest speed you can measure (easily) is 1000/65536 = 0.015 RPS. That's a pretty good range, provided 1% resolution at your top end is adequate. The main problem with the concept as a whole is that your update rate slows down the slower you're moving. At 1 RPS, you'd be updating every 10 ms. Or once a control cycle if you're working at 100 Hz. At .25 RPS, it's once every fourth control cycle and so on. So I think it'd be optimistic to expect a PID based off this to maintain 0 velocity.

Programmatically, my main problem is that unless you've got extra logic in there, things get screwy if you're moving at less than 0.015 RPS. If you roll over the 16-bit timer, it suddenly looks like you've only taken 1 microsecond between pulses and you're suddenly traveling at ludicrous speed. So you'd have to have extra logic tracking how often you've rolled it over, etc. And, of course, the encoder jiggling while you're at rest would make it look like your robot was traveling at a fair clip as well, and etc, etc, etc.

So, mostly, it'd be a fair amount of effort to work up this code, I think. At least it would be to get it efficient and fast. That plus the prospect of a totally new and different control system next year has pretty much completely sapped me of any will to work on it. Except, of course, that composing this post already started the process of hammering out the logic and structure and working around at least some of the problems.... I'm actually pretty sure you could make it work fairly reliably off your Port B Encoder jiggle-resistant logic.....

It may be clearer when I admit that I've always implemented this functionality in a FPGA, not software. There is little difference though. Measuring low velocities isn't really a problem because you can expand the sixteen bit timer to any width by incrementing the upper bits in the ISR. Secondly, if you know your pressent velocity, you can forward predict the number of ticks to let go by before you calculate your next update.

-Kevin

[Kevin Sevcik]

Originally Posted by Kevin Watson

It may be clearer when I admit that I've always implemented this functionality in a FPGA, not software. There is little difference though. Measuring low velocities isn't really a problem because you can expand the sixteen bit timer to any width by incrementing the upper bits in the ISR. Secondly, if you know your pressent velocity, you can forward predict the number of ticks to let go by before you calculate your next update.

-Kevin

Yes, I agree that FPGAs, uninhibited PICs, MCUs, etc would all make implementing just about anything a lot easier.
And yeah, I was in fact already thinking about how I'd be incrementing a char as the timer was overflowing to expand my bits somewhat. I hadn't considered predicting a reasonable number of encoder ticks to measure over, however. That'd definitely be the way to make it work. More complicated, but not terribly. And pretty fast if you're changing the ticks by powers of two so you can just use bit shifts and masks....