Purchasing the 2009 controller

[synth3tk]

After reading this little conversation, I'm leaning towards picking up an NXT myself and learning to program for next year. Kudos on all the help, Danny.

[Danny Diaz]

Originally Posted by whytheheckme

So I got my hands on an NXT. Should I just simply install LabView, and download the toolkit? Once I do, where should I get started? Is there some kind of getting started guide for LabView+NXT?

Geez, What a n00b.

Yes, follow these steps:

1. Install LabVIEW from the 2008 KOP
2. Download the toolkit AND the patch for 8.5
3. Install the toolkit (Extract the ZIP, there is a setup.exe in there)
4. Install the patch for 8.5

Everything else you need is here:

• http://zone.ni.com/devzone/cda/tut/p/id/4435

Notice on the bottom of the page is a section with "Helpful Resources." The second link in that section is
"View the Getting Started Guide" and it has everything you need to know about getting started and connecting up with the NXT through LabVIEW. The 4th link is "View the Advanced Programming Guide", and it contains the full NXT Toolkit programming guide. Each VI has help for it built into LabVIEW, and once you get the hang of programming LabVIEW it becomes fairly natural.

If you run into any specific problems, come see me in the LabVIEW Forum here on ChiefDelphi and I'll be glad to help you out.

-Danny

[MWagon]

Great info & advice Danny. Much appreciated!

[yoyodyne]

Danny,

In the table of programming environments for NXT http://www.teamhassenplug.org/NXT/NXTSoftware.html

It says that the NI Labview Toolkit lacks events, bluetooth, floating point?, and data logging. - Is this true? I would have thought that the Labview toolkit would provide a superset of all other functionality.

Do you know if RobotC, which seems to have a Yes in every column at least for a windows environment would be useful training? I guess that would depend on what WPI is planning on putting over VxWorks.

Thanks,

Greg

[Danny Diaz]

Originally Posted by yoyodyne

In the table of programming environments for NXT http://www.teamhassenplug.org/NXT/NXTSoftware.html

It says that the NI Labview Toolkit lacks events, bluetooth, floating point?, and data logging. - Is this true?

NI LabVIEW NXT Toolkit Lacks Events - TRUE*.
NI LabVIEW NXT Toolkit Lacks ability to partner the NXT Brick to 3rd party Bluetooth Devices - TRUE.
NI LabVIEW NXT Toolkit Lacks ability to do floating point - TRUE**.
NI LabVIEW NXT Toolkit Lacks Automatic Data Logging Mechanism - TRUE***.

* - You don't really think the cRIO supports interrupts, do you?
** - I say true only because that's what I've always been told, I am having a hard time finding the correct resource to completely back that claim up 100%.
*** - You can always data log yourself, by writing data to a file as it's read.

Originally Posted by yoyodyne

Do you know if RobotC, which seems to have a Yes in every column at least for a windows environment would be useful training?

If you are an FTC team, or an FRC team that has never worked with C before and direly want to learn C, I will say ABSOLUTELY. However, the C interface is looking to be quite different between how you program an NXT device and the cRIO (only based on what I know about programming VxWorks' C interface and RobotC for NXT). As it stands right now I cannot say anything definitive about how the cRIO C/C++ interface is going to resemble anything you can get your hands on today without buying a VxWorks development license (I wouldn't even consider it).

Originally Posted by yoyodyne

I guess that would depend on what WPI is planning on putting over VxWorks.

Exactly, for C/C++ I'm afraid I must agree it's primarily in the hands of WPI. While NI is providing some support and working with WindRiver on the toolchain, WPI is leading the charge in most all other respects for this aspect of programming the system.

-Danny

[yoyodyne]

Danny,

Thanks for the information. What I was thinking about but didn't ask correctly is if the capabilities that are lacking in LabView for NXT might make the environment significantly different than it will be with the cRIO. It probably doesn't matter unless there is a better alternative right now for getting some practical LabView experience this spring/summer. We have been a C development based team mainly because it would have been a financial strain to buy EasyC seats for all our programmers. Also, with the excellent code that Kevin Watson wrote we really didn't need WPILib and without the WPILib source it was not possible to teach what was really going on at the hardware interface. We had some really great success stories of students building their own microcontroller projects, especially with the Atmel devices that really need no glue and no programmer other than a serial port and a few zener diodes. It was largely due to minor mods to Kevin's code that the students got the confidence to go there...

I'm thinknig that with VxWorks already abstracting the HW the low level experience is gone unless we add a co-processor (that probably cannot be justified from a need perspective).

We looked into the LabView simulation capability but it didn't look at the time as though that would work without EasyC. However we probably could have used MPLab and just made sure that we were populating the dashboard packets with what the VI was expecting. On the topic of the simulation environment was there any capability to model the mechanical system with motor power, wheel friction, CG, weight, etc? Never got to tutorial 3. That would be really useful. What we do now is measure the system response the hard way by inserting step changes in the PWM outputs and then record the wheel shaft encoder and gyro outputs and try to come up with a low order polynominal fit to model the system. Of course this year we hade a mecanum drive with no suspension that did not stay co-planer so there probaby was no hope for modeling.

Thanks,

Greg

[Mike Mahar]

Originally Posted by Danny Diaz

NI LabVIEW NXT Toolkit Lacks Events - TRUE*.


* - You don't really think the cRIO supports interrupts, do you?

-Danny

I can't tell if you are kidding or not here. Does the cRIO support interrupts?

[Danny Diaz]

Originally Posted by Mike Mahar

I can't tell if you are kidding or not here. Does the cRIO support interrupts?

I was actually wondering if anyone actually had the opportunity to read the technical specifications for the cRIO and realized there ARE NO INTERRUPTS SUPPORTED ON THE cRIO. I'm guessing not.

Instead of having interrupts, you have an FPGA - the FPGA is a pure polling mechanism, but it's extremely FAST. So, instead of having interrupts taking time away from the main processor, you've got an external unit managing a fast polling strategy for reading external sensors.

-Danny

[Alan Anderson]

Originally Posted by Danny Diaz

I was actually wondering if anyone actually had the opportunity to read the technical specifications for the cRIO and realized there ARE NO INTERRUPTS SUPPORTED ON THE cRIO. I'm guessing not.

I read the "technical specifications" that I've found. None of them say anything about interrupt support one way or the other.

I'm a little uneasy about this news. If there aren't any interrupts, how will it be possible to do control loops that depend on doing measurements and computations at precise intervals? How can even a simple speedometer function be implemented? I'm guessing -- I'm hoping -- that what you mean by "no interrupts supported" is not the same thing as what I'm thinking of.

[Mike Mahar]

I'm assuming that there must be some sort of way of scheduling things. VxWorks is a multi-task RTOS. How do you schedule anything without any interrupts? For example, this year we used the gyro which is a rate sensor. To get an angle we had to integrate it over time which requires an accurate time base. The FPGA could do this for us but we don't know what is in the FPGA and we can't change it. If the function that we need isn't there, how do we work around it? Similarly, the accelerometers can give you speed by integraing over time and then you can get distance by integrating the speed over time. In this case the speed isn't even a real input and is unlikely to be in the FPGA.

I've read up on the mpc5200 that is in the cRIO and there are 8 timers built into the processor. I suppose that those will still be available.

[Joe Ross]

Originally Posted by Danny Diaz

I was actually wondering if anyone actually had the opportunity to read the technical specifications for the cRIO and realized there ARE NO INTERRUPTS SUPPORTED ON THE cRIO. I'm guessing not.

Instead of having interrupts, you have an FPGA - the FPGA is a pure polling mechanism, but it's extremely FAST. So, instead of having interrupts taking time away from the main processor, you've got an external unit managing a fast polling strategy for reading external sensors.

-Danny

For things like quadrature decoding, I'd expect that the FPGA would latch the input. Since it is an FPGA (hardware, as opposed to software), it processes everything in parallel.

CompactRIO whitepaper has a lot of great details about the architecture.

Originally Posted by Mike Mahar

I'm assuming that there must be some sort of way of scheduling things. VxWorks is a multi-task RTOS. How do you schedule anything without any interrupts? For example, this year we used the gyro which is a rate sensor. To get an angle we had to integrate it over time which requires an accurate time base. The FPGA could do this for us but we don't know what is in the FPGA and we can't change it. If the function that we need isn't there, how do we work around it? Similarly, the accelerometers can give you speed by integraing over time and then you can get distance by integrating the speed over time. In this case the speed isn't even a real input and is unlikely to be in the FPGA.

I've read up on the mpc5200 that is in the cRIO and there are 8 timers built into the processor. I suppose that those will still be available.

I've never worked with VxWorks, but it's very likely that uses one or more of the hardware timers to provide software timers at whatever rates you want. From the link above "Timed loop structure for multirate deterministic control"


After reading the whitepaper, I'm very happy with the architecture. My only qualm is that without real interrupts in the user code or the ability to reconfigure the FPGA, it will be impossible to add certain types of sensors without support from NI. I'm sure they will do a good job getting all the common ones in, though.

[wireties]

VxWorks does indeed support interrupts and timers. A VxWorks BSP (board support package - code to support an architecture port of vxWorks on a unique piece of hardware) will possibly include 3 timer libraries.

The first is the system timer and includes functions like sysClkRateSet, sysClkRateGet, sysClkEnable etc. The system timer library is mandatory and is used by the BSP to generate the tick timer that support pre-emption. The system tick normally runs at 60Hz or 100Hz. It is common to raise the rate up to 1Khz. There is a watchdog library that hooks the system timer ISR to do its work. It is pretty easy to create watchdog, interval and one-shot functions. The watchdog library only works in the kernel context, if you are working in a RTP (real time process - very much like processes in linux) the POSIX timers are available.

The second timer library is very similar to the system timer library, called the auxiliary timer library and includes functions like sysAuxClkRateSet, sysAuxClkEnable etc. It is commonly provided but is optional. Programmers make use of the aux timer library if greater precision (that the system timer) is necessary. It also works only in the kernel context, there is no analog in a RTP.

The third timer library is the timestamp library. It is normally used by system profiling functions in the kernel context. It is less commonly provided and is optional. The idea is to support a very high-res timestamp rather that interval and one-shot functions.

Finally, rolling ones own timer is pretty easy and not unlike using the timers on the 2004-2007 FIRST systems. You set a clock source, pre-scalar and initial value, register a ISR, enables interrupts and let it rip. But vxWorks makes it muuuuch easier to write interrupt service routines.

HTH,
Keith

[wireties]

"im betting it cant cost NI more than $300 in order to manufacture this cRIO and all of its components"

That is way off. Students and indeed the general public are misled about the costs of computer-like things. We are used to buying consumer products which are made by the tens or hundreds of thousands or millions in China. NIs costs for the cRIO and modules are probably nearer to $1200 if they make them thousands at a time. And this is after putting in at least $500K in development. The development number would be much higher but this is not the first cRIO nor the first VxWorks BSP for this processor family.

NI has a great reputation for quality and good thorough engineering. My concern is that they are also quite expensive. If NI sells the cRIO for something similar to the current RC/OI they will be losing money. Wind River's products are the best-in-class but also pricey. I'll bet Wind River is just giving away development platforms (that might normally go for $20K each). One hopes that new management at NI and Wind River will not cut off FIRST after a few years. Until they do this control system is cool and students will get a real-world close-up look at an industrial strength setup. The current FIRST RC/OI setups are really just souped-up toys in comparison.

[Greg McKaskle]

Once upon a time, THE computer company, IBM, was releasing this little product called the XT. They needed a GPIB board to allow it to be used in labs and mfg test. NI was able to land a make/break contract, providing the boards at a price that such a small company couldn't really manage.

This gamble forced NI to invest heavily in its manufacturing, drive down costs, allowed it to gain a foothold against bigger suppliers, and to self-finance many new products. Identifying investment opportunities and doing what it takes to win the gamble, is IMO one of the intangibles that separate well run companies into the goods and greats.

Personally, I think the cRIO architecture is a winner, and now in its second generation, upping volumes, driving down costs, and getting it in the hands of smart and motivated people, is a similar gamble, well worth taking. NI isn't prone to walking away from things like this, and "new management at NI", is not something I'd really worry about either. I'm biased, but I think NI has a very strong and stable culture, not only at the top, but throughout the organization.

Anyway, I thought this way-back story, might be appropriate to share some of NI's point-of-view. By the way, it is always fun to see others guess at your costs, and at your levels of investment. As far as I know, no prizes will be awarded.

Greg McKaskle

[yongkimleng]

If I'm not mistaken, with the FPGA itself you can do quite a bit of fancy action-reaction or even PID loops

ADC / encoder -> FPGA ->PWM

How configurable the cRIO is I'm not sure, being here in Singapore the chances of getting my hands on a cRIO isn't very high. Yet.

Found a useful image here:


And here


One should offload most of the closed loop logic into the FPGA while the RTP handles monitoring, higher level processing, scheduling etc. Perhaps this explains why there are no support for interrupts. You don't need them! I think there is a certain level of paradigm shift from PIC based microcontroller programming to the cRIO observed here.

In my opinion, having an embedded computer in a ruggedized chassis at $1k is pretty decent. Apart from their development costs, one must remember that these are industrial grade equipment. Maybe within the range of other industrial PLD/CPLD devices.

On the sidenote, may want to consider thinking how many IFI processors, OI, etc which are already fried (dead), due to mistakes in connection such as polarity (oops!), high current surges, etc. I think the cRIO would be more reliable in this sense too.

Edit: I'm thinking of sampling a cRIO here in SG, and probably budget for it so that the kids here who were playing with vex can try out some new stuff, though I'm completely clueless how to go about doing that. Any non-FRC members have any idea?