![]() |
Re: The 2009 Control System Q&A Thread
Quote:
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. |
Re: The 2009 Control System Q&A Thread
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. |
Re: The 2009 Control System Q&A Thread
Quote:
|
Re: The 2009 Control System Q&A Thread
Quote:
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. |
Re: The 2009 Control System Q&A Thread
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.
|
Re: The 2009 Control System Q&A Thread
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. |
Re: The 2009 Control System Q&A Thread
Quote:
|
Re: The 2009 Control System Q&A Thread
Quote:
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. |
Re: The 2009 Control System Q&A Thread
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.
|
Re: The 2009 Control System Q&A Thread
Q. As the FPGA code is finalized, will NI release a list of sensors that will be supported?
|
Re: The 2009 Control System Q&A Thread
Quote:
Thanks, -Joe |
Re: The 2009 Control System Q&A Thread
Quote:
Quote:
|
Re: The 2009 Control System Q&A Thread
Quote:
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. Quote:
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. |
Re: The 2009 Control System Q&A Thread
Quote:
Quote:
|
Re: The 2009 Control System Q&A Thread
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? |
| All times are GMT -5. The time now is 02:39. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi