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.