Autonomous Mode Assumptions

[Goya]

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,

[Mike Soukup]

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

[Morgan Jones]

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.

[Goya]

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.

[rwaliany]

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)

[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".

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.

[Damian Manda]

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

[Goya]

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.

[nwagers]

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.

[JC Denton]

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?

[Neal Turett]

We just cover ours in electrical tape. Works well enough, and non-permanent.

[Morgan Jones]

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.

[nwagers]

exactly, the driver will not go for a button. He will intuitively grab the joysticks...

[Ryan Meador]

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.

[Morgan Jones]

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.