Outputting Data Onto Computer Screen

[Tanner]

Well if I am understanding ye right, you want to have a non-LabVIEW dashboard to display something (i.e. a computer generated image) on the Classmate?

As far as I know that wouldn't be legal for competition use with this year's rules, though you can certainly pipe out the dashboard data to another computer (via remote dashboard) and read the values coming in via whatever method of programming language you like (Processing sounds like fun). I haven't tried it, but it might work.

-Tanner

[Joe Ross]

Originally Posted by Tanner

Well if I am understanding ye right, you want to have a non-LabVIEW dashboard to display something (i.e. a computer generated image) on the Classmate?

As far as I know that wouldn't be legal for competition use with this year's rules, though you can certainly pipe out the dashboard data to another computer (via remote dashboard) and read the values coming in via whatever method of programming language you like (Processing sounds like fun). I haven't tried it, but it might work.

-Tanner

It's specifically allowed by <R60>.

[Tanner]

Originally Posted by Joe Ross

It's specifically allowed by <R60>.

Then all sounds good then for something like this.

-Tanner

[davidthefat]

I CAN put an arry of LEDs on the robot to light up each led according to the sensor input... That would be pretty cool

[Andrew Schreiber]

Originally Posted by davidthefat

I CAN put an arry of LEDs on the robot to light up each led according to the sensor input... That would be pretty cool

Yup, if you are in Atlanta check out 33, they do just this. They have 3 colors of light bars on their bot to serve as visual feedback.

EDIT: 2337 uses the vibration of the xbox controller to provide feedback to their driver, just another way of doing it.

[Tom Bottiglieri]

Any data visualization should be done off-board the target (cRIO). The robot doesn't care what you see on the screen, so why should it do any extra work to put it there? You just need to set up your robot to pipe the required data to an external viewer.

The dashboard classes built into WPILib are probably the easiest way to pull data off of the robot. The Labview example dashboard is probably the easiest way to view this data. You don't need to worry about any of the transport methods, and can just concentrate on doing things that matter. We used a custom Labview dashboard quite frequently to plot sensor inputs/motor outputs over time to help tune our control loops.

If you really are opposed to using free functionality, you can set up your own socket connection to the target and pump the data through manually. Or run a http server on the robot and fetch selective data with http requests and return JSON/XML. Or whatever you want, really.

Edit: I forgot about this. Seems pretty cool. http://code.google.com/p/webdma/

[Greg McKaskle]

As has already been said, you can run notepad as your dashboard if you like. The key is that it listens on the DB port and pulls the data from the data streams. Also said, you don't need to build bitmaps or renderings on the cRIO. Sure, you can do it if you try hard enough, but the fact that the cRIO doesn't have a video card might be a clue that it was designed for something else.

If you are interested in doing OpenGL programming, you can find many frameworks and toolkits to assist you in the language you choose, and yes, the scene graph, sometimes called the 3D Picture Control, will do 3D in LV.

Honestly, I don't think you need OpenGL. LV has a display called the intensity graph which maps a 2D numeric field into color-coded display. It doesn't do contours and fancier stuff, but it does fast display, typically of spectrograms, but other times data from 2D microphone arrays, radio telescopes, etc.

Greg McKaskle

[byteit101]

You can also get data with the ZomB Dashboard System. (http://firstforge.wpi.edu/sf/sfmain/....zombdashboard)
It has all kinds of ways to display data: graphs, on/off, 3-ways, analog value displays, tacos, etc...
you can even create your own dashboard, just drag and drop (and a few other small steps) I will be writing some more documentation soon...

[apalrd]

Generally, a graph of data vs time is quite enough. For example, I have all of my root classes setup to graph the analog input(s), setpoint(s), motor output(s), and other feedback data on a graph almost full screen. This dosen't run when I do a full build, just when I run Robot Main (works quite well). Actually, this was very useful when we broke our analog module or card (we replaced both). We saw that the arm was moving spontaneously (sorta flickering), and a probe on the voltage (in software) returned somewhere between 2.9 and 3.0 volts, but a look at the graph showed it was oscilating between 2.8 and 3.2 volts (not good). I then wrote a VI to tell me the voltage of all of the used analog channels, and about 10 minutes later (1/3 of that downloading), I had a graph of all the analog channels. Graphs and probes of variables are very easy to do in LabVIEW. Really Really easy.

As for WebDMA, the cRio is capable of hosting a webserver that has dynamic VI front panels (they can be static, static auto-reloading, or full interact-able front panels). I looked at this as a means of quickly getting more feedback data then I could fit on the dashboard, but eventually settled on a tabbed dashboard plus an interface to use when running Robot Main, because of CPU load reasons. Its just another feature LabVIEW provides to make things easier.

Still think C++ has more potential than LabVIEW? As for potential, in the long run, yes, but it will take you alot longer to get the same result. And in FIRST, we have negative time budgeted for everything, so you don't have that time.

As to the lights that Andrew mentioned, they are 12" automotive light strips, 6 total in 3 colors, off 2 Spike relays for indication of various HUD-type messages (ball in, high gear, etc). If anyone remembers the vision targets from 2006 and 2007, the green ones are from those (the red and blue ones are identical to the green ones, except in color). They have two purposes: tell the driver when he has a ball and if he is in high gear, and tell the coach if he should be yelling at the driver to shift up or down. The lights are visible from the webcasts, I hear. We also flash the lights in a sequence when we hang from the pole, a feature requested by Jim Zondag himself (this is how little we have to do to the robot between competitions, when a purely decorative software change is requested by the lead mentor)