Programming with the 2009 controller

[Danny Diaz]

Originally Posted by Damien1247

If you are right you will have made my day... (Im a Mac user) Anyone have any official releases from companies answering this?

I can officially answer that we do not support the Mac for downloading Real-Time code to the cRIO. You can develop code on a Mac, but you must use Windows or Linux to upload your code to your controller.

However, virtual machines are a wonderful thing, especially if you've got an Intel Mac that can run Windows and Mac OS X natively. In that scenario your problem is solved.

-Danny

[Shinigami2057]

Originally Posted by Danny Diaz

I can officially answer that we do not support the Mac for downloading Real-Time code to the cRIO. You can develop code on a Mac, but you must use Windows or Linux to upload your code to your controller.

However, virtual machines are a wonderful thing, especially if you've got an Intel Mac that can run Windows and Mac OS X natively. In that scenario your problem is solved.

-Danny

Danny,

Is/will the protocol used to upload programs to the cRIO be documented, as it is (or seems to be) just a simple IP transmission over ethernet? I'd be more than happy to use a protocol specification to write a loader for OS X / Solaris / any other unsupported UNIX system.

[Kevin Sevcik]

Originally Posted by slavik262

3. The new processor combined with RAM 1000 times greater than this year's processor will finally open doors to us using dynamic memory allocation. Combined with C++, this will let teams do some pretty awesome stuff.

*shudders* If you're willingly going to walk into the fray of dynamic memory allocation on a real-time, (relatively) high-speed system, you have my sympathy. I know I wouldn't look forward to tracing down memory leaks, or figuring out how to fail gracefully when my autonomous routine couldn't grab enough memory. Mostly it's something I just don't want to have to worry about.

Also, in reply to Chris's rather long post:

I just started working at Arc Specialties where we making welding robots of various sorts. And yes, 75% of our robot run off a single Omron PLC. I had the privilege of being tossed into ladder logic cold, but as you've noted, having a programmer's mindset tends to make moving from one environment to another largely a matter of syntax. I was also interested to discover that thinking in terms of small, high speed loops for programming the IFI RC developed a good frame of mind and some useful habits for programming in ladder logic. I'm sad to see the IFI controller go for this reason in particular. It's been preparing a large number of programming students for a smooth-ish transition into the ladder logic that's in charge of the vast majority of robots out there.

I'll also agree that I really like Labview for data acquisition, signal processing, and other high speed applications like motion control. It's difficult to get around the fact that implementing a state machine or anything like it in Labview can get pretty annoying. I had to implement one for some automated testing of a device in college and keeping track of every input and output from the case structure, as well as how to manage the transitions, quickly got on my nerves. And that was a fairly simple and straightforward sequential state machine. Unless NI will be providing us with the State Chart module, which seems unlikely, I'm not at all going to relish our team developing an autonomous mode of any real complexity. Nor implementing any other automated functions during teleop mode that can't be broken down into simple signal processing with an on-off switch.

Also, thanks TONS for MrPLC. I'm uncertain I would have survived my first project here without that forum and the resources and documentation provided there.

[Danny Diaz]

Originally Posted by Shinigami2057

Is/will the protocol used to upload programs to the cRIO be documented, as it is (or seems to be) just a simple IP transmission over ethernet?

As far as I know, the answer to that is no. We have never and possibly will never release protocol information such as that, especially since it changes between some LabVIEW versions.

-Danny

[slavik262]

Originally Posted by Kevin Sevcik

*shudders* If you're willingly going to walk into the fray of dynamic memory allocation on a real-time, (relatively) high-speed system, you have my sympathy. I know I wouldn't look forward to tracing down memory leaks, or figuring out how to fail gracefully when my autonomous routine could grab enough memory. Mostly it's something I just don't want to have to worry about.

Obviously I won't be pulling any special tricks. Dynamic memory will be the thing addrest last AFTER everything else is working. I won't be using it extensively; I'm just saying it will open up some interesting avenues.

Come to think of it, I'm not even sure I'll use it. Just the prospect of finally being able to use it is rather interesting.

[Kevin Sevcik]

Originally Posted by slavik262

Obviously I won't be pulling any special tricks. Dynamic memory will be the thing addrest last AFTER everything else is working. I won't be using it extensively; I'm just saying it will open up some interesting avenues.

Come to think of it, I'm not even sure I'll use it. Just the prospect of finally being able to use it is rather interesting.

I find the prospect of being able to do OCR on our robot similarly interesting. This doesn't mean I have any desire whatsoever to use this feature in an FRC competition. *Looks meaningfully in the direction of the GDC*

[Guy Davidson]

Originally Posted by Danny Diaz

Of course, I'm going to be a little bit biased on the side of programming the FRC system with LabVIEW, though I will most certainly take advantage of the C Interface Node and the Call Library Node within LabVIEW to compliment our code, which allows for LabVIEW/C/C++ hybrids. Last time I heard this was still going to be supported, but it is all still preliminary.

-Danny

Danny,

How would you combine LabVIEW and C? What functions, for example, would you use C rather than LabVIEW for? Could you give a few examples or links to see how this all comes together?

Thanks.

[Danny Diaz]

Originally Posted by Guy Davidson

How would you combine LabVIEW and C?

Through the Code Interface Nodes and the Call Library Nodes, but after thinking about it a little more I think I would not use the Code Interface Nodes since the Call Library Nodes are the easiest to work with.

You can build .out files for VxWorks (the equivalent of .dll files for Windows/ETS) and call into them using the Call Library Node - this allows you to have a C-compiled library that you can use. It's incredibly easy to build libraries with WorkBench, the VxWorks IDE you should be getting, we even have a step-by-step instruction set to help you build your own libraries under VxWorks.

Originally Posted by Guy Davidson

What functions, for example, would you use C rather than LabVIEW for?

There are multiple reasons why it would be beneficial to have a hybrid system.

First, I'm what I call a "realist" - I don't think you should be forced to take algorithms you've already written in C and convert them to LabVIEW just for the sake of having them in LabVIEW. I know there are a lot of great algorithms for performing lots of different kinds of advanced calculations floating around, and a good number of them are in C. Sometimes you want to break them apart and study them in-depth in order to become a master of the algorithm, and sometimes you realize you have 2 weeks before ship and you just want to plug-and-chug. Being able to build/access C-based libraries are beneficial in this case.

Second, having a c-based library gives you the power to change out modules on a filesystem level, or access modules on a given filesystem. This makes a lot more sense on NI controllers with USB Mass Storage support, you could have different program code on different USB flash drives, and change them out at will. You can do the same thing with the FTP server on the controller, it would allow you to update specific portions of your code without recompiling everything (and it can also be done through an automated script).

Code sharing. If you have the .out files, you can share code with teams using the LabVIEW interface as well as the C/C++ interface. This would be especially useful for autonomous algorithms and sharing them with rookie teams without autonomous.

Lastly, using C instead of LabVIEW can be a valuable crutch. Depending on when the controller gets in your hands and how much time you have to learn how to use it, having an out can make you more comfortable with the whole 6 week deadline thing. I would hope that teams would pick up the LabVIEW software we provided in the KOP, maybe even pick up an NXT robot and the LabVIEW NXT Toolkit, and learn how to use LabVIEW in the off season. However, that's not going to be possible for all teams. Giving a way to experiment with LabVIEW but being able to use some C code if necessary can help facilitate teams moving to using LabVIEW without being cornered into an all LabVIEW or all C/C++ situation.

Originally Posted by Guy Davidson

Could you give a few examples or links to see how this all comes together?

LabVIEW itself is chock full of examples. Just use the example finder found in the lower right-hand corner of the LabVIEW 8.5 opening splash screen. Look up "Call Library Node" and you'll find tons of examples of how to use this feature.

I hope I answered your question adequately.
-Danny

[jwr134]

Can someone give a list of the programs that teams will be able to program with in 2009 and following years?

[yoyodyne]

Originally Posted by Danny Diaz

I would hope that teams would pick up the LabVIEW software we provided in the KOP, maybe even pick up an NXT robot and the LabVIEW NXT Toolkit, and learn how to use LabVIEW in the off season.

Danny, I am doing just that and the examples work great with the NXT but I don't know why or how. For instance in the getting started guide there is the NXT microphone example. I am trying to figure out where the sample rate is set. There is a lot more detail shown in the VI hierachy dispaly but I haven't been able to drill down to the basic configuration info. Is it worth trying to figure out how the VI's work at a lower layer (at least for the NXT) VIs or are the configurations kind of hard coded and not accessable? Now that I think of it I don't even know how the system figured out what sensor input I pluged the microphone into. I need to spend more time reading the generic help info but searches on "sample rate" did not turn up anything that looked fruitful.

[esquared]

There are a few key ideas that I believe have been missed so far in this thread, but picked up on in other similarly-themed threads.

1.) Labview VS. C/C++ - A hybrid approach is completely reasonable and could be equally efficient as a pure LV or C project. LV has the capability to call C-esque libraries on this real-time target, so your team’s C programmers can still code their PID controls for an end effector, but have the top level LV code simply provide the position target to that block. It remains to be seen whether there is any significant overhead in a LV->C library call when in a real-time situation. It was made clear in the mentor’s meeting in Atlanta that the reverse would NOT be possible, wherein a C project could call Labview libraries/functions.
2.) This is not your momma’s Labview – LV for the cRIO becomes code that can run in real time. It is more like VHDL where you describe how you would like signals to be manipulated, where you would like them to go, and let the compiler/synthesizer take care of the details. A similar approach is used by Matlab’s Simulink program, where there are tools for going directly from a discrete-time simulation of an algorithm to object code for a DSP or microprocessor. Is Matlab/LV higher level programming? Yes. Do you want to write an application to provide a testbench for your code, graph/filter/FFT your results, etc. for your C program? Probably not. LV will DEFINITELY help in testing stability/response time of your various control loops, something that was difficult before or only achievable by physically trying it on your robot.
3.) There is a strong commitment by FIRST/NI/WPI to keep library development equal between the C and LV branches. This was specifically asked and addressed at the mentors meeting. Assuming they live up to this commitment, I do not expect teams using C to get stomped by Labview teams, even for vision processing.
4.) Accessibility – Some of the LV capabilities demonstrated on the practice field were fantastic. Draw a line on the screen, your robot will follow it. What gets lost when you have this sort of accessibility is the details of how something like this works. The two girls on our programming team spent their whole 6 weeks learning how to interface with a gyro, how PID works, how to tune PID constants to achieve a stable response, how to write a basic state machine to accomplish a series of motions, and then combining it all to knock trackballs off in any position and drive our robot around the track in hybrid mode. They know how all of this works because they spent the time and effort to understand it, and they put blood (well, I did), sweat, and tears into it. Scoring 12-20 points in hybrid mode was a lot of work, and when we’d get out on the field and do it they were excited because they made every motion out there happen. Drawing the robot path with a mouse on the field, and having it follow it automagically… what did they learn? THIS is what FIRST is all about – not making robots work, but learning and teaching HOW robots work.

Apologies in advance for making everyone’s scrollbars that much tinier.

--Eric

[Chris_Elston]

Originally Posted by Danny Diaz

Anyway, LabVIEW has a State-Chart, Ladder Logic, and other types of plug-in modules you can use to alter how you program LabVIEW.
-Danny

It's OK if it won't be provided in the KOP, my main question is:

Does the CRIO controller support it? If we as a team elect to purchase the state-chart module or ladder logic module direct from NI, will the hardware support it?

[Gdeaver]

On the LEGO NXT web site there is a link to some downloads for the schematics and some low level docs on the interface.

I believe that a graphical programming environment is an excellent way to bring a larger population of students in to programming. My experience over the years has led me to believe that only 10 to 20 percent of the general population have brains wired that allow them to be natural programmers. A larger percent can learn to program, but they really struggle to master the basic abilities. I've noticed that the more visual and graphical the programming environment the easier it is to get the "programming challenged" going. This is especially true when the graphical objects refer to real world objects. The NI cRio and Labview system at the low level are much more complex than our previous controller. I worry that if you EE and professional programmers attack the programming of our new system in c-c++ you will alienate a large percentage of our students. I submit that First and our society in general would be better served if you elite programmers focus your immense skill base on abstracting our new system to a high level graphical object system where we concentrate on robot behavior and algorithms instead of low level constructs. If it is done right there will be layers that that students can peel back and expose the complexity as they become more proficient. Automation and connectivity are rapidly permeating our society. In the future we will need a very large work force to service all the automation. This will never happen unless you professionals start designing system the Rest of society can deal with.

[Phalanx]

I can say for myself with absolute certainty that for Mentors that are "Systems Programmers" and "Low Level" architects like myself (micro controllers and PC's weren't invented yet when I began my career) we will have a learning curve and challenge in front of us.

I have done the Labview tutorials, and worked slightly with the "Robot Toolkit" yet I still find myself struggling. Mainly because I believe it to be my way of thinking.

So my question to ask, would be, just how many Mentors have a strong working knowledge of Labview to meet this new challenge, and of these how many of them would be willing and interested to provide multiple hands on workshops to teach the rest of us and students as well?

[Danny Diaz]

Originally Posted by esquared

THIS is what FIRST is all about – not making robots work, but learning and teaching HOW robots work.

I was with you up until right there. Even Dean Kamen has come out and publicly said that FIRST is not about teaching engineering, it's about inspiration. I figured I'd throw that out there since it gets thrown in my face enough as it is.

-Danny