I was looking at the dashboard program from innovation first and I noticed that it only shows 2 pwms: PWM1 forward/reverse and PWM2 forward/reverse.
I’m not the teams programmer but I’m wondering if anyone has ever made their own dashboard program similar to innovation first’s but it would show at least 8 pwm’s. How would I go about making a new dashboard?
what do you mean by program? like something that sits on your laptop and gives you feed back?
yes, that’s what i mean
I downloaded one off the white papers, it was made by team 7, i haave been messing with it. Its pretty good i forgot where i found it look around white papers to find it
The fact that it only displays PWMs 1 and 2 is because that’s all the data that gets sent to the dashboard port. For full details, you can grab InnovationFirst’s documentation from their website.
Also, I’ve written a linux dashboard viewer (gDash) which you can get from my website www.robbayer.com, though it suffers from the same lack of PWM feedback for the reason stated above.
–Rob
*Originally posted by Ryan_team710 *
**I downloaded one off the white papers, it was made by team 7, i haave been messing with it. Its pretty good i forgot where i found it look around white papers to find it **
I’m assuming you’re speaking of the one made by me while I was on team 7 (I believe it was written in 2000). It can be found here: http://www.bontragers.net/first/
Matt
Ya thats the one . I liked it It helps us debug alot of things
*Originally posted by ryan_f *
**I’m not the teams programmer but I’m wondering if anyone has ever made their own dashboard program similar to innovation first’s but it would show at least 8 pwm’s. How would I go about making a new dashboard? **
i’ve had plenty of trouble with this problem, trying to send back all the PWM data. I’ve learned that by manipulating the Out bits (Out8 --> Out15) you can send up to an entire byte back. That’s enough to show two states for each PWM, but only two. I have tried to multiplex the feedback, by timing based on the Out7 bit (the one that toggles on and off to show that the PBASIC chip is working), but I have had no luck with that, as the C++ code could not decode the streams correctly (sometimes data would come back right, other times wrong, but predictably wrong). In short, I gave up on that and figured out how to deal with less variables being given back.
I’m hoping that next year the new controller will have much more flexibility with what is sent back, and how much is sent back. This is almost a must, if we are to have more autonomy. I think that it’s useful to feedback anything and everything you can, so you know if anything is wrong at the end of autonomy, but that’s currently next to impossible without building a custom board. In anycase, we should be learning of the new controllers soon, so don’t pull your hair out if you can’t get a dashboard that does everything you want it to do with these controllers.
i’m not sure what the first dashboard program is, but i was developing sort of a dash board program for my team which was to be displayed on a laptop screen on the driver station
it was done in flash and i basically had the flash side done but since the major reason why it was being made (our CVT’s) was never made a componenet of the robot, there wasnt really much use of this dashboard display
i may do some work on it more for next year’s robot if there is use of it (CVT or complicated robot features). it also was supposed to show a map of the field with the robot in it using the data from our INS system which i dont think really was accurate enough in the long term anyway
all the data was to be sent using the few pins available that are sent back to the driver station, all the data was to be encoded but this part wasnt even started so i dont know how it would have went and i read here that people had some problems with this and indeed lets hope for better first hardware next year (would make things easier)
i have one picture of a really early version being developed at http://users.wpi.edu/~piotrm/projects/images/first_hud_1.jpg
since its in flash it doesnt have direct access to hardware like the serial port so the intention was to write a tcp server to be run on that computer which would communicate with the hardware and serve the data via tcp (flash XML Socket routines). i have had much flash/tcp communication experience already (tacOps display server) so thats not the problem and can help anyone out if they are interested in doing something like this
good luck
i think robs programs will do what you want, if im nto mistaken (which i may be) there is a program out there or here in the whitepapers that give you feedback for all the PWM’s…
~Mike
*Originally posted by Ryan_team710 *
**Ya thats the one . I liked it It helps us debug alot of things **
Maybe I’ll get around to updating it a bit someday. When I have some free time (ha!). I’m always amazed by the number of people who found it useful at some point in time.
Matt
*Originally posted by dez250 *
**i think robs programs will do what you want, if im nto mistaken (which i may be) there is a program out there or here in the whitepapers that give you feedback for all the PWM’s…
~Mike **
Sorry, but it won’t. Unless you want to use the LED feedback bits like Ian W. suggessted, you’re not going to be able to see the actual values of any of the PWMs.
OK then thanks Rob, i guess i was mistaken and that the program i was thinking of doesn’t give you analog feedback, only binary.
~Mike
firestorm dosent work. WHY?
there is one way to give feedback of all 16 PWMs, and all it requires is a pot and some coding knowledge.
i just thought of this now, so i think it should work, someone may want to check this though. second, probably a bad idea for use during a competition, due to extra code.
first of all, plug your joystick in, as we have the wheel that we can use as a pot (yay!).
Divide 255 by 16, we get approximately 16, but since it’s PBASIC, let’s truncate and make it 15.
Down at the very bottom of your code, after everything but the SEROUT (this way you’re sure to be outputting the correct values), but something like this (excuse any syntax errors, it’s been a few months :p)…
switch (wheel_var)
case 0 to 15:
out8 = pwm1.bit0
out9 = pwm1.bit1
out10 = pwm1.bit2
out11 = pwm1.bit3
out12 = pwm1.bit4
out13 = pwm1.bit5
out14 = pwm1.bit6
out15 = pwm1.bit7
case 16 to 30:
out8 = pwm2.bit0
out9 = pwm2.bit1
out10 = pwm2.bit2
out11 = pwm2.bit3
out12 = pwm2.bit4
out13 = pwm2.bit5
out14 = pwm2.bit6
out15 = pwm2.bit7
and so on till you get up to pwm 16.
turn the wheel, you can probably estimate the distance needed pretty easily, otherwise you can very easily output it to a laptop computer and see what pwm you’re getting (i believe the wheel on port 2 is sent back already).
now, if you have the 2003 controller, put it into User Mode, and you get the pwm values right there on the controller, nothing else needed.
if you don’t have the 2003 controller, i’m sure there is a program, or i’m willing to write a quick and dirty command promt program that will simply output the pwm value (converted back into decimal or 0 - 255).
as I said, this is not the best code to have in a competition ready robot, but as long as you’re just testing, i guess it’s fine.
DISCLAIMER: I think this should all work, but I haven’t tested it (because I’m too lazy to boot into Windows, find my old robot code, add this in, and plug it into the controller sitting on my desk). If you have any problems (like robots blowing up or killing people) either you did something wrong, or it’s a hardware problem ;).
<EDIT> Sorry about the lack of spacing, but I can’t think of any other way to make it space correctly</EDIT>
*Originally posted by Ian W. *
**<EDIT> Sorry about the lack of spacing, but I can’t think of any other way to make it space correctly</EDIT> **
use the [code ][/code ] tags.
Ian great job with the code, that will be very useful to some of us and its nice to know someone on here can spit out code that works and is willing to share it…
~Mike
P.S~That post was not meant to be flaming anyone
First off, excellent idea. One thing that many people don’t seem to know is that there is a variable called OUTH that is byte-sized and includes out8-out15. With it, you can clean up the code a lot, so that all you need is:
SELECT p3_wheel/16
CASE 0 to 15: outh=pwm1
case 16 to 31: outh=pwm2
…
ENDSELECT
Hmm. Could you mux it like this?
var counter byte
counter = 0
mainloop:
select ( counter // 5 )
case 0: outh = 255
case 1: outh = pwm1
case 2: outh = pwm2
case 3: outh = pwm3
case 4: outh = pwm4
endselect
counter = counter + 1
goto mainloop
Considering that the RC runs at ~40Hz, if you output four PWM values, along with a sync value (might be unnecessary), you’d get ~8 output values per second.
I have never written a dashboard program, so I don’t know the intricacies of doing this kind of thing. Sorry. Just a random thought.
i’ve tried stuff like this, but i never got it to actually work 100% of the time. i think it has something to do with the serial port or the PBASIC chip, but i was never able to find the problem, as i kinda gave up after a while. i based my “counter” off the BasicRun LED, which toggled between 0 and 1 every loop, so i think it may have gone too fast, or slow, or something, for it to properly sync with the computer. if anyone wants to see my 2002 dashboard program (simple C/C++ console app), i’m more than willing to post it, but it doesn’t work.
rob, thanks for the tip with OUTH, i never knew it existed till now, although it may or may not be important next year.
brandon, would it be that hard to add a
tag button, or are we just so close to vB3 now that it doesn’t pay to go and edit the vB2 code (the latter, i hope :p)?