Can we assume that the p1_y and p1_x values will not change during autonomous mode?
If so, can we also use the change in those values to determine the end of autonomous mode?
Thanks in advance,
All the inputs from the player control side will be 127 (for analog) and 0 (for digital). Analog & digital inputs from sensors on the robot will have the correct value.
A better way to check the auton_mode bit. You can find more info in the Programming_Reference_Guide.pdf document on the IFI site, or look at some posts in other threads. I remember rbayer gave a good code snippet to use.
Mike
You can check the auton_mode bit, but I think in my code, I will have the robot continue in autonomous mode until it receives input form the OI. That way, if the robot is doing fine by itself, the driver can let it continue on its own for a while longer. As soon as the driver needs/wants to take control, s/he just has to grab the joysticks.
That was the route I was planning to take.
In effect, the robot will be in “win” mode and will continue to play the game for the lazy drivers until they take over.
That’s a lot cooler if the robot can react with the enviroment, like the movement of the boxes.
I like auton_mode better,
' auton_mode VAR PB_mode.bit6
' PB_MODE = the first bit in the second byte on initialization
'Note: its a byte, but on initialization its the first BIT to turn on/off
'+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
' Manipulation
'+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
if auton_mode <> ON then skipcontrol
gosub sub_automation
skipcontrol:
if auton_mode <> OFF then skipautomation
gosub sub_setRelays
gosub sub_tankDrive
' gosub sub_balance 'balances the robot uses sensor3
'eduRobot with yaw rate sensor + 2 servos
skipautomation:
This is cut from our program (Team 691)
I wouldn’t recomend having it break auto mode based on when the joysticks change. As we all know, those pesky trim knobs tend to get bumped every now and then, so some other value may end up becoming the “centered”.
What you can do:
Have a switch on your Button Box that you can flip to break out of auto mode, or use one of the buttons on your joystick.
*Originally posted by rbayer *
**I wouldn’t recomend having it break auto mode based on when the joysticks change. As we all know, those pesky trim knobs tend to get bumped every now and then, so some other value may end up becoming the “centered”.
**
Also, If a driver happens to bump a joystick, it would jump out of autonomous mode, and the robot would just have to sit there for the rest of the period.
-Damian Manda
If a driver does bump a joystick during the autonomous period, the value wont be transmitted to the RC. So bumping the joystick during the autonomous mode wont have any effect, while hitting it afterwards would place the robot into driver-mode. If the driver decides not to hit the joystick, then the bot will continue autonomously.
rbayer, I was also considering that approach, as it is much safer.
It shouldn’t be hard for the program to determine if the joystick was moved vs having the trim offset. The first time through the code after the autonomous mode is switched off simply save the input to a variable and check to see if the input matches the stored variable each successive time through the loop. If it is different then the joystick was moved. Also you might want to only allow for the initial variable to be in a certain range(like 120-134) that way if the driver has the joysticks moved before autonomous mode is turned off the program knows it isn’t just a trim value. As far as accidentle bumps go, you could easily program a button to send it back into autonomous mode.
would epoxy the jostic trim tabs a bad idea?
Is it allowed because I read in the manual that using any sort of chemical tampering with the joystix is illegal?
We just cover ours in electrical tape. Works well enough, and non-permanent.
I would probably write the program so that only a significant joystick event dropped the robot out of autonomous mode. That is, the joystick would have to break a predetermined threshold (maybe something like +/- 50). That way, a minor bump would be ignored, but when the driver urgently grabbed the controls, the robot would understand. Of course, any other input from the OI(buttons, pots, etc) would also break the autonomous mode. Basically, I want the driver to be able to take over immediately should something go haywire after the 15 seconds. If the robot suddenly veered toward a wall at full speed, the driver could grab the joysticks and save the robot without having to think about pressing a button.
exactly, the driver will not go for a button. He will intuitively grab the joysticks…
I find this thread very interesting. I, too, have already wrestled with this problem, and I came up with all the solutions that have been suggested, but the one I decided upon is the one you all seem to be leaning away from: a button. It would be a non-momentary (is there a word for the opposite of momentary?) switch and the program would map the switch value to the auton_mode bit in the program. All it takes is a quick flip of the switch, and the robot will pop out of auton mode. I believe the concerns about the drivers’ instincts being to reach for the joysticks are valid, but any sufficiently practiced driver (not to mention anyone that plays computer games) will have an easy time learning to push the button, just like they can fairly easily adapt to the way the robot handles when it’s driving towards you.
*Originally posted by Ryan Meador *
**…sufficiently practiced driver… **
There’s the problem 
As for non-momentary… I think the word “toggle” might fit your needs.
very true, an experienced driver will learn to press the button. I feel that my duty as a programmer is to make the robot as user friendly and easy to drive as possible. Perhaps find a happy medium, use both buttons and joystick movement? or better yet, make any operator input snap the robot out of auton_mode
What about the simple solution?
Having the driver pass retina, blood, urine, fingerprint and password-protected tests before allowing the joysticks to control the robot?
(Wink, Wink) 
That might be a good idea having a button to snap the robot out of auton mode. Well, if the robot is doing good by itself, the question comes to mind: why should the driver drive?
- Ryan
How is the auton_mode bit set? does the RC set it to 1 when the OI is off or no radio signal… (due to power cut for autonomous play) or is it get sent from the OI some how…or perhaps is it something else, i mean how does the competition control it? Anyone know this yet? I havn’t been able to find it anywhere.
Thanks.
*Originally posted by Morgan Jones *
**I think in my code, I will have the robot continue in autonomous mode until it receives input form the OI. That way, if the robot is doing fine by itself, the driver can let it continue on its own for a while longer. As soon as the driver needs/wants to take control, s/he just has to grab the joysticks. **
Why do this? Won’t a human driver invariably be better than a autonomous one in? It’s not like you need to be calculating re-entry trajectories or something that actually requires computer calculation. I can’t see a circumstance where having the robot continue autonomously will be better than having the driver do his/her thing. Englighten me.