Makin' a home-brewn dashboard program, and I need theory help!

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 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 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 :slight_smile:

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.

*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 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 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 :slight_smile: **

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.

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?

*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…

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…

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.

[EDIT]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.[/EDIT]

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! :smiley: Oh well, i guess i’ll just have to find a FIRST team, and make sure that i’m the mentor. :wink:

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?

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?

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.

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 :slight_smile:

Nah, the more help we get, the better. It’s always interesting to find ways around problems. :smiley:

hmmm, that alternating trick is actually a great idea. Thanks =)

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 =)

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.

*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.

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…

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.

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… :smiley: