View Single Post
  #10   Spotlight this post!  
Unread 08-09-2008, 20:14
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,751
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: A few Labview questions

Quote:
Originally Posted by Alan Anderson View Post
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.
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
Reply With Quote