Re: The 2009 Control System Q&A Thread
 

First, some quick background. I love NI hardware, but really don't like LabView. At my Co-Op we used a whole bunch of your hardware (M-Card, 8-port serial card, 4 axis motion control card, can bus module, VBAI) to build a testing robot and ran it from Visual Basic in Windows XP.

I really like the ease of using calls to the CVI libraries... will the same CVI calls be available in the Wind River C environment?

Also, I don't know how much of your (awesome) vision system you're including, but do you know if we'll be getting vision assistant or VBAI?

If you can pick... I find VBAI much easier to use and more powerful, and it's very easy to load up an inspection with a CVI call.

How much resolution do the PWM outputs have? What frequency do they output at?

One last question on the 150lb weight limit: If this is true, why are batteries and bumpers not included in the weight limit? FIRST robots currently weigh a good deal more than 150lb with a full complement of bumpers and batteries. Sorry, I was thinking 120lb not, 150. :o

Thanks,

-q

I'll focus on the HW answers (Greg can snag the SW):

A: The PWM periods are configurable and the 9403 DIO module has an update rate of 6.625us. The period would depend on the type of motor controller that is used. While I can not speculate on future motor controllers, I can say that the IO module was selected with this update rate (and the resulting resolution/period ratio) in mind.

I don't know that answer for 2009 - that will be completely up to FIRST.

Re: The 2009 Control System Q&A Thread
 

Regarding the 150lb weight limit, I certainly hope that a 120 lb robot + 15 lb bumpers + 13ish lb battery doesn't "weigh a good deal more than 150 pounds".

A few years back, we learned that not all SLA batteries are created equal. There are mass differences between samples and we found out that robot weight changed substantially depending on which battery was installed during inspection. So... for consistency, we now weigh robots without the 12V SLA battery installed.

Russ Beavis
Chief Inspector

Re: The 2009 Control System Q&A Thread
 

I'm not sure I understand the answer. I'm not looking for the toolchain or C tools, but rather just the documentation of the API for what currently ships with cRIO in terms of cRIO's version of VxWorks and the special FPGA interface. Since the C programming interface is not currently customer visible, my interpretation of the above is "Not currently available, will be created and shipped with the H/W"?

Re: The 2009 Control System Q&A Thread
 

Your interpretation is correct. The C interface for the FPGA are not released yet.

Greg McKaskle

Re: The 2009 Control System Q&A Thread
 

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

Re: The 2009 Control System Q&A Thread
 

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.

Re: The 2009 Control System Q&A Thread
 

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

Re: The 2009 Control System Q&A Thread
 

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.

Re: The 2009 Control System Q&A Thread
 

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

Re: The 2009 Control System Q&A Thread
 

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[*] 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.

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.

Re: The 2009 Control System Q&A Thread
 

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.

Re: The 2009 Control System Q&A Thread
 

*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.

Re: The 2009 Control System Q&A Thread
 

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.

Re: The 2009 Control System Q&A Thread
 

Well, I can say that with the amount of resolution on the speed controllers as it sits right now, our 'rocketry control system :) ' 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: