CVI is not released for cRIO, or for other RT targets. The WPILib libraries will be included with the ANSI, and posix libraries provided by WindRiver.
I’m not positive about the licensing of the visions stuff. I think that Vision Assistant will be in the kit.
Greg McKaskle
I’m still confused as this is (may be) an answer to only half the original question? The other half had to do with the VxWorks API as supported on cRIO. RTPs, for example, are not available in the VxWorks port on cRIO. It would be very useful to know which set of components of the VxWorks API that are NOT in the cRIO. I think the answer is the same, “information not currently available, will ship with h/w”?
Thanks for the clarification.
I’m afraid that’s correct; LabVIEW customers are completely unaware of these nuances, and that’s the way it should be - an end user application shouldn’t care what happens in the OS, so long as everything works like it’s supposed to. And, in fact, we work hard to make the end user experience the same no matter what OS they’re working with; of course there will always be subtle (and sometimes not-so-subtle) nuances, but that’s par for the course.
I would expect such OS documentation will ship with the final product, and hopefully you won’t be subject to working directly with the OS but through heavily tested interfaces such as the WPILib.
-Danny
This is only true for the the LabView environment.
If working in the C/C++ environment, I’m not sure how you wouldn’t end up working with the OS since you need to at least create tasks and schedule them… I seriously doubt the WPILIB will package up the necessary routines to create/schedule/prioritize kernel tasks, do data stream logging i/o, etc. which is already available within the OS API. The duplication effort would not seem to add value – but anything is possible.
I think it would add extreme value - even Microsoft finally “saw the light” with its new driver architecture framework in Windows Vista. In order to perform “standard operations”, there was a “list of things every driver had to do.” Finally someone said, “Hey, if we always have to do this, why not give us an interface so that we give you the information for the specific thing we’re doing, and you do all that boiler plate code FOR US.” I would hope the WPILib will handle the boiler plate code for you, and not force you to become entangled with OS specific drudgery.
But then again, anything is possible. 
-Danny
A standard i/o & driver framework definition exists within VxWorks, its pretty orthagonal to the driver framework in linux/unix, but NI chose not to use this standard. Instead the cRIO driver is implemented in a different/custom fashion. So your statement may in general be true, but even NI finds instances where it isn’t.
Currently there are between 250-300[li] different component libraries within VxWorks kernel each with a average of 8-10 interface calls… device drivers as being supplied by WPILIB represent 5% or less of that total API call interface. I just don’t see the WPILIB providing all the templates needed to hide the other 95% of the operating system interface so C/C++ programmers don’t have to call any OS functionality.
[/li]
For example, I doubt that the WPILIB will provide a callable inertial navigation system (INS) whereby you can customize at the call interface specifying how many sonar, IR, quad encorders, gyros, accelerometers, GTS, and other specific sensors exist on your particular robot. To implement your own INS, you will need to use various services of the operating system plus the drivers supplied by WPILIB.
[*] from “VxWorks, KERNEL API REFERENCE Volume 1: Libraries”; some of these are undoubtedly not implemented in the cRIO port of VxWorks, but most should be there.
Well if FIRST is planning on using the IFI Victors and doesn’t find an alternative speed controller, we know the maximum effective resolution achievable on the Victors is 97 counts on either side 0. This despite the IFI RC’s actual resolution of 127 counts on either side of 0.
Now, the 9403 has an update rate of 7us. Given that we have to vary our pulse by 1ms for a “full” range of control, that gives us about 143 counts of resolution over the full range. As opposed to the 255 counts on the IFI RC. (Presuming the IFI pulse work out to exactly 255 for 1-2ms variation) When you add in the Victor’s deadband and only 97 output steps, you end up with an effective resolution of 54 output steps with the cRIO/9403/Victor combination.
I realize that we’re not doing rocketry control systems here, for the most part anyways, but effectively halving our output resolution annoys me, as one or two counts can definitely affect how straight your robot’s driving. Especially considering this is the Control System of Tomorrow and the motor control system now seems to be less capable than the Control System of Yesterday. I think following in NASCAR’s Car of Tomorrow footsteps is taking the Overdrive theme just a bit too far.
chokes umm. If you’re implying that they selected the 9403 because of the 7us update as opposed to in spite of it then that’s disappointing. Considering they were obviously planning from the start to use the IFI Victor speed controllers, and that a 7us update rate combined with the 1ms variation for the Victors yields an astounding 143 counts of resolution… Well if they were planning on purposefully making the Victors annoying to use and less reliable, then mission accomplished, I suppose. I was assuming that the trade-off was to gain 32 DIOs in a compact form at the price of poor resolution with the Victor controllers.
That’s not quite what I was saying. The 9403’s update rate (which really is 6.625us if you want to be precise) was well known and understood when the module was selected. Also the selection process included detailed performance profiling of various motor controllers when used with the 9403.
Well, I can say that with the amount of resolution on the speed controllers as it sits right now, our ‘rocketry control system :)](http://www.youtube.com/watch?v=RjGyQPax5Vo)’ wouldn’t have worked with any higher of a minimum ouotput power. You can (even with the 3% throttle and resolution available now) still see our 2008 robot shimmy as it’s dynamic braking to enter an interpolated arc motion (just check out any videos on TBA of our autonomous, especially Midwest and Archemedes).
You know, if they try hard enough, I bet they can get this new control system to be just as good as the old one (that cost way less than half of the new one)!
whimpers Why, oh why couldn’t we have just upgraded to the PIC32 (80MIPS) or even the Querk controller… 
-q :yikes:
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.
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.
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.
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.
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.
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.
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.
Q. As the FPGA code is finalized, will NI release a list of sensors that will be supported?