Programming with the 2009 controller
 

I am extremely excited about the ability to finally write code in C++. Other than what I've read on the site, does anybody know any specifics about how this will work? Will we be able to simply compile and transfer the file using wireless into the controller? Will we have to use a specific IDE or will the compiler be useable across multiple IDEs provided we use the libraries given to us for the processor? My dream would be to write the robot code in the Microsoft Visual C++ IDE, which is better than MPLab by leaps and bounds, mostly due to Intellisense.

Re: Programming with the 2009 controller
 

The information I've been able to gather is that we will be able to use LabView NI or WindRiver IDE. WindRiver is supposed to be very nice, so that will be suitable for C++ development, I think. Personally, EITHER of those is superior to Visual C++ for the sole reason that it's a Microsoft product... but hopefully, we will all be able to use whatever environment is most comfortable for us.

Re: Programming with the 2009 controller
 

Hooray for anti-M$ sentiment...

My main goal is to get away from MPLab and it's fun casting issues. I'm hoping for Visual C++ because I've used it extensively for school projects and had great success with it.

Regardless of IDE, I can't wait to program the robot in C++. Object-oriented programming combined with 1,000 times the memory of this year's RC and a much faster processor will let teams do things we've been dreaming of for years.

Re: Programming with the 2009 controller
 

I'm thinking of trying LabView for 2009. Looking at some videos on the NI website, it looks pretty cool. Anyone know how easy/hard is it to learn and use LabView?

Re: Programming with the 2009 controller
 

The learning process for LabView takes wildly different paths for different people. I've watched complete novices pick it up in basically no time.

On the other hand, it was very difficult for me. I think that's probably because I was learning it from someone who knew it inside and out and thus could do everything quickly, but who was very poor at transferring that knowledge to someone who couldn't follow it that quickly. Most of my time was spent doing two things: unlearning a lot of what I learned about procedural programming, and getting used to the multilayered view of programs that LabView provides.

I still am not at all comfortable with it, and I still cannot "read" a LabView program written by an expert.

Re: Programming with the 2009 controller
 

I definitely agree with you on this, Alan. I've used both LabView and Simulink in various project to program embedded targets, and it has nearly always been easier for me to understand and conceptualize what is going on when I write my own C code. That said, I do have a lot of friends and know many people who swear by Simulink and LabView for doing their programming for various types of things. They are extremely versatile products. I would imagine though that they might be easier to pick up for someone without any programming background than C or C++, although I personally feel that there are a lot of insights into controls and programming that you can't gain by using such high level, abstracted ways of programming.

Re: Programming with the 2009 controller
 

I think it's great that FIRST has expanded our variety of IDEs.. I read on the 2009 PDF that Windriver is basically Eclipse.. Can somebody please explain? Is Windriver some comerical spinoff of a perfectly good Open Source project? Or is it just a set of plugins for the standard Eclipse IDE?

Either way, Eclipse is a great program (widely used in the industry).. Labview also shows promise as a learning tool, though I am a big fan of starting newbies off with writing real C code..

On another note, does anyone have any idea as to what libraries will be onboard the cRIO? Also, what libraries will FIRST or WPI be supplying? I assume they will write some of the very low level (pwm generation/timer interface) for us.. If you know, do tell!;)

The most exciting thing for me.. Floating points and Objects!!! Woohoo!!

Re: Programming with the 2009 controller
 

Eclipse as a whole is a set of plugins for a very small core platform. The open source components include that core platform and various development tools that can turn Eclipse into and IDE. One of these open source development tools is the CDT (C/C++ Development Tooling). However, the open source product only integrates with variants of GCC (and I think possibly Visual C++ in the latest version). So WindRiver basically added support for their compilers, debuggers, etc. to the CDT (which does require a good deal of effort) and repackaged it and sells it to you as WindRiver Workbench. Their website for it is here.

Re: Programming with the 2009 controller
 

Thanks for clearing that up.. I watched a bit of their video demo and found "We support many host OSs, including Windows, linux, and Solaris!" a bit disappointing (no love for the mac!)

Could Eclipse be used on the mac? (for purposes beyond text editing/versioning, for the cRIO?)

Re: Programming with the 2009 controller
 

Thanks for clearing that up.. I watched a bit of their video demo and found "We support many host OSs, including Windows, linux, and solaris!" a bit disappointing (no love for the mac! [which, btw, has some 8-12% of the market now])

Could Eclipse be used on the mac? (for purposes beyond text editing/versioning, for the cRIO?)


Also,
I am quite certain the cRIO supports GCC. Not so sure about the visual c++

Re: Programming with the 2009 controller
 

Eclipse would work on a Mac, since it is Java based. (Plus, Wikipedia says it is cross-platform)

~DtD
Blue Valley Robotics

Re: Programming with the 2009 controller
 

<clip>
</clip>

Wind River is a company that develops toolchains such as compilers, linkers, and debuggers. My company uses them for cross compiling from a standard Wintel box to an embedded PowerPC platform. From experience I feel they are a good pick for this aspect of the new controller, and should hopefully bring fewer casting issues and more useful compile/link error messages.

For the poster who mentioned Visual C++, most of the gain of using Visual C++ is the tight integration with developing for MFC/.NET. Even if you could set it up to call the Wind River tools, the bulk of the nice features would go unused. That doesn't mean, however, that you couldn't use VC++ to write a Labview-esque frontend to send/receive data from your robot...

Re: Programming with the 2009 controller
 

Does any one in this thread know if the 2009 controller can be programmed with the traditional industrial languages?

such as:

Ladder Logic
State Logic
Flow Chart Diagram
Structured Text (yup...C++ is Structured Text)

Are these optional? Or is labview only function block programming only?

National Instruments for YEARS has been bugging me to try a controller to replace the PLC (programmable logic controllers) I use in machine designs, and have said we can program in ladder logic, STL, flow chart, ST, when we switch over to this controller. That's where I am coming from with this question.

Or is C++ and function block (labview) the only options? And those other few mentioned in this thread....

Re: Programming with the 2009 controller
 

The only supported ways they mentioned were WindRiver C/C++ (Using WPILib), Intelitek easyC, and National Instruments LabView. However the WPILib for this RC will be open source so the options are not set in stone. Also I was told we will not have access to program the FPGA next year but it is something they are evaluating for future years.

Re: Programming with the 2009 controller
 

Eeek! :yikes:

Sorry, I have an allergic reaction to Ladder Logic.

Anyhow, I think the reason your NI rep said you could program in all those methods was that if you arrange your icons right on the screen in Lab View, it runs just like ladder logic. Similarly, with a clever use of the filmstrip control you could make it act like a flow chart too. I know they have C boxes that work in there somehow too.

If I were the programmer for our team next year, I'd go the C route if they give you cVI libraries. The labview system has a lot of oddities to it, like (this is a dusty memory) you can do everything to an array except one critical function like writing or reading a specific element or something of the sort, can't remember quite. Also, LabView pictures are REALLY hard to document and get jumbled really fast. The pictures aren't too portable really either.

And finally... this won't seem like a big issue till you're using it... LabView has no zoom. The little one or two pixel wide terminals you have to hook wires to don't get any bigger. :ahh:

It'll be interesting, any which way it goes...

-q

Re: Programming with the 2009 controller
 

I've been programming and designing PLC based controls for years...10+ years… Of course, I am partial to ladder logic. My job title: Sr. Controls Engineer. I have my own website dedicated to PLC based controls: www.mrplc.com written a few papers on it. I have several example codes to download.

When I say "robotics" to a FIRST student, they are thinking MARS rover or first robotics, or even animatronics type robotics. Like Disney based characters, etc.

When I say "robotics" to my co-workers or anyone I contact in my everyday life, they are thinking, ABB, Fanuc, Motoman, industrial six axis robots. Robots that to do repetitive tasks.

I've declared a difference to my students and I figured out it's best to explain it like this:

If you're going to be an electronic engineer, a person that designs circuit boards, you'll more likely be apt and need to learn C++ so you can program micro processors. You'll be working for someone like United Technologies, they make thermostat controllers, or BAE, Raytheon, any automotive ECU's and such or any type of electronics that require a micro processor. Could even be a toy company too, like Tyco Electronics. Tickle Me Elmo stuff.

If you're interested in automation, or stuff you see on the TV program "How It's Made" like machine automation, you'll need to learn ladder logic. If you want to play with six axis industrial robots, learn ladder logic. Though most six axis robots are not programmed in ladder logic, you'll need a PLC to interface with. The PLC is the master controller of most all automation processes. Why? It's robust, been around for years, easy to program. One of the BEST FEATURES of the PLC is the ability to programming and make code changes on the fly. Or in the PLC world it's called "online changes". I can go online with a PLC while the production line is running, and make code changes on the fly and not disrupt the production line, hence no downtime. Places like GM, Ford, assembly plants charge their suppliers $10,000 a minute for each downtime caused. There is no compile process in PLCs. PLCs are designed around robust wiring hardware as well. Most use standard hookup wire, 16 AWG or smaller. PLC don’t crash or blue screen. Most roller coasters are controlled by two PLC’s. Each PLC ladder logic must match before it tells an output to turn on in a roller coaster ride. The Raptor roller coaster in Cedar Point is controlled by 4 PLCs. Two PLCs control the trains on the track and make sure that no train enters each other’s “zone”. The other two PLCs monitor safety. Each seat belt has a digital input and each PLC must agree logically before any output is processed. The PLCs that control the Raptor are Allen Bradley PLC5 type PLCs. PLC5 type PLCs are octal based processors however have been a standard in automotive production for decades. I think all of FORD plants still use PLC5 type PLCs, most are now switching over to Control Logix based PLC platforms. Learning to programming a PLC is like programming in assembly. (only thing I can think of to compare it to). Your working in “bits” and “bytes” and need to move “words” of data around logically. It’s as basic as you get. Most PLCs have built in functions like a “timer” which make it easy to program.

In my experience so far with working with National Instruments, they excel in data acquisition. Traditionally in the past, it's been quite cumbersome to do data acquisition in a PLC. In the OLD days, the PLC had one RS-232 port, channel 0 they call it…. and quite often even to get a bar code reader into a PLC to sort a package on a conveyor line was a chore. Or even a standard weigh scale running the weight through the RS-232 port of a PLC was not fun. No fun, but I've become an expert ASCII parser learning to do it this way. Quite often the thought process of reading a weigh scale “string” through an RS-232 port, then parsing the data you want say the weight of the box, then converting the parsed data into a integer based number so you can make a logical decision on this was quite tricky.

Then not long ago, National Instruments really started to catch on in the automation industrial world, and wow...the data acquisition and test data you can get is amazing. So my gut feeling of most places that deal with automation or manufacturing still use PLCs to control the automation, and have a National Instrument controller for data collection. Before National Instruments I used a product called WinWedge and other products similar. Where National Instruments has my attention is their ability to create VI's for just about everything, like standard off the shelf vision systems. National Instruments can talk on a multitude of protocols. Ethernet, Controlnet, Devicenet, Profibus, RS-232. Back in the old days products like WinWedge took the cumbersome ASCII parsing out of play, but was only good to interface with RS-232 devices such as scales, bar code readers, etc. This is where I see National Instruments really start to shine. Recently though, they are starting to try and take and replace PLC’s with their controllers….in my opinion right now, I dunno.. I am not sold. I need more convincing along with a lot of other Control Engineers I know. I have never heard of National Instruments using C++ until now from FIRST. From a control point of view, I think that would be better to write and control a process in C++ than function blocks of Labview. If I was using a National Instruments controller to replace a PLC.

I've talked to several industrial based control engineers and right now, we are still mostly sticking with PLCs for our main process controls. Every factory out there will "generally" have a PLCs at the heart, then other types of controls like a National Instruments test stand that will collect data and store it away into a database. Something that would take a long time to do in ladder logic, A.K.A. a PLC, a National Instruments ability to data collection and analyze test data takes the cake. Those engineering peers of mine that have tried to use National Instruments for control have suffered and found it really hard to make use of process control in labview function block. Simple multi-task state logic, or digital input debounce logic, that a PLC can do with a couple rungs of ladder.

Basically what I am getting at is ladder logic is not for everyone, but in certain industries, you've got to learn it. It depends on what students choose to purse.

Students of mine in the past needed some guidance and I get asked all the time which is the best programming to learn. I sit them down and explain to them what I have explained here. It depends on what you think you might be interested in doing. I don't discourage either, even though I am partial to PLC.

However from the programming perspective, I still believe to this day, not everyone can program. You either have that "nak" to program or you don't. If you can think logically, learn the basics of logic flow, A.K.A IF THEN ELSE, you should be able to sit down in ANY ENVIRONMENT and program. I sit here and tell you I started mentoring for FIRST robotics in 2004, the first year the C++ controller was introduced. I had NO CLUE how to program in C++. But I had the fundamentals of programming and understood logic based thinking. Of course I was an expert in PLC ladder logic programming, but that didn't make me an expert in C++ nor did it scare me away from trying to learn this microprocessor stuff so I could continue on learned it myself so I could teach my students the best I could even though I didn't have one course in C++ programming.

In the automation world, it seems to me just about everything I touch has it's own "mnemonic" based language anyway. For example Fanuc robotics use a language called "teach pendant programming" TPP. Its mnemonic based, or you can program the Fanuc robot in KAREL as well.

My final advice to my students is to have them try and decide what kind of an engineer they think they'll want to be, then I can direct them on the best way to use your time as a FIRST student in high school. Each industry has their standards for what they use for hardware and programming languages. It's up to the students to decide which one fits them the best. I can see that alot of my past programming students will find electronics more their cup of tea because of being exposed to C++ and microprocessor based controls. PLCs and ladder logic have a purpose, C++ and MPLAB have a purpose. Each one could probably do each other’s job, but I can’t see using a PLC to control the fuel map on your injection system in your car, nor can I see PIC processor controlling a 1000+ I/O production line where it has to interface with vision systems, robotics, handle data collection request, and do all that while able to make online programming changes too.


Sorry for the long post.

Chris Elston
Sr. Control Engineer
www.mrplc.com

Re: Programming with the 2009 controller
 

Yeah, that was a pretty long post... :cool:

Anyway, LabVIEW has a State-Chart, Ladder Logic, and other types of plug-in modules you can use to alter how you program LabVIEW. I don't believe we're going to be providing those modules to teams in 2009, however.

And to answer a previous question on this thread, WindRiver uses a home-modified variant of GCC to compile programs for use with their OS, VxWorks (which runs on the cRIO-9074 and FRC variant), and they also have a port that uses diab (though the cRIO-9074 and FRC variant cannot use). NI has modified the VxWorks OS a bit to work with the cRIO controller, but we've done nothing to the compiler - WindRiver is going out of our way to make sure we have the latest and greatest tools for FRC teams to use to program C/C++ within the eclipse-based IDE they have.

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

Re: Programming with the 2009 controller
 

Chris, I'd first like to thank you very much for that post. Despite its length, it really provided a great deal of insight. :D However,

The current controller does not support C++ programming, but C. This year is the first year teams will be able to program in C++. This makes me very excited for several reasons:

1. I have grown to strongly dislike the current compiler. It misses time-costly errors such as interger promotion and overflow issues without producing so much as a warning, providing you the fun of manually searching your code (Oh! We had to cast the char to a short on line x!). A new compiler will make my day, or rather, my season.

2. C++ will finally allow us to use object-oriented programming, making code cleaner and more efficient to write and debug.

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.

Re: Programming with the 2009 controller
 

Sadly the cRio will be Windows only based on what an NI employee said at one of the sessions. Windriver (I think) is only a windows app and their license won't let them port to OS X. However this is only true for sending to the robot. So using a different OS for debugging and stuff is an option.

<conjecture>Also, my hunch is that the Windows thing only applies if you use their libraries. It is possible to program the robot using currently existing tools so we might be able to, with some extra work, do most everything on a Mac. I would appreciate if someone more familar with NI could comment on this thought. </conjecture>

Also for anyone who missed the championships and wants to see some info about the new controller the link to the NI community is http://decibel.ni.com/content/community/first.

Also, who thinks it would be a good idea if NI released pre-release libraries so that teams could get their feet wet over the summer? This is a massive change for everyone involved. The controller is bigger and heavier (2.5 lbs w/o modules) And the wiring to and from it will be different. Perhaps FRC should allow us to get our hands on stuff ahead of time to help us overcome some of these obstacles.

Re: Programming with the 2009 controller
 

Agreed. A look at the code would be rather nice. I don't want to have to figure out an entire new system and program a robot at the same time. We all have plenty to do during build season as it is :D

Re: Programming with the 2009 controller
 

I was explicitly told Windows and Linux and that the compiler is based on the GCC toolkit by more then one representative (one from NI and the other from WPI).

Re: Programming with the 2009 controller
 

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

Re: Programming with the 2009 controller
 

Sorry about that. That's what I meant. Thanks for correcting me.

Re: Programming with the 2009 controller
 

You don't need an OO language to program in OO. We did OO in C this year (well, mostly). It's just way easier with an OO language :P.

Well I guess you can't exactly practice polymorphism in C. But the whole encapsulation thing, easy.

Re: Programming with the 2009 controller
 

The evaluation download page for the WindRiver compiler (http://www.windriver.com/portal/serv..._OpenerMode=2&) lists the following system requirements:

Now that means you'll be downloading an RPM but it will be trivial for a semi-experienced Linux user to install it on any number of distros.

Re: Programming with the 2009 controller
 

um.. isn't C an object oriented language already.

Re: Programming with the 2009 controller
 

No, C is a procedural language.

Re: Programming with the 2009 controller
 

You're right, I was getting them mixed up, but if this isn't getting too off topic, what kind of
languages are there and what is the difference? Anytime I run into a different style I just adjust and then go with it.

Re: Programming with the 2009 controller
 

LABView, while I have no experience with it, is a graphical interface you use to code.

C++ is a subset of C, meaning that it follows the same syntax. C++ is basically C with added features such as classes (allowing for object-oriented programming) and templates. If you're already comfortable with C the jump to C++ should be fairly easy. Online tutorials such as learncpp.com have helped me a good deal.

While you can "fake" OOP with C, actually having classes to work with brings a whole new world o' fun into programming.

Re: Programming with the 2009 controller
 

If it will run it Linux, it shouldn't be that hard to get it to run on a Mac given the unix core. In addition, os x already runs many linux services such as apache and gcc. I am going to try and get the compiler to run ASAP.

Re: Programming with the 2009 controller
 

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

Re: Programming with the 2009 controller
 

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.

Re: Programming with the 2009 controller
 

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

Re: Programming with the 2009 controller
 

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

Re: Programming with the 2009 controller
 

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.

Re: Programming with the 2009 controller
 

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*

Re: Programming with the 2009 controller
 

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.

Re: Programming with the 2009 controller
 

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.

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.

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

Re: Programming with the 2009 controller
 

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

Re: Programming with the 2009 controller
 

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.

Re: Programming with the 2009 controller
 

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

Re: Programming with the 2009 controller
 

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?

Re: Programming with the 2009 controller
 

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.

Re: Programming with the 2009 controller
 

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?

Re: Programming with the 2009 controller
 

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

Re: Programming with the 2009 controller
 

I'm planning on doing just that for the Central Texas FIRST teams, probably sometime over the summer. I figured we'd start off with basic LabVIEW skills programming exercises from the "LabVIEW Basics I and II" provided in your KOP. Then for the next class it'll be "Bring your NXT day" and we'll learn how to program the NXT in LabVIEW using the NXT Toolkit. Then, once the new cRIO system is released, we'll hold a workshop on programming with the new cRIO FRC toolkit (I imagine it'll be a toolkit). Those who do all 3 classes should be ready for business.

As the summer draws closer we'll organize something and post details on 418's website.

-Danny

Re: Programming with the 2009 controller
 

Danny,

That's true....but what I find inspires these kids is getting them to the point of competency with the programming. I expect them to write the VI's to perform autonomous, control the drives and other actuators and implement feedback control, as well as being able to debug.

I don't expect them to become LabView experts....but I DO want to leave them with that taste of wanting more. THAT's what I call inspiration.

BTW, will the FRC Toolkit VI's that I have be of any use?

Re: Programming with the 2009 controller
 

All of which I firmly believe will be the case and then some; no matter what we did, if we didn't do that then we'd be doing a disservice to the competition.

I think that might be going on my quote board. That's what FIRST should be all about.

You mean the FRC Simulation and Modeling Toolkit VIs we provided for the IFI controller? Nope. That toolkit was designed specifically for the IFI controller since we couldn't do the kinds of things we can do with the cRIO. Unfortunately we had to look at the IFI controller like a black box, and use the USB DAQ device to programmatically inject "fake" sensor data to make the controller think its sensors and such were actually giving it live data, and then we used the Dashboard to peek at what was going on behind the scenes to see what the results were. With this mechanism the modeling environment was extremely specific, and you were limited as to what you could do (forget modeling the camera inputs!!).

Teams that use LabVIEW should be able to do all this within a LabVIEW environment on their laptops/computers without the need to do hardware-in-the-loop simulations. That way the electronics team isn't yelled at for stealing sensors and the controller. It would probably take an average team a day to a week to set up an environment to model for their specific robot, depending on how complex it is (and, of course, I've never tried modeling crab or meccanum (sp?) drives, so that might require some additional thought).

-Danny

Re: Programming with the 2009 controller
 

[Flame suit] That's what I call marketing. NI has been targeting engineering students for years with their academic programs. Get them hooked in college, so when they graduate they'll be more likely to specify NI products because they are most familiar with them, not necessarily because they are the best-suited products to fulfill their needs. The colleges don't object because they can pack their labs with newer equipment which helps their recruiting efforts. Now NI has decided that college isn't early enough - they are now targeting high-school students.

I've got nothing at all against the marketing business, however I think it's key to be able to recognized when you are being "marketed to". It's certainly not unique to NI. I can think of lots of companies that do this (going at least as far back as the Apple ][.[/Flame suit]

Personally, I'm trying to keep an open mind about this change. I'll reserve judgement (positive OR negative) until the dust settles after the 2009 season. I definitly don't think this is a no-brainer great move for FIRST though.

Re: Programming with the 2009 controller
 

DUH! Look at the Kit of Parts. Don't you see that as one big marketing bucket? You should. Autodesk, IFI, AndyMark, BaneBots, NI, the list is too long for me to list. You don't think they are providing parts out of the goodness of their heart, do you? You don't think FedEx donates shipping "just because" do you? It's the hope of ALL of the suppliers that you'll give them repeat business. That you'll recognize them as being leaders in innovation because they're donating (or providing at a significantly reduced price) to FIRST. Opening ceremonies are marketing blitz events. Closing ceremonies are marketing blitz events. Awards given out are marketing blitz events. FIRST SURVIVES on marketing revenue almost entirely. If you didn't already know that then hopefully you do now.

If anything you should THANK the suppliers and sponsors of FIRST for letting you have access to technology and goods at a price significantly lower than you could have on your own. That's where FIRST's main value is in my mind - you don't get the level of exposure at the same price point anywhere else.

-Danny

Re: Programming with the 2009 controller
 

I'm of the opinion that while the new control system will be significantly different than the IFI control system, that the FRC Modeling Toolkit could still be a useful learning tool for those of us that need skill sets using Labview. I believe that by using it, it will help bring some better understanding in how to use Labview by working with environment, motors, and sensors we are already familiar with. Since we "know" how those systems are supposed to work, we could use it as a learning/teaching tool. Does this make sense? Or would there be a better approach?

Re: Programming with the 2009 controller
 

Danny,

Do you know if "strategic” cRIO controllers could be given to certain mentors in areas of the USA?

For example, I would not mind volunteering to teach a class like this myself say at the Indiana Forums in Kokomo. I could think of several other people like Alan Anderson, Alex from 1024, Josh Hambright and even our own student programmer Nathan House. However, we would need to get our hands on it and learn it first before we could teach others in our own area.

Re: Programming with the 2009 controller
 

I'd definitely be interested, but remember I could only tele-mentor most of this comming build season (i'll be in college at UIUC). Thanks for the vote of confidence Chris. :]

I'm still planning on having a programming week this summer for the guys on our team who will be taking over for me. So far, we're still planning on doing it with the current PIC-based FRC controller, since the concepts still transfer, it's just the way you interact with the hardware that's changing (so far I'm still shooting to work with the Wind River C as opposed to the LabVIEW).

If anyone around our area is interested in attending the summer class (mostly on motion control) i'm having for my team, I think we could handle a few extra friendly faces. It's all tentative for right now.

But anyhow... we are working on getting a compact real-time backplane with the IO/expansion modules first is including... but one thing we aren't doing is paying full price. :eek:

And I thought $1195 was bad for the current control system... jeesh! :ahh:

At any rate, we're trying to get one too... hopefully somebody will have a breakthrough! :confused:

-q

Re: Programming with the 2009 controller
 

I hope that you can prog in C on Mac.. however, right from their site, Labview will support OSX and Linux:

http://decibel.ni.com/content/docs/DOC-1668

Re: Programming with the 2009 controller
 

To my limited knowledge in this area, this is not a current consideration. As soon as the system is ready, the current plan is to roll it out to all teams at the same time. FIRST is handling the distribution, so they would be the final word, not me nor anyone at National Instruments. If there is going to be any kind of "strategic preview release", it would come from FIRST directly.

-Danny

Re: Programming with the 2009 controller
 

No. I want the current FRC Modeling Toolkit to die, it has no practical use for learning how to program LabVIEW nor how to program for the new FRC environment. We also don't have the 3rd tutorial and its incredibly necessary information - it was never sent to me, only the byte stream location that I posted here on Chief Delphi, and WPI seems to have "lost" what they had (so please stop asking for it).

You can still download the toolkit, but I am not going to maintain it nor explain it nor support it any longer. I hope that concepts from that particular toolkit will be reflected in the final product, but it would require waaaaaay too much work to maintain. Jon Mittelman from 236 suggested that I/we modify it to replicate what's going on with the FPGA and such, but the work required would be similar to writing the production interface itself - I'd rather just leave it to our LabVIEW team working on this to create a final project, not have two completely divergent branches of code (I also have better things to do with my time, like actually teaching LabVIEW with the tools already provided to teams).

-Danny

Re: Programming with the 2009 controller
 

LabVIEW will run in Windows/Mac/Linux, but to deploy a real-time project to the cRIO will require Windows.


One thing to keep in mind is that you don't need the cRIO to learn LabVIEW. Students can start by writing the standard "Hello World!" program and work their way up to VIs performing useful tasks all on their PCs. You can write software emulators for sensor inputs or read in saved data if you want to build and test VIs related to robot control.

Re: Programming with the 2009 controller
 

Danny,

I'm sorry if I wasn't clear. What I had meant to propose is that the final Toolkit supplied to the Teams contain VI's which would enable the programmers to model their robot's behavior by running on the PC rather than the cRio. If this approach would involve duplicate work for the development team (modeling the FPGA itself), then could we use the program running on the cRio, monitoring the outputs on our custom 'Dashboard' and modeling the gear ratios and chosen motor characteristics?

In this way we could intelligently model the electrical system's load requirements under actual operating conditions, rather than watching for 'magic smoke'. http://www.chiefdelphi.com/forums/im...lies/smile.gif
:)

Re: Programming with the 2009 controller
 

Danny,

Firstly thank you for your insights and knowledge with regards to this new control system and Labview.

This is most likely the direction we'll take. Subject to change of course.
Or "How I spent my summer Vacation"!

I'm planning on obtaining a Lego Mindstorm kit(~$250) and the additional rechargeable battery(~$50). I've downloaded the Labview NXT toolkit, and will attempt to learn and teach Labview within our Team.

Once the WindRiver, VxWorks, WPILib environment is ready we'll begin work porting our "C" code to it. This may be a bigger challenge, since we don't use Easy C or WPILib today, so some our "high performance" modular routines may not fit as nicely as we'd like.

At least this way we'll have options and choices, and hopefully enough skills to be ready for the new season.

Re: Programming with the 2009 controller
 

Check out these links:

NI Labs - LabVIEW Ladder Diagram Editor
Welcome to NI LabVIEW Ladder Diagram Editor

According to this link: http://zone.ni.com/devzone/cda/tut/p/id/2856 the State Diagram Toolkit is supported on the cRIO

NI State Diagram Toolkit

-Brian

2009 Software Development platform
 

I found on the NI web site a poll for the program environment that teams will use for the 2009 controls. Place your vote on your chose for the 2009 development platform.


NI "Which software will you use to program your FIRST robot in 2009?"

http://decibel.ni.com/content/poll.jspa?poll=1008

Re: Programming with the 2009 controller
 

I would imagine modeling the behavior of the robot and using the corresponding information directly into the robot. I completely forgot that LabVIEW would have the necessary tools to do control system design which is kind of dumb on my part. It's also quasi intuitive if you are approaching this from the control systems/linear systems background.
PID Control
Actually, if I was making a thermostat controller I would defiantly use Matlab or LabVIEW. The usefulness of both those programs goes way beyond simple programming. And anything else you can bring up is going to probably have the same functionality.

Re: Programming with the 2009 controller
 

Except that MATLAB and Labview aren't really for embedded applications. They're far too resource intensive when you're designing something to perform a simple task for as cheaply as possible. If you're writing something embedded, you're almost definitely going to be using some variant of c/c++ or assembly. Probably using some kind of PIC, or, if you need a bit more juice, maybe an ARM processor.

With an ARM, you get a lot of bang for your buck, but don't try running something like LabView or Matlab on them.

I know that if I were designing a thermostat, and I told my boss I needed a single board linux machine to run it, that wouldn't fly.

Re: Programming with the 2009 controller
 

Programming a micro controller in C or assembler requires expertise and time for a project. People who can do this are an expensive asset. If you want to see a innovative solution to the development cost, look at Cypress semi and their PSOC micro controller. They wrote a development environment called PSOC express. Its a high level graphic design environment similar to Lab view. They have a high level state machine tool that allows a complex high level control design that takes out the low level complexity. You should really look at the coffee maker example to see how a graphical high level data flow tool can speed up the design process. The software and examples can be down loaded for free. In the future we will see more and more design tools that will allow us to concentrate on the behavior of a system at a high level and shield us from the costly low level stuff.

Re: Programming with the 2009 controller
 

NI has been pushing their LabVIEW tools into the embedded world for a few years now and they really seem to be gaining traction. There are already cRIO and sbRIO solutions and you can even get a variant of LabVIEW called LabVIEW Embedded with ports for ColdFire, Blackfin and ARM on your own custom PCB (including the Luminary Micro controller in the new Jaguar motor controller).

Such high-level tools (eg LabVIEW, Matlab/Real-Time Workshop, UML) will never compete with machine code, assembly or C/C++ (or other similar text-based languages) in terms of code efficiency. However, a good engineer knows when to use which tools. Sometimes you need to partition a design team and leverage their individual capabilities (eg use a combination of languages with high-level state machine "programming" and low-level drivers for code size/speed). Sometimes you need to get a product out the door as quickly as possible (often made easier using high-level tools) and are willing to pay a few extra $ for a microcontroller with a little extra oomph.

Russ

Re: Programming with the 2009 controller
 

It's true, and I think that that provides for some really interesting prototyping capabilities. One thing I haven't seen, though, is cost. Is LabView embedded royalty-free? If you're paying even a few $/processor that uses it, I can see how that would be a major detriment to the industry adopting it. I think there's a couple reasons why many people who develop microcontroller applications, would shy away from LV. If you're doing something more than just a simple task, it's really easy to become limited, by code size, core frequency, etc... and there's still the conception that things like LabView have a huge amount of overhead.

Also, maybe I've just hung out with old school developers, but none of them trust LabView, and I don't think they'd ever consider using it on a microcontroller. Don't get me wrong, LabView is great for a lot of applications, but I don't think their place is on a small embedded uC. Not yet, anyway.

As for the PSOC, it's a really interesting piece of hardware... Or rather, the development tools for it are interesting. There's some places where it could be really useful, but it doesn't seem like it's made the jump into industry yet. Back about a year ago, when I was starting my senior capstone project, guys from Cypress were pushing the PSOC pretty heavily. It seems like they're trying to target the college kids so that when they go out into industry they can say "hey, I know how to use this, and it would work in this application."

Re: Programming with the 2009 controller
 

The PSoC is a really interesting family of chips, and I would highly recommend checking them out to anyone who is interested in mixed signal. I really wish I had known about this during my sophemore year - I did a couple of labs that were "PIC + op-amps + filters + rats nest" that could have easily been "PSoC".

Re: Programming with the 2009 controller
 

The LabVIEW Embedded Module for ARM is royalty free. There is no deployment license for LabVIEW Embedded Module for ARM.

Its always interesting to hear about the amount of "overhead" LabVIEW incurs. One should keep in mind that when C was first developed many engineers stated the same thing regarding overhead. Luckily as compilers improved so did engineers opinion of C. Furthermore LabVIEW is extremely optimized compared to inline C for multi-threaded muti-core programming.

When the LabVIEW Embedded code is deployed to a (supported ;)) ARM processor it is converted into C++ code. While this is not as efficient as programming in C the difference may eventually be unnoticeable. Isn't that the whole point of innovation?

In regards to the 2009 controller there should little performance difference between LabVIEW and C/C++.

Re: Programming with the 2009 controller
 

Is it Functional C++ or Object C++? Sorry, first year mentor haven't seen previous year code so flying blind so to speak.

Re: Programming with the 2009 controller
 

has anyone succesfully controlled a robot using labview. if so could you please share some tips. also any help on instrument commands, and i stress anything(what they mean, how to make them), i would greatly appreciate it.

Re: Programming with the 2009 controller
 

Closest thing you'll get is the Guide that one of the team members of Team 1817 has done about programming a National Instruments Compact Rio (NOT THE FRC VERSION).

http://www.team1817.org/cRio_report.html

If the code there intimidates you, be assured that programming the 2009 NI CRio FRC will be much more easier. From what I understand right now, there will be many demo VIs (programs in LabView) that will explain how to program in LV and program a robot in LV, and hopfully, teams will recieve/download a default code(or VI) for LabView which with it teams can control a robot like you would with the Default Code for MPLab in previous years, just that you will have much more options of changing values easly in order to:

- Chose the method of driving the motors (1 joystick, 2 joysticks, omni....)
- Defining input/output for analog and digital components
- and probablly much more!
and all that without having to create too much of your own code.

So I think the best thing for teams (same goes for teams that are looking forward to use only C/C++) to do now is to understand how to use LV to program a robot (know how to use shortcuts, values, loops, statments etc...) so once you receive the robot controller and Labview (hopfully) with the Default Code, you'll be able to change the code to fit your robot easly.

Re: Programming with the 2009 controller
 

so let me geth this right. keep in mind that this is my first year in the usfirst competition. they will give us default vi to modify?

Re: Programming with the 2009 controller
 

Yes. There will be examples and default code in both C/C++ and LabVIEW.

Greg McKaskle

Re: Programming with the 2009 controller
 

Actually, when I wrote MATLAB I meant Simulink. I forgot they were not the same program. And when I wrote that I had no idea Simulink can produce pure C code. Also, I was vague when I wrote that. I agree 100% with what you said but you typically do not want to start programming the device you are trying to control because you stand a good chance of catestrophic destruction if you make a mistake. I'll admit a temperature controller is a bad example of this.

Re: Programming with the 2009 controller
 

My experience is with real time OS's, PLC's, robot steppers/servos and going to Labview seminars tells me this:

It will be much easier for the average team to use Labview. It's graphical based and easier to learn and make small changes to default code. C++ is for those teams with extensive programming depth. Wind River is a professional IDE for real time control and will be a steeper learning curve.

The trick to Labview programming is to think about signal flows. The origins of Labview was remote control of professional instruments like scopes and signal generators. It grew into Labview being the instrument. If you grab an analog electronic design person they will find Labview intuitive, as each block is like adding another op amp circuit, integrator, comparators, etc.

Where Labview will excel is feedback control, like encoders controlling motors and speeds. I assume there will be stepper motors in this year kit, in addition to the DC motors. It has PID blocks. Analog signal processing, such as controlled ramp up and ramp down will be a snap. Dick Morley the inventor of the PLC is a big advocate of "stateless" PLC programming. Control programming at it's simplest requires an output fires/ramps/runs based on a input conditions button/sensors/alarms/limits. To try to make a state program in Labview (procedural steps) is against the natural flow of it.

Re: Programming with the 2009 controller
 

Making procedural steps may be against the flow of labview, but that's exactly what many folks will need to do to program autonomous.

To program teleop, you don't need it - but I would guess that 90%+ of the good auton's out there use a state machine or a sequence of some sort. Go to location 1, check situation, go to location 2, and so on.

Conceptually, perhaps one of the NI reps can answer this question. Hopefully it isn't in the NDA since it's pretty general. Will we have a general "loop" setup like the current controller where specific loops are run at a specific and documented rate, or will we have to use timers of our own to control the update rates of variables that need calculation (like distance error, etc).

Re: Programming with the 2009 controller
 

While LV expressions are based on dataflow, it is not a pure dataflow language, and since many real-world problems require state, LV has numerous mechanisms for maintaining state. Of course the parallel nature of LV means that it is important that you access the state safely.

As for loop timing, there is not a hardcoded schedule that everything else is bound to. In our prototype bots, we've often built loops that run in parallel at rates that match their task -- comms and joystick at 25Hz, servos at 50, motor updates at 100, camera at 10, etc. LV and C/C++ have different ways of doing this, but you have the flexibility of different rates.

You can of course put tasks in the same loop and try to run them at the higher speed, but you now have other choices.

The communication between the loops is usually a small set of variables, notifiers, queues, or other mechanisms for data transfer. It may be useful to think of them like registers between PICs if you want.

To calculate distance or otherwise factor in time, you will have access to high resolution clocks, which should give better results than assuming loop rates never wander.

Greg McKaskle

Re: Programming with the 2009 controller
 

That's great information.

People can now starting thinking about the structure of their program.

Each sensor is going to be polled at a rate specific to that sensor. So we'lll define that rate and compare it to a timer. That's not something my team ever worried about in the past - we simply polled all the sensors at the slow loop rate since we never had issues with it. This will lead me to a nice discussion about update rates of each component that we use. We can also write a very short VI that calculates the next timer value for an "update" for each component as a starting point for the kids to learn.

Ok - next question. If we place the polling blocks in "parallel" (I assume that simply means next to each other rather than in a series string) can the hardware actually poll the sensors in parallel, or will it be qued up and poll each piece of hardware in series?

Re: Programming with the 2009 controller
 

The LabvVIEW installation disks that come with the competition kit will already know how to build a FRC-cRIO project. So instead of saying "New Vi" you will say "New FRC cRIO project"

That project will build and deploy to the robot and work just like the "Default programs" of past years.

This base project can then be modified to your hearts content to build custom robot capabilities. There is also a large set of "custom" vi's created to support typical FRC components. The best thing is that you can drill down into these and see how they were built, and learn LabVIEW skills the same we learn most programming.

Note: the cRIO will probably be loaded with this program out of the box, so once wired up it should run without any software changes (just like past years)

Go to this forum to ask question of the teams currently beta testing the new hardware/software.

http://forums.usfirst.org/forumdisplay.php?f=743

There is not much there yet because people aren't asking questions (like yours).

Re: Programming with the 2009 controller
 

I found that this basic primer was helpfull. It demostrates some of the basic program structures that are available... including typical loops, case structures, State machines and timing elements.

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

Just watching each video game me a starting place for thought.

Re: Programming with the 2009 controller
 

Yes, next to each other. You can have common inputs going into the loops, common outputs coming from the loops, but if one loop feeds the other through a dataflow wire, the downstream loop cannot begin until the upstream loop completes and hands over the data.

The parallel loops are internally scheduled using a pool of threads, typically 4 per processor in the system. This means that if a loop calls into some code the suspends the thread waiting for an operation to complete, a parallel loop can be scheduled on a parallel thread to fill the void. Or, most of the I/O in LV is built using nonblocking APIs, and that means that even the original thread is available to do work while the first loop's task is in progress. A good example of this is network communications. Doing a read with a timeout of 100ms means dependent nodes will wait for the results of the read. It doesn't mean that parallel code can't borrow the thread and make progress while the TCP stack does its job.

And of course on truly multicore machines, the loops really can run in parallel, even the contents of the loop can be run in parallel to the extent that dataflow allows.

Greg McKaskle

Re: Dumb question - Java?
 

I teach a programming class that prepares students for the AP Test, which is all Java. Many of the students are interested in doing the robotics team. Ideally, I'd like to have the class work on programming the FRC controller in Java instead of having them learn a different language that won't help their AP Test preparation. Has anyone been able to program the new controller using Java? Any thoughts on how well it would work and how to go about it?

Re: Dumb question - Java?
 

The cRIO does not currently support a Java environment, and I know of no plans to port Java to it. To paraphrase Greg, the most important language a programmer will learn is their second one - I couldn't agree more.

Teaching them C++ or LabVIEW would probably be more effective for their AP Java than you would think.

That being said, I don't think any one would stop you if you did port Java to the cRIO.

Re: Dumb question - Java?
 

Perhaps the one advantage to using Java in this situation is that it might make it easier to create an emulator for your robot. However, being interpreted, it would be considerably slower. C++ really is similar enough to Java that they should be able to read and understand it right off. Labview, while there isn't the excess of (free) resources to help you with it, is quite useful in that you don't have to look through a manual to learn it, and it handles a lot of datatype conversions automatically.
Sure, go ahead and use Java, but consider giving them the option of using another language as well.

The other option, of course, is just interpreting it when you compile. This could introduce some translation issues, but I doubt there'd be many, considering the similarities. For porting Java to the cRIO, you could start with a Linux OS, and then make it open up Konqueror and run everything as applets. The advantage of Java is that it can be used on any system. The advantage of programming for FRC is you know exactly the specifications of the computer you're dealing with, and you don't have to deal with any other systems.

Anyways, it's your choice if you want to put the work into it. Considering these are normally used for industrial applications, I'm pretty sure you'd be the first to do it.

Re: Programming with the 2009 controller
 

cRIO-FRC Training Video: Joystick Motor Control in 10 minutes

I'll let one you guys create a new thread for this video if it seems warranted.

This is the first installment of cRIO-FRC training being produced by National Instruments. Expect more videos like this as well as text companion material in the next couple of weeks.

FIRST Robotics Competition: Joystick Motor Control in 10 Minutes

Please post feedback! We want to make our training material the best possible.


Cheers,
Mark
NI FIRST Support

Re: Programming with the 2009 controller
 

Just a quick question, what value is considered full speed? (255? 1.0?)

Re: Programming with the 2009 controller
 

The Set Speed input's range is -1.0 to 1.0. So full speed (+) would be 1.0.

Re: Programming with the 2009 controller
 

Is there a compiler or library that will allow this supposed "C++ support"? Because I really don't want to have to relearn a new IDE, and run the risk of breaking/losing the computer with the singular licensed IDE copy (which we did last year). I want something command-line based, that will let me use something like Code::Blocks or Dev-C++, if properly configured. Is there something like this out there?

Re: Programming with the 2009 controller
 

Windriver Ecplipse for C++, I think?:confused:

Re: Programming with the 2009 controller
 

The IDE is Wind River Workbench, which is based on Eclipse (3.3, I believe). The toolchain is a VxWorks-specific derivative of GCC.

Re: Programming with the 2009 controller
 

Does anyone know how many seats will be in the KOP and what tools will be included in the toolchain?

How many seats for LabView?

What did the beta teams receive for each?

Re: Programming with the 2009 controller
 

The beta test teams were not given any restrictions on the number of workstations on which they could install either LabVIEW or Wind River.

Re: Programming with the 2009 controller
 

Teams will get a 25 seat license but it will most likely not be policed because we know so many teams are much larger. The license will expire January 2010 (just in time for the next season!)

Re: Programming with the 2009 controller
 

That's pretty awesome, actually. 25 seats should be adequate for the vast majority of teams, really. The single seat license we got for MPLAB and EasyC definitely hampered teams, thought accruing multiple licenses over the years did tend to help somewhat. 25 seats is going to be sheer luxury.

Re: Programming with the 2009 controller
 

25 seats, really? I'm not complaining, but I don't think we have that many kids on our team, let alone programmers! :) It'll be really nice though, compared to the one seat we got for EasyC.

Re: Programming with the 2009 controller
 

Yeah, 25 seats will be nice(even though there isn't that many total people on my team but still, It allows for room to grow). What I'm looking forward to is the possiblity to use OO in our programs(Read: Better AI).

Re: Programming with the 2009 controller
 

No, technically, it's not truly object-oriented, because it does not include polymorphism, inheritance, virtual function call stacks, and other requirements of true OO languages. However, I'm not saying it's not IMPOSSIBLE to accomplish these with the C language alone, but it's just MUCH more complicated, and if C++ has these things built in, why not just say C/C++ together is an OO language?

(I DONT LIKE STDMETHOD POINTERS AND HAVING TO WRITE VTABLES!)

Re: Programming with the 2009 controller
 

One thing to say...

Wind River = Win Driver?