Dashboard

[Kevin Karan]

Heres a screenshot of our dashboard for this year. It has speeds for the encoders and the general position of the robot as seen by the IrSensors

[deltacoder1020]

looks pretty good

[jacob_dilles]

awsome lookin. is that the demo dashboard or the full version?
edit: i went to if site. there is no full verion dashboard. how did you get it to look all cool like that?? did you write it in VB or is there a button im missing? i wana be cool like you!

[Ryan M.]

I wish I had time to do stuff like that. :cry: Very nice. Did your robot actually have a map and store its position on it? We had thought about doing that this year, but decided it would take to long and instead would do it over the summer and use it next year.

[Kevin Karan]

I coded it in VB. The robot stores its position as a double, then I convert it into a char (255x255 resolution) and send it via 2 user bytes. The speed is sent via 4 user bytes and 2 limit variables (not used otherwise by us). Designing the dash actualy took the longest, the parsing code was pretty easy.

[Nick Fury]

I'm not meaning to be a thorn in the side but I have a question for you. You posted a screen shot of the program but you did not post any code for the program. Why? I mean, you did a great job coding it, why not share it? I would like to look at the code for a dashboard to see how it works. I think it would be really cool. Yeah, I'm one of those crazy open source hippies. I can't force you to share the code but I wish you would considering FIRST robotics is an educational expierience and education has typically been a place for open source. Again, I'm not meaning to be a thorn in your side and if you don't agree with me then just take what I said and ignore it.

[Ian W.]

That's pretty cool looking.

One thing I might suggest? Last year, me and my friend (SuperDan) created a dashboard "suite" of programs last year. It used a C++ backend to read/parse data, and a Flash MX frontend to display data.

This allowed us to make a pretty crazy frontend, and Dan actually made a small model of the robot, which made it very easy to see what was going on without reading.

Keep in mind, you don't want to be reading absolute values so much as seeing relative values. It's nice to know you're going exactly 10 ft/sec, but I find it more useful to see a bar that gets higher the close I get to full speed. Or see an arm that moves on the computer screen as the arm on our robot moves instead of a "LED" lighting up.

I like the way you did your output, it's very simple and it's following IFI's dashboard so people should be somewhat familiar with it. But I think that depending on how you interpret data, it can be much improved upon. Just remember, you only have 2 minutes to play, most of the time you'll be looking at the field, not a laptop, so you want those few seconds spent looking at the laptop to give you as much data as possible, sometimes numbers take too long to read.

[KevinB]

Originally Posted by Nick Fury

Why? I mean, you did a great job coding it, why not share it?

The reason he probably didn't share the dashboard code is because it depends on his specific ROBOT to work properly. Unless your robot has identical shaft encoders connected the same way to the same motors and the same wheels all running the same robot code, the positioning data won't work for your robot.

[jacob_dilles]

Originally Posted by Ian W.

Last year, me and my friend (SuperDan) created a dashboard "suite" of programs last year. It used a C++ backend to read/parse data, and a Flash MX frontend to display data.

that sounds awsome! how did you intergrate flash with C++? ill bet it looked great. you mind sharing some tips, our driver wants a laptop this year and i was about to write a termanal app that had 2 bar graphs based on printf()... kinda pathetic in comparison

[KevinB]

One way to do it would be to have the C++ App write to a file and have the Flash App read the file.

[jacob_dilles]

yeah but thats kinda skech... think refresh rate at least 15 times a second. i would think VB would be best here, but c++ is a lot more direct in accessing ports.

[10intheCrunch]

Can you explain a little about how you keep an accurate position of your robot during a match? Is it based on speed and direction, and if so how do you account for slipping wheels or other irregularities?

We thought about designing a positioning system briefly at 254 but decided against it for the complexity and predicted inaccuracy (with proximity sensors on gear teeth and possibe optical encoders on the motors).

What it boils down to: can you keep an accurate position even when bumping into things, dueling with other bots, or climbing the stairs, where your wheels will be slipping?

Thanks,
~Alex Baxter
Programming, Team 254

[jacob_dilles]

theoreticly you can accuretly track postion with an acceleromitor and a compas. everything else just adds accurcy.

[Kevin Karan]

We get a position, though not all that accurate, within a few feet, with a combination of ir sensors and encoders.
And Nick, I was going to finish cleaning up the code and make a white paper with an example since noone else had.
EDIT: let me explain this alitle better, The way we get position is to use the encoders for distance and the sensors for direction. The encoders do a horrible job figureing out where the robot is pointing, but their good for getting distance. The encoders are great for getting what direction the robot is pointing, but horrible at getting distance. They also try to detect when the other is not working. For instance, if the encoders show the robot is moving, but the trackers show that its stopped, the robot will first deturmine if there is somthing wrong with the trackers by giving up its current lock and relocking it on the beacon, if its the same, it can assume the encoders are the problem, and will ignore them untill the trackers show the robot has moved.

[jacob_dilles]

how bout some VB example code. please?
ooor flash & c++. PRETTY PLEASE?
lol white paper would be most exclent.