Control Board

I know my team is trying to turn the control board into something more productive than just a station to just control the movements of the robot. We are working on a dashboard program that will hopefully interact with our driver both visual and audio outputs. I was wondering if any other teams had ventured into this field, and how they faired in writing the Visual Basic with the PBasic for the dashboard program.
~Mr. Ivey

Audio outputs might be useful. To me, Dashboard didn’t seem to offer much more info than the OI itself, but if you had auditory feedback, you would allow the driver to keep his eyes on the game.

How about a HUD? That’d be cool to see.

now to your dashboard question, what exactly did you want the dashboard to do and more or less show, because you can get a dashboard program that has already been done, but all it basically shows is what the OI shows, now you could make a custom one, and well would prolly take a little longer, but very possible, it just all depens on what you want it to do. And im guessin that the driver this year is Scott, but that is kinda beside the point, so basically it all goes back to what u want the dashboard program to do. hope this helped.

Mike O’Brien
Team 1086
Web Designer/ Developer & Programmer

Yeah, we’ve tested out the OI dashboard, but it really isn’t that great, we wanted to make something that shows Scott what the robot was doing, I was contemplating using the gyro sensor to relay where the robot is on an X,Y,Z plane, and to show a color display of the temperature of the fuses, relays, shows the speed in a color display and in a percentage, and gives off a warning sound when a motor is about to trip. Also we are trying to make a HUD, we are finding out that it really isn’t easy, especially when you have 2 displays, but I won’t go into that.
~Mr. Ivey

The dashboard port helps with feedback like the joysticks, but the information can’t be changed to what you want. The specifications are here.

The visual display we want can not be made with PBASIC, but it can be done with VB, and with some persistance. Remember anything is possible, but all it takes is intelligence, creativity, and above all a problem to overcome. So I’m pretty sure that we will be able to do it, with the help from our mentours.
~Mr. Ivey

Ivey, do you know C++? DirectSound? I would love for you to add your audio ideas to Dashboard3D! That would be terrific! I’m hoping that D3D will receive widespread use in FIRST once I finish it and adding your audio would be really great.

I think Mark knows C++ (if he dosn’t, he can learn it with me. I want to know it too). :slight_smile:

*Originally posted by Adam Shapiro *
**Ivey, do you know C++? DirectSound? I would love for you to add your audio ideas to Dashboard3D! That would be terrific! I’m hoping that D3D will receive widespread use in FIRST once I finish it and adding your audio would be really great. **

I don’t want to discourage anyone because audio feedback would be neat, but be aware that it’ll be hard (if not impossible) to hear the audio at the driver’s station during a match. We all know how loud some of the arenas can get! :wink:

That’s true but it would be nice, even if most teams don’t use it. I agree that it would probably be hard to hear during a match but it might be helpful at other times such as during building or testing.

*Originally posted by Dave Flowerday *
**I don’t want to discourage anyone because audio feedback would be neat, but be aware that it’ll be hard (if not impossible) to hear the audio at the driver’s station during a match. We all know how loud some of the arenas can get! :wink: **

Couldn’t you wear headphones? :slight_smile:

You could wear headphones but it is kind of hard to do that while driving in a competition. You need to be able to hear what is going on around you and if you have headphones on, it might be quite hard. Also, a cable restricting your movements wouldn’t be very helpful…

Hey it’s Mr. Ivey, I’m using joseph’s laptop, but yes i do know some, big word, some, C++, i use my manual, and I can learn it quickly if needed. Just give me some details, and hopefully we can have it ready for this year.
Mr. Ivey

*Originally posted by M. Krass *
**Couldn’t you wear headphones? :slight_smile: **

I read on the technical message board last year that wearing headphones is not allowed but that might be different this year I don’t know. I won’t use headphones anyway. I know that a lot of information can be collected from just the screams of fans. Like if there is a lifting robot on the field and everyone shouts Lift Them! Lift Them! then that is a pretty good indication someone is going to get lifted, not that I know that from experience.

/me remembers bad idea from team 826 last year. Lifting Robots = Bad, very bad.

*Originally posted by Mr. Ivey *
**I know my team is trying to turn the control board into something more productive than just a station to just control the movements of the robot. We are working on a dashboard program that will hopefully interact with our driver both visual and audio outputs. I was wondering if any other teams had ventured into this field, and how they faired in writing the Visual Basic with the PBasic for the dashboard program.
~Mr. Ivey **

Last year, our robot had a current measurement circuit that we used to both protect our breakers, and to sense motor stall on several motors. (we used it as a detect that we hit the mechanical stops)

Anways, the breaker protection was eventually drawin into the stamp code, but at first, our dashboard was used to place up bar graphs of important motor currents. These would not normally be looked at, and they would normally be green…but when the current got into the danger zone (overloaded) the bars would turn RED, and when the motor current stayed OVER CURRENT for a period of time (such that the breaker was going to go very soon) we flashed these red bars…so the drivers didn;t pay much attention until they saw the red flashing…

It worked well, but even that wasn’t enough when the drivers were hot in a match…thats when we gave the STAMP the power to throttle back the motors itself when it sensed breaker failure coming on. (we simply powered back to 30% for the rest of the loop, and let the next loop re-adjust it however…the result was just the right power for a stalled motor that kept the breaker from overloading)

-Quentin

-Quentin

I still can’t figure out what is wrong with the serial input for the Dashboard3D program… If anyone has any ideas as to why the numbers I’m getting are as crazy as they are, I would really appreciate the help. I would really like to get this program up and running as soon as possible so that all teams get a chance to check it out and, possibly, work on it.

Unless we pull a Jesus here people and some maracles happen, looks like we will not have our really cool HUD controll board this year. :frowning:

But you never know… :]

I think it will happen. Plus, it is always possible to code/test the D3D with old robots and controllers (for after the shipping date). Everything in the dasboard packets is essentially the same (actually, it is exactly the same)…