The 2009 Control System Q&A Thread

[Alan Anderson]

Originally Posted by crake

...the selection process included detailed performance profiling of various motor controllers when used with the 9403.

Would it be possible to see what this detailed performance profiling showed?

I'm wondering whether the control system rules next year will require us to use only Victors as motor speed controllers, or if there will be a new device with a different control input available to us.

[Kevin Sevcik]

Not to belabor the point, but in case anyone hasn't thought it out fully yet, this resolution issue is going to now be a permanent feature affecting the use of standard RC style servos, and that isn't going to improved by any new motor controllers. Granted, such resolution was primarily useful for tracking with the CMUCam and we'll be getting much better vision equipment and processing at some point, but still.

Also, I just had a brainstorm. I can't get my hands on our robot right now to test this theory, but could you calibrate the Victor to work with a pulse longer than 2 ms or shorter than 1ms? If anyone in this thread is using Kevin Watson's precision PWM code, you should be able to create a 1-3ms pulse width with your GAIN constant set to 79 and your CENTER constant set to 20000. I'm curious if the Victor can successfully calibrate to this range, or possibly .5-2.5ms. Doubling the pulse width difference should get us back to a comparable resolution to what we currently have.

[The Lucas]

Originally Posted by Kevin Sevcik

Doubling the pulse width difference should get us back to a comparable resolution to what we currently have.

Along the same lines, if you had a circuit that took an input pulse then output a pulse of half the length you could double the resolution (kinda like a one-shot with the output length is half the trigger length). Just send it 2ms-4ms (same frequency) pulses and get 1ms-2ms out to the Victor. The couple ms of jitter induced by changing signals between 2ms & 4ms shouldn't affect the servos or the Victors since they just require a minimum length gap between pulses (8ms for the Victors). This circuit could be installed in the place of the current buffer IC on a future rev of the digital sidecar. Just a thought.

[Kevin Sevcik]

Originally Posted by The Lucas

Along the same lines, if you had a circuit that took an input pulse then output a pulse of half the length you could double the resolution (kinda like a one-shot with the output length is half the trigger length). Just send it 2ms-4ms (same frequency) pulses and get 1ms-2ms out to the Victor. The couple ms of jitter induced by changing signals between 2ms & 4ms shouldn't affect the servos or the Victors since they just require a minimum length gap between pulses (8ms for the Victors). This circuit could be installed in the place of the current buffer IC on a future rev of the digital sidecar. Just a thought.

... Sorry, I'm having difficulties envisioning any sort of simple pulse width halving circuit. At least one that doesn't involve something like one 555 timer, some logic, and a slew of passives per PWM channel. Or possibly two constant current sources, one cap, a FET or transistor, a Schmitt Trigger, a NOT and an AND... per PWM channel.

Or I suppose you could use a FIFO and clock the unloads twice as fast as the loads and just make sure you're not outputting a high signal for a ridiculously long time...

But on the whole, it seems like a pretty major design undertaking for the digital sidecar. Especially considering it's been prototyped and probably headed for mass production shortly. Making such a modification at this stage of the game would only put it very behind schedule.

[Kevin Sevcik]

I hate to follow up my own post, but after some further research, I noticed a slight miscalculation on my part. Looking at this IFI FAQ, the victor speed controllers are obviously going full range at 1-2ms, more or less. The IFI RC is changing the PWM width in 5 us steps, so it's varying the pulse width by 1.275 ms, and we're not using .275 of that range. So the output on the IFI RC has an full range resolution of 200 counts, compared to the cRIO's resolution of 143 counts. So the resolution will probably end up with about 75% the resolution, not the 50% I stated earlier. My curiousity about calibrating the victors to wider pulse widths remains, however.

[crake]

For reference, when the 883 and 884 were profiled they were found to have a step resolution of 6.44us (with some steps actually 12.85us) with the ability to generate 127 discrete voltages.

But as no announcement has been made with regards to motor controllers and their operational specifications, any further discussion is pure speculation.

One closing note with regards to PWM generation - the cRIO is not limited to 256 steps, thus allowing for far longer PWM periods while still maintaining the 6.625us resolution.

[lynca]

Originally Posted by Alan Anderson

Would it be possible to see what this detailed performance profiling showed?

I'm also interested in a datasheet for the microchip (on the CompactRio) that is generating the PWM pulses?

[Kevin Sevcik]

Originally Posted by lynca

I'm also interested in a datasheet for the microchip (on the CompactRio) that is generating the PWM pulses?

Andrew,
There isn't going to be a datasheet past the data sheet for the cRIO chassis we're using. Virtually all the IO in a cRIO passes through the FPGA chip in the chassis, so that's where the PWM pulses are going to be generated. Given the fact that it's probably going to be running a loop at tens of kilohertz or more and has a 40MHz clock, the precision and resolution of the FPGA aren't a limiting factor. The sole difficulty is the update rate of the 9403 DIO card. Given that the other option is a 9401 with 100 ns update, but only 8 DIOs, I can understand the choice for the 9403. It bugs me, but I can understand it.

Also important to remember is that any inputs need to stay below about 140kHz if you're expecting to catch all the transitions. That's assuming a 50% duty cycle. So for quad encoders, I think it'd be smart to stay below 50k cycles per second. So a 1024 cycle per rev encoder should stay below 6000 RPM. I know that's going to be pretty hard to stay under given the 5,000 interrupts per second limit we've been operating under so far, but I'm sure you'll all manage somehow.

[tdlrali]

If FIRST switches to motor controllers that run on a bus (I2C, SPI), then none of this will matter. They even put bus terminals on the sidecar.

[Jon236]

Q. As the FPGA code is finalized, will NI release a list of sensors that will be supported?

[jhersh]

Originally Posted by Jon236

Q. As the FPGA code is finalized, will NI release a list of sensors that will be supported?

When the list of supported sensors is announced is up to FIRST. However, I'd like to know what you have in mind, as I asked here.

Thanks,
-Joe

[Alan Anderson]

Originally Posted by tdlrali

If FIRST switches to motor controllers that run on a bus (I2C, SPI), then none of this will matter. They even put bus terminals on the sidecar.

It wouldn't matter for motor control, but it still matters for servos, as Kevin pointed out a few posts ago:

Originally Posted by Kevin Sevcik

...this resolution issue is going to now be a permanent feature affecting the use of standard RC style servos, and that isn't going to improved by any new motor controllers.

I don't think a reduced servo resolution will end up being a problem, but it certainly looks like it will be a "feature" of the new system.

[jhersh]

Originally Posted by Kevin Sevcik

Virtually all the IO in a cRIO passes through the FPGA chip in the chassis, so that's where the PWM pulses are going to be generated. Given the fact that it's probably going to be running a loop at tens of kilohertz or more and has a 40MHz clock, the precision and resolution of the FPGA aren't a limiting factor. The sole difficulty is the update rate of the 9403 DIO card. Given that the other option is a 9401 with 100 ns update, but only 8 DIOs, I can understand the choice for the 9403. It bugs me, but I can understand it.

It is unfortunate that it happened to work out that the resolution of the PWM signal dropped from 5us to 6.625us. One thing to keep in mind is that the devices you are controlling have a resolution associated with them as well. I'm not sure of the actual resolution of the Hitec 322HD servos since I can't find any specs in the Hitec Servo Manual about the resolution other than that the resolution is higher for digital servos (322HD is analog as stated here), so it is unlikely that the change in resolution will affect the current hobby servos that we use. As for the other device that we control with this signal, the Victor, I used a high resolution counter to sweep across the input range in 1us steps and measured the voltage to get a transfer function for the Victor. This is the profiling data that Chris Rake was referring to. It showed that the Victor generates 127 discrete voltages across its range. So in this case as well, there should be no discernible difference in performance. Clearly this only addresses the equipment available in the past that we have lots of investment in. The future of controllers in the kit and what the rules will allow is unknown. They may be new, but they also may not change. At least if they don't change, we can expect the same performance that we're used to.

Also, with these PWM signals, not just the resolution is important, but also the range. This also needs to be a good fit for the devices you are controlling. In a test I did with one 322HD, the servo responded outside of its spec'd 0.9us to 2.1us range, which means the new control system's PWM signal can give you more range out of the servos than you could get previously.

Originally Posted by Kevin Sevcik

Also important to remember is that any inputs need to stay below about 140kHz if you're expecting to catch all the transitions. That's assuming a 50% duty cycle. So for quad encoders, I think it'd be smart to stay below 50k cycles per second. So a 1024 cycle per rev encoder should stay below 6000 RPM. I know that's going to be pretty hard to stay under given the 5,000 interrupts per second limit we've been operating under so far, but I'm sure you'll all manage somehow.

The encoders, pwm generators, etc are running at just over 150kHz on the FPGA. This means that any signal you have going in to or out of the NI-9403 should not have 2 transitions in the signal closer together than 6.625us. It's true that we would all like to be able to have faster transitions, but the trade-off for cost, space, and channel density seem like a good thing.

The key improvement here with the FPGA is that if you have 1 encoder or 8 encoders, you can run all of them at full rate without one affecting the other. Certainly not something that was possible previously. The NItro demo was using 3 quad encoders that were 1250 pulses per rev (5000 edges per rev) coupled to the output shafts of the ToughBox transmissions with one CIM each. This was excessive resolution since we determined that the transmissions themselves had between 400 and 500 ticks of slop in them. I think encoder support will no longer be a short pole in the tent.

[Kevin Sevcik]

Originally Posted by jhersh

Also, with these PWM signals, not just the resolution is important, but also the range. This also needs to be a good fit for the devices you are controlling. In a test I did with one 322HD, the servo responded outside of its spec'd 0.9us to 2.1us range, which means the new control system's PWM signal can give you more range out of the servos than you could get previously.

Just FYI, as shown in that IFI post I linked, even the standard IFI signals range from .9ms to 2.1ms. And the user controlled ones could, in fact, be configured for nearly whatever range and resolution we liked. So this isn't actually an improvement, per se.

Originally Posted by jhersh

The encoders, pwm generators, etc are running at just over 150kHz on the FPGA. This means that any signal you have going in to or out of the NI-9403 should not have 2 transitions in the signal closer together than 6.625us. It's true that we would all like to be able to have faster transitions, but the trade-off for cost, space, and channel density seem like a good thing.

Erm. That was sarcasm. I'm fairly confident we won't actually be limited by the input frequency, especially given the current update rate of our motor controllers.

[Bomberofdoom]

Q: Which module is the PWM output one?

Q2: If we don't have the new distribution block, can we use/ alternate the old electronic system and connect the CRio through it to the current motors?