Programming with the 2009 controller

[dbarr4011]

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

[Adam Y.]

Originally Posted by Guy Davidson

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.

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

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.

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.

[steveg]

Originally Posted by Adam Y.

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.

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.

[Gdeaver]

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.

[Russ Beavis]

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

[steveg]

Originally Posted by Russ Beavis

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

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

[EricVanWyk]

Originally Posted by steveg

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

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

[BLAQmx]

Originally Posted by steveg

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.

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

[Dbruce1792]

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

[pollyproof12]

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.

[Bomberofdoom]

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.

[pollyproof12]

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?

[Greg McKaskle]

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

Greg McKaskle

[Adam Y.]

Originally Posted by steveg

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.

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.

[rjmah]

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.