View Single Post
  #41   Spotlight this post!  
Unread 24-04-2008, 10:22
esquared's Avatar
esquared esquared is offline
Keeps saying 3-2-1-Rush...
AKA: Angry Eric
no team (Volunteer!)
Team Role: Mascot
 
Join Date: Jan 2006
Rookie Year: 2005
Location: Boston, MA
Posts: 192
esquared has a reputation beyond reputeesquared has a reputation beyond reputeesquared has a reputation beyond reputeesquared has a reputation beyond reputeesquared has a reputation beyond reputeesquared has a reputation beyond reputeesquared has a reputation beyond reputeesquared has a reputation beyond reputeesquared has a reputation beyond reputeesquared has a reputation beyond reputeesquared has a reputation beyond repute
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