PDA

View Full Version : Makin' a home-brewn dashboard program, and I need theory help!


DanL
05-31-2002, 04:51 PM
Okay, so Ian and I have decided to make our home-brewn Dashboard program (after all, wheres the fun in using someone elses?). Anyways, before we do any programming, we want to make sure we have the theory correct.

Basically, this (http://www.innovationfirst.com/FIRSTRobotics/pdfs/DashboardSpec2001.pdf) document describes whats in a Dashboard packet. Now, if I understand it correctly, ANALOG1-7 are the analog inputs on the RC, SWITCH_A, _B are the digi inputs on the RC, and PORT 1/2/3/4 Y-Axis are the raw joystick feedback from the OI?

Now, before we go further, my first question is the x/y axises in the dashboard packet, are these the inputs from the oi, or the appropriate variables in the default code?

Anyways, moving on... So basically, our main question is where do these variables come from? Do they come from the OI master processor, or do they come from the information processed by the PBASIC processor?

Basically, the reason why we want to know is we want to be able to check the processed variables, kinda as if we were debugging them. Now, the diagram on page 5 of the user manual (http://www.innovationfirst.com/FIRSTRobotics/pdfs/ControlSystemUsersManual.pdf) was kinda ambiguous. It appears that it outputs the 'dashboard bits' (analog1-7, switches_a, _b ?) after the processing. Does this mean that we can have the code manipulate the input variables and then use these to view it from the dashboard port? Meaning, say that we wanted to view a PROCESSED pwm output. Could we set an unused Analog input from the RC to the PWM value and thus, be able to view the final PWM output on a dashboard program?

Any clarifications would be helpful :)

Ian W.
05-31-2002, 06:04 PM
We also need some help on the 'reading a packet' part. I have the Firestorm Dashboard program, which was written by Matt Leese. I was looking at the packet.c and packet.h files, and well, they're a bit confusing to me. I understood the basic idea of what they did, but how they do it, I have no clue. If someone could clarify how these work (Matt, you out there :p), that would be great. The biggest problem I'm having is that I only know basic C++ commands (everything up to link-lists, if that helps). I know there's ways to make Bytes and Bits, and run loops ~40 times a second, but how, I do not know. I tried reading Matt's packet.c/.h files, but I couldn't get anything beyond the basics.

So, what me and Dan need is someone to tell us how it works, or a website that tells us where to get info on how this stuff works. Seeing as I don't know what I'd even be looking for, I haven't really done any searches. Kind of hard to look for something, when you don't know what it is you're looking for :p.

Nate Smith
05-31-2002, 07:58 PM
Originally posted by SuperDanman
Okay, so Ian and I have decided to make our home-brewn Dashboard program (after all, wheres the fun in using someone elses?). Anyways, before we do any programming, we want to make sure we have the theory correct.

Basically, this (http://www.innovationfirst.com/FIRSTRobotics/pdfs/DashboardSpec2001.pdf) document describes whats in a Dashboard packet. Now, if I understand it correctly, ANALOG1-7 are the analog inputs on the RC, SWITCH_A, _B are the digi inputs on the RC, and PORT 1/2/3/4 Y-Axis are the raw joystick feedback from the OI?

Now, before we go further, my first question is the x/y axises in the dashboard packet, are these the inputs from the oi, or the appropriate variables in the default code?

Anyways, moving on... So basically, our main question is where do these variables come from? Do they come from the OI master processor, or do they come from the information processed by the PBASIC processor?

Basically, the reason why we want to know is we want to be able to check the processed variables, kinda as if we were debugging them. Now, the diagram on page 5 of the user manual (http://www.innovationfirst.com/FIRSTRobotics/pdfs/ControlSystemUsersManual.pdf) was kinda ambiguous. It appears that it outputs the 'dashboard bits' (analog1-7, switches_a, _b ?) after the processing. Does this mean that we can have the code manipulate the input variables and then use these to view it from the dashboard port? Meaning, say that we wanted to view a PROCESSED pwm output. Could we set an unused Analog input from the RC to the PWM value and thus, be able to view the final PWM output on a dashboard program?

Any clarifications would be helpful :)

All of the values returned through the dashboard port are the hard-wired values, meaning that you can not change, for example, analog5, in code and have that modified value returned to the dashboard.

DanL
05-31-2002, 09:46 PM
hmm, that bursts my bubble. Well what about the axis bytes? It seems kinda silly to hardwire only p1_x, p1_y, p2_y, p3_y, p4_y, and p2_wheel without being able to change it according to the setup. Can you change THESE values?

Nate Smith
06-01-2002, 01:37 PM
Originally posted by SuperDanman
hmm, that bursts my bubble. Well what about the axis bytes? It seems kinda silly to hardwire only p1_x, p1_y, p2_y, p3_y, p4_y, and p2_wheel without being able to change it according to the setup. Can you change THESE values?

Nope...the only byte you have control over is the LED byte(don't remember the exact name right now)...the general workaround for the x and y axes is that if you want one to come through the dashboard that doesn't right now, rewire how the joystick connects to the OI...

DanL
06-01-2002, 02:15 PM
Hmm, okay, well thanks for the help. Arrg, I think in the future InnovationFIRST should give us one or two bytes that we can access in the code and send through the dashboard port...

Nate Smith
06-01-2002, 04:46 PM
I know quite a few of the teams used the LED control byte(and sometimes just taped over the corresponding LEDs on the OI), to feed data back...it is possible, however, that when the new-generation control system comes out(by 2004, I've heard), that the dashboard structure will be different.

Something else to keep in mind, as well, is that without updating the default code and the firmware in the master CPU, the only data that currently gets output from the user control program anyway is the 9 LEDs(basic run + LED control byte) and the PWM/Relay outputs.

Ian W.
06-01-2002, 05:06 PM
But by 2004 I'll be a senior, or if it's fall 2004, I'd be in college! There's no fun in having a really cool feed-back system if i can't use it! :D Oh well, i guess i'll just have to find a FIRST team, and make sure that i'm the mentor. ;)

DanL
06-01-2002, 05:31 PM
hmm, just out of curiosity, would it be possible to somehow loop a PWM signal back into an analog input? I'm not exactly sure about how the whole Pulse-Width-Modulated stuff works in comparison with the analog inputs, but would it be possible to somehow take a pwm output and loop it back into an analog input?

DanL
06-02-2002, 01:46 AM
Actually, I've been thinking.... they give us control over one byte. That means we can send either 8 digital outputs to the dashboard, or one 0-255 output...

If the 0-255 method is done by having
bit 0 = 1
bit 1 = 2
bit 2 = 4
bit 3 = 8
bit 4 = 16
bit 5 = 32
bit 6 = 64
bit 7 = 128
then turning on/off the appropriate bits to get any number from 0-255 (1+2+4+8+16+32+64+128 = 255), couldn't this method also be used to get two numbers from 0-15? Meaning....
bit 0 = 1
bit 1 = 2
bit 2 = 4
bit 3 = 8
bit 4 = 1
bit 5 = 2
bit 6 = 4
bit 7 = 8
So, using this method, we could program the Robot Feedback byte to actually carry two PWM values, but just the PWM value 16. Since the maximum value is 255, if we divide it by 16, we get a number between 0 and 15. Thus, we could send to a dashboard program approximately two PWM values.

Say the code outputs a value of, oh, 123 to a pwm. We can take 123 and divide it by 16. Since PBASIC doesn't handle decimals, the final result would be 7 (it's actually 7.6875). This number will always be between 0 and 15, so we could use bits 0 through 3 to 'encode' it (bit 0 - on; bit 1 - on; bit 2 - on; bit 3 - off; 1+2+3 = 7). The same could be used with bits 4-7.

In the end, the dashboard program would read the Robot Feedback (LED) byte and from it, decode two numbers between 0 and 15 - or, two PWM outputs to the nearest 16. Sure, it's not perfect, but it's an approximation of what your robot code is sending out to the PWM.

This method could also be used to transfer to a dashboard program an approximate PWM value AND 4 digital outputs.

You guys understand what I'm trying to say?

Joe Ross
06-02-2002, 03:04 PM
That's correct, and you can break it up anyway you like, because you are in control on both ends you can do whatever you want with that byte and break it up whichever way is best for your robot.

Just remember that the digital inputs are already sent back, so you only need to send it back if you do some type of calculations with the results.

Dave Flowerday
06-02-2002, 08:45 PM
There's all kinds of tricks you can pull to cram more data through those 8 bits. If you need to send back two values, you can use one of those bits to indicate which value you are sending, then use the other 7 bits as the value. For instance, use the most significant bit as the value selector:

Bits
7 6 5 4 3 2 1 0
----------------------
0 0 0 0 0 0 0 1 = Variable A = 1
1 0 0 0 0 0 0 1 = Variable B = 1

This way you can send back a number between 0 and 127 for each variable and just alternate which one you send. You can carry this idea further and trade a bit of precision for another power of 2 of variables, i.e. 6 bits for the value, 2 bits for the variable number, etc.

If you need to send back lots of values and only need to do so a couple times a second, you could something like this: Send the values 0xFF, 0x01, 0xFE, 0x26, 0xFF, 0x02, 0xFE, 0x67... In this sequence, 0xFF is an attention signal: it means that the next number will be the variable number. Then 0xFE is another attention signal and means that the following number is the variable data. So the above sequence tells you that variable 1 == 0x26 and variable 2 == 0x67. Now obviously you can't use 0xFF and 0XFE as either a variable number of a variable value. The downside to this is that it takes 4 dashboard packets to send each value, so you can only send 10 variables a second. There's also a problem which is that you don't know exactly when the master CPU is going to send a packet, so you can't really send 40 different bytes a second. Probably it's more like 10-15 bytes a second, so using this method you could maybe send like 2 to 4 variables per second.

Anyway, I hope this gives you some ideas. Basically you can do a lot with 8 bits by trading either time or precision. Sorry for rambling on so long :)

Ian W.
06-02-2002, 09:36 PM
Nah, the more help we get, the better. It's always interesting to find ways around problems. :D

DanL
06-02-2002, 09:56 PM
hmmm, that alternating trick is actually a great idea. Thanks =)

DanL
06-02-2002, 10:27 PM
Ian just pointed out something to me.... you have one more bit to play around with - the Basic Run LED. Since the code by default toggles this guy on and off every cycle, you could use it for your own purposes. You actually have 1 byte and 1 bit to send back to the dashboard =)

Joe Ross
06-03-2002, 10:19 AM
I beleive that FIRST wouldn't like you messing with the basic run LED. They use that as one of the indications that the program is functioning correctly. I would contact them before I start using the Basic Run bit for anything, at least on a competition robot.

Nate Smith
06-03-2002, 11:45 AM
Originally posted by Joe Ross
I beleive that FIRST wouldn't like you messing with the basic run LED. They use that as one of the indications that the program is functioning correctly. I would contact them before I start using the Basic Run bit for anything, at least on a competition robot.

While Joe is right on this(check with FIRST before doing anything like this), it seems like I remember hearing of this being done before, with no objections from FIRST...if nothing else, have a switch connected to your OI that would let you switch between a "normal" Basic Run LED, and the value communication mode.

Ian W.
06-03-2002, 02:40 PM
well, think of it this way...

if the LED is toggled on and off in the code, shouldn't we be able to use it how ever we want? if they really wanted to, they could code it in to the master chip, so that only when the pbasic chip ran the code the LED went on/off, but they decided to use the code. so, we should be able to use it for our own purposes.

also, you could aways just use it as an alternator. when out7 (the basic run LED) = 1, the basic byte equals pwm output 1, when out7 = 0, basic byte equals pwm output2. anything like that would work fine, and not interfere with how the LED runs.

i just wish that next year, they gave us more control over what is outputed. could they possibly give us another 'Serout' statement, that sent a stream of no more than 26 bytes out to the dashboard. of course, some would be used, and you can't change that, but if at least a few could be changed...

Dave Flowerday
06-03-2002, 03:28 PM
It's unlikely that we will ever get to send back more data than we're currently able to, even if Innovation First and/or FIRST wanted to give us the ability. This is because the radio modems are transmitting at their maximum data rate (about 9600bps). Thus if it was somehow set up so that you could send another 26 byte packet of your own, you would have to send this packet instead of a normal robot feedback packet. Also, the firmware which runs on the two other processors in the RC and the firmware in the OI would obviously need to change, which means that someone has to write it, and test it, etc. which is very time-consuming.

Ian W.
06-03-2002, 03:34 PM
I just wish FIRST gave us some more control over what was sent back. I'm fine with like, 5 or 6 bytes being taken up by competition important things, but if you only have 1 analog input, why should you have to waste 6 bytes on nothing? same goes for joystick feedbacks. why waste so many bytes on something that many people might never use? i find it a little silly, but oh well. maybe next year... :D

VanWEric
06-03-2002, 05:06 PM
Can anyone point me to the source code of a dashboard viewer that already works? I need to see how the structure is set up before i can program it. A nice VC++ app would be nice. I sort of new to the c++ language, but i am caching on fast, so even uncommented code would be of some help. Thanks

Ian W.
06-03-2002, 05:29 PM
i have what seems to be the actual code from Matt Leese's Firestorm Dashboard. from what i can tell, it's an MFC built with VC++ (an old verison of it, like 4.something). i can't get the source code to run though, cause i don't have all the resource files. i do have the library which grabs the packet though, so if you do need that, i can give it to you.

Jay Lundy
06-04-2002, 03:49 AM
Actually, the resource files are in there, just not in the right directory. When you unzipped it there should be a folder called "MSDEV". Goto "MSDEV/projects/Firestorm Dashboard" and move the "res" folder into the folder with all the source files. Then you can run it in VC++.

VanWEric
06-04-2002, 08:16 PM
Some one should really cobble together some form of how to. I am getting lazy in my old age. What with all this opengl stuff that is being shoved down my naive throat, no more code is fitting anymore.

rbayer
06-04-2002, 09:55 PM
What would you like a how-to on? I just posted one on serial ports, but would be happy to write another if people would find it useful.

Matt Leese
06-07-2002, 08:28 AM
Alright, so there was a call for me above and I hadn't gotten around to answering yet. I was planning on annotating the packet.c file (I started, I swear!) but the whole starting a new job thing has made it rather difficult to get it done. That said, I hopefully will be able to finish that in the near future but I have several other projects I'd also like to work on in my spare time (everyone remember that emulator everyone always wants ;) ).

Anyway, if you'd like to see the dashboard viewer I wrote which is partly written in C and partly written in C++ and runs in Microsoft Windows 95, 98, ME (unfortunately because of a small bug it doesn't run in Windows 2000 or Windows XP; yes I know what the bug is and I may correct it at some point but the dashboard viewer hasn't been of particular interest to me recently; not least of reasons because I don't actually have anything to interface with) it is available at http://www.bcpl.net/~mleese/dashboard.html
I would like to say that this location will be moving after any changes I make (it's an old-dialup account that I have trouble getting access to).

As far as sending data back to the dashboard port, it isn't the easiest thing in the world but, you do get 11-bits and not just a single byte (8 bits). There hasn't been a particular good use that I've seen but that doesn't mean it's not out there.

If you have any questions about the dashboard port or programming in general, feel free to contact me (private message, email, IM, whatever).

Matt

rbayer
06-10-2002, 10:28 AM
Matt, what type of emulator are you working on? I'm in the middle of one too, and was wondering if you might want to collaborate a bit... anyway, just offering. PM/email/ICQ me if you are interested.

Kevin Watson
07-01-2002, 11:38 PM
Ian,

A very important part of dashboard port data handling is the implementation of a "state machine" to keep track of where you are in the telemetry data stream. I've placed an example application, written in C, that illustrates the idea here:

http://www.cvhsrobotics.org/resources.htm

Look for dashbd.c and dashbd.h. If you have questions, feel free to fire-off an e-mail in my direction.

Kevin

Ian W.
07-02-2002, 12:18 PM
the way that you read in data, is it byte by byte? from what i could tell, it seems that way, but i wasn't sure. which way is better, this way, or to read in entire packets at once? there's way to many ways to do this :p.

Kevin Watson
07-02-2002, 12:32 PM
Ian,

Yes, this example assumes that data is read from the computer's UART one byte at a time. From a software standpoint, this is the easiest case to deal with. If your computer's UART has a FIFO buffer on the output, and you get packets larger than one byte, the code (state machine) gets just a little more complicated.

Kevin

Ian W.
07-02-2002, 01:11 PM
and that just flew right over my head :p

i sort of understand the whole idea about the buffer, but the only thing that i know 100% is that when i plug something into the COM port on my computer, it makes a nice connection, and energy signals go back and forth and things happen :D. i want to learn more about this, but i haven't had a chance to yet.

anyways, the way i was trying to run it, it grabs a whole 2 bytes, then searches through. i seem to recall someone saying that you had less of a chance for error that way, but i'm not sure. i think i'm going to try and redesign my program though, because it doesn't work right now, and i think that the way your's is written is simpler.

thanks for the help.

nwagers
07-04-2002, 09:25 PM
Does anyone program with VB? I've noticed a ton of C stuff floating around but nothing from any other languages. At one point I was working on a program that will create PBASIC from a simplified form designed around the structure of the Default Program. E.G. a line like "Filter P1_Y" would be translated into the code needed to run a low pass filter on that variable. I think this will create an environment that will allow rookie programmers to use many advanced features without consuming all their time.

Ian W.
07-04-2002, 09:41 PM
i believe that someone was working on that. um, i forget who mention it, but i know it had some functionality. the only problem with something like that is that a rookie programmer could become dependent on it, so you would need to have the code created, then show why it works. then, the next year they can go and do it without the 'code-creator'.

rbayer
07-05-2002, 01:26 AM
I actually wrote something a little more advanced. It is a fully graphical program generator that supports all kinds of advanced features such as deadzones, filters, tank drive, limits based on digital or analog sensors, etc, etc. It's written in one of my infamous mixtures of C and C++. Check it out at http://FIRSTprograms.tripod.com/ and tell me what you think.

As for the VB code, have you checked the Whitepapers section? I seem to remember a VB-based dashboard viewer there, but I could be mistaken.