For the 2007 & 2008 seasons, FIRST provided copies of Labview with the
Kit of parts. Can these older versions be used to program the oldered MircoChip RC units? I never knew why these were included…
Is there any sample code for the cRIO platform that we might be able to play around with to get familiar with the cRIO platform?
How might our team get better acquainted with the cRIO platform and Labview during the offseason?
Thanks in advance for any helpful suggestions.
I believe they were included for use as an engineering tool along with the NI 6009 DAQ unit. They could be used to validate, test, or measure other elements of the kit. That LV didn’t have a compiler for the controller.
The other use was for building a dashboard display.
You can find sample code for LV all over the place, but it isn’t specific to FIRST, and usually isn’t specific to cRIO. LV is a pretty portable language, so the code written for one application will migrate to another platform provided platform specific resources aren’t being used.
Some teams are using the NXT and the LabVIEW toolkit to get a flavor. Using the previous year’s LV kit with the 6009 will also give some familiarity.
Greg McKaskle
That “portable” nature is fine in theory, but it doesn’t seem very useful in practice. From my point of view, an FRC robot is all “platform specific resources”. For example, at this time, I have no access to sample LabView code that knows anything about the FPGA we’ll be using to monitor many sensors and to control basically everything on the 'bot.
Thanks for the info about the Labview and its use for the 2008 and prior year’s hardware…
Is there any code written for the new controller (2009) available out there for teams to practice with and start the learning curve?
Alan is quite correct here (Oh,and Happy birthday Alan). Imbedded programming (which FRC programming is) is very hardware and processor specific and generic programming will only get you so far.
That said, Practicing using LV will give you the understanding of how to wire LV programs and will get you used to the interface … just expect to have a few things that you’ll need to modify once you start programming for the FRC specific hardware.
I am certain there is.
However, the few teams with access to it have apparently been asked to keep it secret until FIRST decides that it’s time to share with the rest of the teams. The only valid advice at this time would seem to be this: be patient. Keep reading the Chief Delphi forums and you’ll find out more at the same time everyone else does.
Hopefully I can give everyone some ideas on LabVIEW, the FRC-cRIO, and what training will be available.
LabVIEW is not a language. LabVIEW is a programming environment that is designed to be portable and cross platform. Furthermore LabVIEW can target and compile code for a variety of embedded targets with no code changes. LabVIEW FRC edition is special since it comes with special FRC specific palettes and VIs. It is also set up so it can target an FRC cRIO right out of the box.
Since there has been some concerns about the difficulty of installing LabVIEW and all of its components I will address this here as well. Installing LabVIEW for FRC is extremely easy. Everything is on one DVD and is packaged in single installer. This includes all drivers, and LabVIEW modules, and toolkits required for FRC.
Where can I find examples to get started
Currently, there is no code released for the FRC-cRIO. The FIRST support team at NI is working to develop as many examples as possible. We are also depending on our Beta teams for example writing and feedback.
So how to get started without code?
All of the different functions of the robot are implemented in several APIs. Some examples are Robot Drive, PWM, Gyro, Encoders, etc. They are all very easy to use and follow the same Open » Set/Get » Close programming paradigm with few exceptions. This is exactly how most other API in LabVIEW operate including TCP networking and file I/O. Simply put if you understand dataflow and how to use one API, you know them all. With this in mind the real power of LabVIEW (and any IDE) will be demonstrated by how teams solve engineering problems beyond the solutions that are included in any single shipped API.
http://www.chiefdelphi.com/forums/attachment.php?attachmentid=6805&stc=1&d=1220896708
As for getting started with LabVIEW there are tons of resources on ni.com, but some have been developed specifically for FIRST and can be found here:
Getting Started with NI LabVIEW Training
These tutorials do not cover any of the FRC specific APIs, but will get your up to speed on “how” you program in LabVIEW. We are developing FRC toolkit tutorials that follow this same format and they will be released before the build period. You can expect the first of these to go live by the end of the month.
**
Addressing platform specific questions. **
The cRIO is a much more flexible platform that most other embedded controllers including last years controller. This reason for this is the FPGA gives us the ability to create custom hardware in software rather than have the hardware described on a “hard wired” silicon chip or PCB.
But we don’t have access to the FPGA so why should we care?
Like it, hate it, or don’t understand it, the FPGA not being exposed to teams is a good thing. Learning FPGA from scratch and implementing it in 6 weeks would be beyond the scope of most teams and beyond NIs resources to train and support teams. Our engineers have put in an immense amount of work so teams can focus on higher level problems.
So why use a cRIO if its “flexibility” isn’t useful for team?
The fact that we can change the hardware in software is huge for FIRST. For example it allows us to roll out bug fixes without making any significant changes to the controller hardware. Looking ahead to future seasons, the FPGA will allows FIRST to use more and different sensors, motors, etc than would be possible with totally fixed hardware.
My Questions for you!
As I stated before the NI FRC Support team is writing examples as we speak, but we are looking for ideas for some specific examples teams expect. ** What would some of these examples be?** Don’t be afraid to post suggestions because they will likely get created 
DVD? That’s an unexpected surprise, and it’s going to be a major issue for some of us. I hope there’s another relatively easy option for installing LabVIEW for FRC on our team’s non-DVD-capable programming laptop.
They warned us a year and a half ago: http://www.chiefdelphi.com/forums/showthread.php?t=59402
31 respondants to the DVD poll? I certainly hope that wasn’t the sole information source they drew from in determining the DVD. Not a single computer here in the Ford Plant will play a DVD.
I suppose we can always bring a computer from home, share the dvd drive, and install across a network.
I was wondering why I missed that poll, and then I noticed that it was somewhat buried. Only people paying attention to the LabView subforum would have seen it. The poll got a mere 30 responses. It strikes me as akin to polling the people rowing boats across a river about whether they owned a car with sufficient power to negotiate a steep approach to a proposed bridge.
I don’t think it quite counts as having “warned us”, and I still feel somewhat blindsided. Thinking about it for a little longer, though, I don’t think the purchase of a portable DVD drive will break the team budget, so it isn’t really the “major issue” I called it at first.
While most everything works better in theory than in practice, I do think it is a good idea to have some abstractions that allow the platform to be more modular.
If you use a DAQ card to read a sensor such as an accelerometer or gyro. You write PC code in C or LV to do the conditioning and accumulation to give you position, velocity, or acceleration whatever it is you need. You make a function or VI that returns the value of the sensor. Now if you switch to an I2C sensor, you can use the same interface and isolate the users of the sensor from the implementation.
I’m not going to pretend that you can accurately model or simulate the entire environment on a PC, but in a number of cases, maybe vision comes to mind, the PC is an excellent proving ground for testing out processing approaches.
From what I’ve seen in my limited experience, I think that the code can be modularized this way for FRC, and I think that is what the WPI code is shooting for – not a singular slab of code, but modules with more obvious boundaries.
Greg McKaskle
I’m not worried about modularity one way or the other. Modular design is a fine thing when you’re building a system that might have a number of different options. However, its relevance to a one-of-a-kind FRC robot with a predefined control system is unclear to me.
I’m not going to pretend that you can accurately model or simulate the entire environment on a PC, but in a number of cases, maybe vision comes to mind, the PC is an excellent proving ground for testing out processing approaches.
Forgive me for being blunt, Greg, but do you have any experience with programming FRC robots? “Testing out processing approaches” seems rather an odd priority when the task involves something as straightforward as reading joysticks and driving motors.
Or maybe seemingly things like speedometers and PID control processing are going to end up being significant issues on the cRIO, and I’m going to find myself spending a lot of time with the team’s software group working on “processing approaches” and trying to work around the pitfalls when the LabView for FRC package and FRC toolkit tutorials are released.
It’s possible that I’m missing something fundamental about what you’re describing. It’s certain that I don’t understand what “BLAQmx” meant when he said LabView isn’t a programming language, especially after he then pointed to examples and described them as “programming in LabView”. So the problem I’m having might be due to something as trivial as a simple mismatch in terminology, in which case my whole fogginess can evaporate as soon as I get that straightened out. Or it might be due to something much more profound, in which case I would expect to eventually reach a higher state of enlightenment. One would hope that the likelihood of the alternative (that I never do understand what you’re talking about) is vanishingly small.
No need to ask for forgiveness, blunt is fine. An important part of Klingon culture, isn’t it.
I graduated before FRC existed, and have not been a mentor, not yet anyway. My involvement with building robots has been on the demo units to demonstrate how the cRIO, I/O modules, and 802.11 can be used to build a robot. Over the past year, that adds up to three robots. I was primarily involved in the SW end. As is typical, that means that a week or two before show time, the HW is starting to get stable and you learn that plenty of design assumptions are out the window. The SW must adapt to the actual HW and sensor conditions, and modular design is one of the best tools to adapting to changing circumstances, IMO. By the way, I’m in no way trying to take credit for single-handedly building three robots, this would definitely not have happened without a seasoned FRC mentor, Joe Hershberger, and a number of other enthusiastic engineers.
For tinkering, if you only intend to read joysticks and control motors, Brad has already designed nice modules. If you want to take input from other sensors, and tune the system, I think it is nice to keep things modular, and avoid having P set in the vision section, I set in the joystick section, and D set – hopefully – somewhere before it is used – “doesn’t the gyro affect D”? Plus, anything we produce should be modular, even if the implementation in the FRC bots isn’t.
I don’t think that you will spend lots of time making speedometers and PID work. More complex sensors, vision in particular, do require new engineering. There is no PID hammer that handles all vision issues. Doing it only when you have access to the robot limits the time to evaluate alternate processing schemes. Thus my belief that PC and portable code development are good things, even in FRC. Also, don’t assume that the predefined control system is closed and limited. We think it is highly modifiable, even if the FPGA is currently closed.
As for terminology. I apologize for the acronym soup that NI spews. Every industry does it, and we absorb a little from each of those industries. To make matters worse, LabVIEW has multiple meanings. Technically, LabVIEW is a product name, and another name was invented for the langauge – G. In reality, few people use that name, and the comp.lang newsgroup is comp.lang.labview, not comp.lang.G. So don’t let that confuse you.
I think I understand your concerns with the new system. You have indeed been kept in the dark. This isn’t Brads decision, and it isn’t mine either. I’m not really a fan of tadah moments. I’ll be much more comfortable when people have access to the entire system and we can respond to demonstrated deficiencies in the system rather than FUD caused by an information vacuum.
Greg McKaskle
To add on to that a bit, joysticks and other potentiometer-based game controllers are definitely not the only way to control a robot. The most obvious way to control a robot would actually be to not control it at all; make it fully autonomous. For that there is definitely benefit in testing beforehand (this testing is actually quite possible, considering that the drive system on the robot changes little). However, there’s also several forms of semi-autonomous control. One of them would be simply running an autonomous program and interrupting it as necessary. What I’m working on is a picture-based setup where you have a map of the field and all obstacles the robot can see, and you assign it a route or tell it to manipulate something on the field. If you’re interested, I have the very beginnings at http://sotabot.com/robot/programming.html The file is called “robot tracker”, but I use some of the other VIs in it, and you might have to download them as well.
Good luck, and keep asking questions; you’re clearing things up for us too.