I’m honestly not sure if anyone’s ever tried this, or if anyone else even thinks it could be a good idea, but I just want some feedback on it in general.
Basically, this all started with a PS2…
My girlfriend was playing GTAIII on her PS2, but when she turned it on, she was running in circles. I told her immediately it was because she had left the control upside down. She asked me why anyone would want the sticks to center when you turned on the system. I wasn’t totally sure, but I told her it was problaby to make sure they always started in the middle. She said, and I quote, “too bad our bot doesn’t do that”. And so began an idea…
The attached code is what I came up with. Ignore the “factoring” part, as that was something that my team is using to test out a new drive system. Any thoughts on it would be greatly appreciated.
I know the obvious downfall is the same as with the PS2 controller, if someone pushes the stick forward, and turns on the bot, it will jump. I added in a way to “recalibrate” the sticks, but that would still be after the bot initially runs amok and crashes into someone’s kneecaps.
Our team goes back an forth about whether on not this is a good idea. We debate it over and over.
If you decide to do this, I think you have done a pretty good job. One thing I may suggest is that when you wake up (at the initialization of the code) you can check the state of some buttons (dedicate a button or pick an unusual combination of buttons that are unlike to be pressed upon reset) and then only recalibrate if these bottons are pressed.
You don’t have to have a live recalibrate button if you only check this at the initialization of the code. If you wake up and your robot is insane because of a bad calibration (perhap you had a zero calibrated from an old joystick an you just put in a new joystick with a different zero point), you can just press robot reset on the operator interface along with the other buttons for recalibrate and viola! you’re back in business.
Just a consideration.
FYI, we always come to the conclusion that it is better to leave the code alone and set the joysticks to proper trim value. Two reasons drive this. #1 we are already code hungry fools, giving us less to have to do every loop may be the difference between missing 2 data packets and missing only 1 – this is a worth goal. #2 we are always worried about having to replace stuff that breaks. We have had balls come over the wall an break oe of our joysticks off. We always prefer to be able just plug in a new joystick and run with it without having to recalibrate.
I don’t mean to be rude, but you argued both sides, very well I might add.
I thought about this a few time through out the year last year, and I still haven’t really come to a concluion. One option saves code the other time. I guess to me last year I was on the field so I set the trim before every match and there was not problem until the driver hit the trim wheels. I guess this can happen even with an auto calibration so it prolly don’t matter. What I found easiest last year was taking advantage of the user mode that is on the 2003 controllers. I used it to calibrate the joysticks and that worked pretty well.
I guess my indecicevness will in the end prolly make up my mind for me.
Our team has been doing something similar to this for years (with a bit of a twist). We don’t (and the code/hardware combination doesn’t allow us) to re-zero the sticks during a match.
What we did is mount a special “stick calibration switch” onto the robot itself (that way we can’t accidentally push it while in the driver station before the match). The switch is a spring loaded rocker so if you’re not physically pushing it, it is in the non-cal mode.
Anyway, upon power up, if the switch is ‘ON’, the software goes into calibration mode and takes the zero points of the joysticks. If the switch is ‘OFF’, the cal mode is bypassed. We find that we rarely have to do a cal more than once per competition since the joysticks don’t drift that much if you inhibit the motion of the trim wheels).
I’ve found a much easier solution is just to pass joystick values back to a Dashboard Program.
The RC passes back Y-Axis for all four ports, and the X for the first. This allows you to get real-time perfect precision control of the joysticks.
I will be working on a very basic dashboard program over the summer, that will (hopefully) when it’s done collect all the information and save it to two files, one that is read by a Flash MX program (the second half of our Dashboard, and the part that only works with our robot), and a second that will save all the data given by the robot. IF people want, I can also make a mode that just outputs all 5 joystick axises to console, and to zero out the joysticks just make them all equal to 127.
I’ve found that the Dashboard Programs, even when saving to / reading from a file are very quickly updated, because the RC is so slow compared to a laptop / desktop, so it’s very easy to calibrate the joysticks this way.
The other possible way to calibrate the joysticks is to use the DEBUG command in PBASIC, except that slows down the code execution a lot, where, as far as I’ve noticed, the dashboard port doesn’t seem to affect it much.
What does it mean to go back and forth on an issue?
If the answer was clear cut, we would make a decision and forget about it.
As it is, there are pros and cons to both sides.
I discussed some of them in my message.
What more can I say?
Joe J. **
I think I was tired and not thinking clearly. For some reason I thought your team made a descision and then you argued both points. But then, what do I know. Maybe I should keep my mouth shut.
*Originally posted by Joe Johnson *
**
FYI, we always come to the conclusion that it is better to leave the code alone and set the joysticks to proper trim value. **
I agree Joe,
For the drive train we typically include a “joycal” button on our OI that allows us to trim up our drive stick. This year, since we had 4 pairs of pots to trim , in addition to the drive stick, we had a separate set of trim routines that we’d down load.
To eliminate drive train “surprises” we always set the 'bot on “pony” blocks when we first fire it up.
Like Joe says, there are good reasons to do it either way. BTW…like the code JLambert!
Thanks for all your opinions and critiques everyone, they are greatly appreciated. Hopefully, I’ll get a chance to let our drive team test out using this, and see what they like. Wether or not they do use it, I really just had fun trying to make it work, and getting a little practice coding.