Dashboard Fun

Ok, so I dug up my Dashboard program from last year, and I’ve been working on updating it to work with this year’s OI. I ran into a small problem though.

The analog inputs on the robot have 10 bit registers, as far as I can tell. We can only output bytes, 8 bits, back to the robot. The easiest way is to just chop off the two lowest bits, which may help to reduce the noise on the current sensors, but might hinder other applications. The only other idea I could think of was to use two bytes, and match it all back up once the computer receives the data.

Can anyone else building a dashboard program offer any input on how they’re working around this rather annoying problem?

Lastly, anyone who wants a simple C++ console dashboard program, let me know and when I’m done I’ll put it in the white papers. We use this as a backend, mostly because I never learned C++ GUIs, and we found a way to make much cooler GUIs anyways ;). Give me a few days though, as I think my priority this week is getting my Eagle stuff into council…

I’d like to see the C++ backend. Thanks for offering. :slight_smile:

Hi Ian,

You can also send the analog value as a delta change from the last value sent which will generally be a smaller number. Implementation assumes the analog value starts at 0 or your dashboard waits a couple of transmission cycles for the delta to add up the first time.

Are you close to your 18th birthday?


If you’re going to build a better Dashboard, how about putting in some kind of analog display for analog values? I was pretty surprised to see numerical-only display in IFI’s Dashboard. Even a simple bar graph would be a huge improvement:

127: XXXX----
64: XX------

I would be your best friend forever, or at least for the next month. :smiley:

Can you explain how you accessed the serial port? I would appreciate it very much.

Well, I hate to burst any bubbles, but that parts mostly for the Flash MX frontend.

The way me and Dan (SuperDan) set this up was on a coach bus going to Annapolis last year, so it’s quirky ;-). Basically, my backend is C++, and it accesses the serial port (which Flash MX cannot do), and writes it out to a file. It loops until forever, constantly updating said file.

Flash MX runs, constantly reading said file, for infinity. This Flash MX program is the nice, pretty, amazing GUI part, but unfortunately, it’s going to be completely tailored to our robot. So we’ll probably offer it out to the masses if we can make it decent, but it won’t do you guys much good.

However, you can take the backend (once I get it working) and create your own Flash MX program to read in variables from the backend. It’ll be set up very easy, anyone who programmed the robot will be able to modify the backend to your purposes.

Once again though, give me a bit of time, maybe I’ll hack some quick (very poor) CLI interface with some sort of graph like that. I know no way of easily updating though, other than clearing and rewritting the screen. I’ll see if that’s even feasible, but give me some time :).

That’s an interesting idea, but I’m not sure if that’ll work either, I have to figure out how much the current sensors can fluctuate in a given cycle. If it’s too much, I’m still stuck back at square one. If you guys manage to test them out and get some values, please pass them on, otherwise we’ll be testing that soon enough.

And I turn 18 May 14th, so I have plenty of time (especially since I’ll be getting the stuff into council by next week, on pain of death by my dad ;)).

There was a white paper put up by Rob Bayer a year or two ago, try searching for that. If you can’t find that, I’ll write one up I guess, but you’ll have to give me a few days on that as well. Also, keep in mind, this is all for Windows, not for Linux/Mac OSX, as I don’t know how to do it under those OSes. Even though I run Linux at home, I still don’t know enough to program a great deal for it, if that makes any sense :).