I would like to create a dashboard program for next year. I would dearly like some advice, such as what language to use, how to do it, and what information can be gleaned from the robot.
Any advice at all would be appreciated!
For languages: anything that can talk to your serial port will work, which pretty much means anything. All of the dashboard programs I’ve written in have been in C, but really anything will do.
To start off with, I’d just get a program up and running that can communicate with the serial port. After that’s done you can start worrying about parsing the dashboard packet.
Information: basically you can get all of the analog and digital inputs from the robot, as well as various OI values, the BASIC Byte (which is the User Mode byte) and an AUX byte which has the low battery indicator, the BASIC Run LED, etc. Check Innovation First’s website for the Dashboard port specifications; it will tell you exactly what is in the packet.
When I get home I’ll try to grab some of my dashboard code that I’ve used. Keep me posted if you have more questions.
You can find code for a Dashboard viewer that I wrote here:
http://www.bontragers.net/first/
It was written during the 2000 season so it’s not quite up to date (I believe one of the labels changed but that’s it). It’s written in C/C++ and is designed to run under Microsoft Windows. If you have any questions, feel free to ask but realize that I really haven’t touched it in 3 years.
Matt
Oh man… the dashboard program… my friend (he’s known as Ian W. around these parts) and I made one of those recalls many frustrations and what-not…
Basically, the way we designed it was there’s a C program that reads in the output from the serial port… that little fella reads the packet that the OI spits out… it then processes the data, writes the data to a text file, and a Macromedia Flash program reads it and displays it. The reason we did Flash is because Flash is designed as a graphics package, so rather than learning MFC’s (or whatever the C-non-console method of making programs is called), we made a simple console C program to read and a Flash program to display everything nicely. Thing about Flash: it’s (relatively) quick and easy to make complicated graphical things, like displays. So the flash is our front-end app, the C is our back-end app.
The display actually came out really nice. We have sliding bars that indicate the speed of the motors on the different sides of the robot (tank-drive system) and… ah, I’ll just attach a screenshot of it. It was actually pretty helpful - one of our biggest problems was the transmission not shifting right… after we attached some limit-switches, we could now tell at the controls if our transmission gears were meshed or not. Since we had a very component-happy robot, we used quite a few limit switches (all of the digi-inputs, to be exact). Anyways, the dashboard program made it VERY easy to see what was going on, so moral of the story: dashboard program is helpful.
To actually sent data back is simple… with PBasic, you have control of one byte in the 26-byte packet that gets spit out the serial port. This byte controls the LEDs. By assigning the states of various components to certain bits and reading those bits, well, you get the point. If you want to do something complicated (but alas, something we failed at), you could try sending analogue signals through this byte as well as digital inputs. The trick is use the BasicRUN bit’s state (which alternates every cycle) to tell the dashboard program what the byte you control is carrying - something like if BasicRUN = 0, then {data byte has an analogue value} if BasicRUN = 1, then {data byte has various states per bit}
I’m explaining all this really fast and crappily right now, but most this has been talked about here before, so do a search or post some questions… we’ll help ya out.
[edit]Dan’s Serial Port Tips:
- When testing the serial port communications part of it, MAKE SURE YOU’RE ON A FULL BATTERY! You have no idea how much frustration we recieved when we kept on getting incorrect data and we thought there was something screwey in the program when it was actually the RC doing funky things because of a low battery
- When opening a com port connection, ALWAYS close it. Failure to do this will get you screwey data when testing it the next time
- If you DO forget to close it, you have to restart the computer. Windows handles serial ports really loosely, and once it’s messed up, the only way to fix it is with a reboot. Cold boots are recommended (turn the computer off for 5, 10 seconds, then power back on) to make sure nothing is left over.
- If you keep on getting screwey data but can’t find anything wrong with the program…
4a: Look harder
4b: Look even harder
4c: Ask someone else to take a look at it
4d: Try it from a different computer [/Edit]
Here’s a picture of the flash part (front-end) of our dashboard program this year ([Edit]“No file” on the second line of the battery label should say “No fill” [/Edit]):
wow thats a really really awesome looking dashboard program…
drools
Cory
One of the former students created a simplistic VB one. I don’t have it cause he hasn’t finished… but it worked reallyw ell. It wasn’t all pretty looking like SuperDanMan’s but it worked pretty well. It has a graph function… it’ll monitor what the inputs are doing and you can see a timeline of the inputs/outputs (you setup what you want to see) and it really is a nice debug to see if something went wrong somewhere (missed loops, etc.) But the rest was just simple speedometer type gauges. The graph function really was a good debug system though.
An easy way to do it would be to use Visual Basic–FIRST sent out Visual Studio .NET to every team, so your team should have a copy. This is a white paper I posted containing a .dll for a dashboard custom control I wrote for visual basic. I don’t know if you’ve used visual basic before, but a GUI is very easy to create, and to use the control you just create one on the form, set the port property, and then double click it to edit the newpacket event handler to process the inputs.
Thanks for all the replies! I think I have something awesome figured out. I will post here when I have more questions.
Thanks again
Edit:
I found this code that deals with the byte, but I don’t quite understand it.
code:
get AUTON_PROG_NUM, temp10
out8 = temp10.bit0
out9 = temp10.bit1
out10 = temp10.bit2
out11 = temp10.bit3
out12 = temp10.bit4
out13 = temp10.bit5
out14 = temp10.bit6
out15 = temp10.bit7
How would I go about assigning values to each bit? Is the get command necessary? What is it for?
I take it you’re talking about the pbasic program…
out8 - out15 are the default aliases for the bits in the one byte that you can control from the program. If you want to give them any particular state, just say out8=1, out9=0, etc. By default, those light up different LEDs on the OI, but if you’re making a dashboard, then you’re going to be ignoring those LEDs anyways.
Get a backlit LCD screen and a PIC - then hand code the pic machine language. (I used the MPLAB to do that, but if you want fun … ;-)) It makes a less expensive package to drop, or have jolted off the shelf, than a laptop.
As the computer-store guy, who didn’t have a 6502 Tiny Basic in Rom ($400 in 1980) in stock, said “Programming in machine language is good for you !” So I learned 6502 assembly language, but had to input hex machine code (into my KIM) before i got my first Apple].
I even tried Hudson a few years back, and they still had Tiny Basic.
Regarding Team 810’s 2003 Dashboard Program…
Me and Dan wrote the entire thing on a coach bus on two laptops, testing with our 2003 OI and 2002 RC. Granted, we spent a year (I took the 2002 robot home over the summer) trying to get it to work before that, but the point is, once you get a basic serial port reading program down, it’s easy to add stuff.
Our biggest problem is that we tried to feedback too much data. We sed the basic run bit (as explinaed above) to try and multiplex our feedback. BAD IDEA!!! I’m still not sure why, but it completely skewered our results, and caused a long, painful, year of fustration. So, unless someone can shed some light on my problems, multiplexing is a BAD IDEA!!!
That being said, the dashboard program was very useful, except you have to know what needs to come back and be displayed. Right now, there’s about 5 or 6 things that should have been displayed, and we would’ve moved in several more matches (NEVER LEAVE YOUR PNEUMATICS DISCHARGED!). It was also very helpful in determining whether or not we were in gear, as our gears weren’t very happy, and didn’t like to shift in right away. All in all, definitely worth a year of fustration.
So, if anyone would like to see the Team 810 2003 Dashboard Program, I can probably upload it or put it on my server. The C++ backend is easy enough to understand (I’ll put comments in), and that can be uploaded quickly. The Flash frontend you’ll have to ask Dan about, as I know nothing about Flash (Dan is one of the two Flash Gods on 810 ;)). Once again, he made the entire thing on a coach bus, so it can’t be too complicated, I think :).
When I get a chance to get the C++ (and Flash if Dan lets me :p) up, I’ll post a link, but till then, if you have any quick question, feel free to IM me (check signature for screenname).
Oh, and one last thing, I think the Dashboard Program is technically multiplatform, but I’ve never compiled the C++ backend on Linux/Mac, so I can’t say for sure. I don’t think there’s anything Windows specific, but there probably is.
*Originally posted by Lloyd Burns *
Get a backlit LCD screen and a PIC - then hand code the pic machine language. (I used the MPLAB to do that, but if you want fun … ;-)) It makes a less expensive package to drop, or have jolted off the shelf, than a laptop.
Was that really legal this year? I think it should be, but we decided to avoid anything like that because the rules were a little vague on the issue:
Teams are permitted to connect a portable computing device (Laptop computer, PDAs, etc.) to the RS232 Output of the Dashboard Port…
Does “portable computing device” include homemade portable devices? They really should clarify that because as it stands my guess is it’s up to the referee/inspector/FIRST person on location and that there isn’t really an official stance on it.
I know last year there was a team that had a really nifty WinCE device displaying dashboard stuff at MMR which they were told they couldn’t use (even though the rule clearly allowed that). In an effort to avoid hassle they simply removed it rather than arguing about it.
I’d love to see FIRST open the rules up on the OI side a little bit similar to what they did on the RC side with the custom circuit. I mean, a lot of teams already have custom controls - the team with the pirate boat to control their wings comes to mind. Would it really be that big of a jump to allow custom circuits to be connected to the OI?
Two things: (It was going to be three, but I deleted a rant about “rules” and “compliance”.)
1 - I used such a device several years ago - even got permission to use power from an OI joyport (a pic and an LCD draw about 15-20 mA) even though First INSISTED that all devices had to be battery operated, instead of just saying ‘must not require 110VAC power’. The next year, they used the same rule, but decided against my little circuit on the basis of “had to be Battery operated” - as if the outcome of the match depended on it).
2 - The PIC and surrounding circuitry is a computing item that I can lift and put in my pocket. I devised one such. Surely, that does meet the First definition of a portable computing device. A 9V bettery feeding a 78L05 regulator would restore the function.
I know last year there was a team that had a really nifty WinCE device displaying dashboard stuff at MMR which they were told they couldn’t use (even though the rule clearly allowed that). In an effort to avoid hassle they simply removed it rather than arguing about it.
That was us, team 109. We plugged an HP Jornada into the Dashboard port, but the referees we showed it to would not let us use it. Ironically, we won the Delphi Tech Award for using the PDA.
Here’s a screenshot of the program.
http://www.chiefdelphi.com/forums/pictures.php?s=&action=single&picid=5110
Thanks for the memories.
*Originally posted by Dave Flowerday *
**I’d love to see FIRST open the rules up on the OI side a little bit similar to what they did on the RC side with the custom circuit. I mean, a lot of teams already have custom controls - the team with the pirate boat to control their wings comes to mind. Would it really be that big of a jump to allow custom circuits to be connected to the OI? **
We could only be so lucky. Alot of people have been doing alot of stuff with the controls in recent years. The pirate team comes to mind, cyber blue, and 447 with the joystick gloves and staff of power (even if the staff didn’t work it was still cool). Atleast get rid of the rule banning modifying the stock joysticks. I understand they dont want people crossing wires and frying their OI but its at your own risk. Every single thing on our controls was custom wired in some way, from a y cable to adding our LED goggles it was all wired really strange but alot of time could have been saved if i could have rewired it in the joystick.
Custom circuits on the control side would also be great for doing more advanced controls with some more custom type controls…
I know i have a strange idea for controlling a omni wheeled kiwi drive type robot with a big kids track ball which would be kind of hard to do with the rules as they are now.
I have been reading the innovation first documentation on this, and I have discovered that you can use analog sensor bytes 1 through 5. If you edited these bytes, the edited results would get sent to the oi dashboard port. I want to try this, but I don’t have the necessary programming skills yet. Could somebody try this and tell me if it works?
If it does, then you have six bytes in which to put your dashboard data. (I’m still counting the led byte)
http://www.innovationfirst.com/FIRSTRobotics/pdfs/2003_Dashboard%20_Spec.pdf
Oneangrydwarf: I agree with you. It would be awesome to make a control with tactile feedback.
http://www.innovationfirst.com/FIRSTRobotics/pdfs/Control_System_Overview.pdf
View Page 4
There are three processors on the Robot Controller. The two of significance are the main processor and the PBasic stamp. The return information is sent back by the main processor. It’s the main processor that reads in the analog inputs and sends them to the PBasic stamp. The PBasic stamp only returns the dashboard bits (the LED bits in the code). After the PBasic stamp does that, the main processor gathers all of the information and sends it to the modem to be transported back to the OI.
Bottom line, you’re thinking good, but you can’t do that. The only bits that you can change are the 8 in the dashboard byte and the BasicRun bit.
Well…
How about using a couple of first or last bits as sigs?
ie:
00(2bits +1st part of byte 1)
11(2bits +second part of byte 1)
10(2bits +1st part of byte # 2)
01(2 bits +2nd part of byte # 2)
This would take at least .1 seconds to do, but you get two bytes out of the deal. My guess is that your problems arose because of the order in which the bytes and bits are sent.
Edit/
You could even do a third byte from the bits
Hey everyone. I just posted the code for Dashboard3D http://www.chiefdelphi.com/forums/showthread.php?s=&threadid=20592. Please check it out and, if you still want to make your own dashboard, it could be very useful. It is in total working condition.