autonomous code variable?
 

will a WORD variable hold more than 254? i'm at a last resort of counting loops for our autonomous code so i need a counter...also if anyone has any simple autonomous code that works and would like to share, i just need to see how you worked it into the main code and detecting if auton_mode = 1
and all that jazz...
Thanks,
manodrum

A word variable will hold a value up to 65535. A word variable is 16 bits long which is twice the length of a byte.


Steve

Re: autonomous code variable?
 

Hi,

Here is some of our code.

(Warning: I am not one of the programmers.)

We have multi-bank code. See Innovation FIRST site for an explanation and example.

We have our autonomous code in bank 2.

Below is how we jump to bank 1 where our driver controlled code is, when autonomous is over.


'---------- Aliases for the Pbasic Mode Byte (PB_mode) -------------------------------
'----------------------------------------------------------------------------------------------
' Bit 7 of the PB_mode byte (aliased as comp_mode below) indicates the status
' of the Competition Control, either Enabled or Disabled. This indicates the
' starting and stopping of rounds at the competitions.
' Comp_mode is indicated by a solid "Disabled" LED on the Operator Interface.
' Comp_mode = 1 for Enabled, 0 for Disabled.
'
' Bit 6 of the PB_mode byte (aliased as auton_mode below) indicates the status
' of the Autonomous Mode, either Autonomous or Normal. This indicates when
' the robot must run on its own programming. When in Autonomous Mode, all
' OI analog inputs are set to 127 and all OI switch inputs are set to 0 (zero).
' Auton_mode is indicated by a blinking "Disabled" LED on the Operator Interface.
' Auton_mode = 1 for Autonomous, 0 for Normal.
'
' Autonomous Mode can be turned ON by setting the RC to Team 0 (zero).
'
' Bit 5 of the PB_mode byte (aliased as user_display_mode below) indicates when
' the user selects the "User Mode" on the OI. PB_mode.bit5 is set to 1 in "User Mode".
' When the user selects channel, team number, or voltage, PB_mode.bit5 is set to 0
' When in "User Mode", the eight Robot Feedback LED are turned OFF.
' Note: "User Mode" is identified by the letter u in the left digit (for 4 digit OI's)
' Note: "User Mode" is identified by decimal places on the right two digits (for 3 digit OI's)

comp_mode VAR PB_mode.bit7
auton_mode VAR PB_mode.bit6
user_display_mode VAR PB_mode.bit5


'After our autonomous routine, we wait for autonomous to end.

WaitQuitAutonomous:

do
Gosub SerialInput

' Quit autonomous mode when it's time

Gosub TestQuitAutonomous

Gosub SerialOutput
loop


TestQuitAutonomous:

' (Test if its time to run the main loop (competition code)

if auton_mode = 0 then Run 1 ' (If autonomous is turned off, we jump to bank 1 and run the driver controlled program)
if AutonomousSwitch = 0 then Run 1 ' (We have a switch on our robot which allows us to turn off autonomous mode)

' Keep going in autonomous mode
Return

Hope that helps.

Re: autonomous code sample?
 

This is probably a lot more than you wanted to know, but here are excerpts which provide a a pretty good idea of how our autonomous mode is implemented:

Slot 0 pretty much just contains the normal pre-main-loop initialization stuff.

Slot 1 (BB2003MainLoop):
And later in slot 1:
And a little later in slot 1:
Slot 2 contains nothing having to do with auto mode except this... just before it would normally call the "output data" slot:
Slot 3 (BB2003_OUTPUT_DATA) contains the serout... and this... which controls the digital display on the operator interface when it is in user display mode:
Note the strange {$...} syntax. These are directives to my BASIC Stamp Preporcessor which translates these to legal PBASIC 2.0 statements. My preprocessor is still a work in progress. An earlier version is available in the White papers section. I don't know whether all the code I'm quoting here will work with that version. You shouldn't have difficulty modding this code to work with either of the currently available BASIC Stamp Editors, but if you're really a "bleeding edge" type, I'll let you have a copy of the current program.

continued...

autonomous code sample? (part 2)
 

Slot 4 (BB2003_AUTON_PROG1) contains the first several of our autonomous programs: (BTW, BB2003Include.bsppi is an include file -- which defines all our shared variables, and gets included in all our programs.)
Slot 5 (BB2003_AUTON_PROG2) contains some more autonomous programs:
Slots 6 and 7 (BB2003_PLAYBACK6 and BB2003_PLAYBACK7) are identical, and are used to record 15 seconds worth of driver control to EEPROM for later playback in autonomous mode:

BB2003Playback.bsppi which gets inserted into both slots 6 and 7, contains all the logic to both save and replay the operator commands:

If you are doing autonomous for the first time you might want to just add some simple movements to your regular Main program.

Helping other teams at regionals I've found they understand the concepts more easily and get up and running faster if you simply add the autonomous as an override of the regular user controls. You only need to expand into multi-bank code if you need more space. We use an autonomous meta or scripting language, so a sample of our code would be counter productive if you're new to this.

The example below is for a single joystick than does 3 moves. Add or subtract moves to fit your need. The code is in the old 1.33 style in case you're modifying last years robot code.


'----------Put these in your declaration section
'These are the # of program loops that completes the movement
FIRST_LEG CON 40 '~ 1 second assuming delta_t=0
SECOND_LEG CON 200 '~5.2 seconds
THIRD_LEG CON 250 '~6.5 seconds
'The last leg you define here should not be > 577 (15 sec.)

auto_counter VAR WORD

'------------Put this before your main loop
auto_counter = 0

'-----------Put this immediately after your Serin command
' We are just overriding the joystick values as if the driver were moving the joystick

IF auto_mode = 0 then NoAuto
auto_counter = auto_counter + 1
'Can also do: auto_counter = auto_counter + 1 + delta_t

If auto_counter >= FIRST_LEG then LEG2
'These values should be what your driver would normally do with the joystick to accomplish what you want to do
p1_x = 254
p1_y = 0
Goto NoAuto

LEG2:
If auto_counter >= SECOND_LEG then LEG3
p1_x = 254
p1_y = 0
Goto NoAuto

LEG3:
If auto_counter >= THIRD_LEG then NoAuto
'Make sure you come to a stop as the last LEG
p1_x = 127
p1_y = 127
Goto NoAuto

NoAuto:

'------------The rest of your regular code

(BTW: This was indented for readability when I typed it in)

Mark,

To preserve indentation, put your code inside {code}...{/code} vBcode tags. (Replace the curly braces with square brackets.)

Here's your code with them:

Thank you for the code. I think that's a very clear and workable way to get people started with autonomous. I will pass that on at our regional.

Question: How does one use a "meta or scripting language" with Pbasic?

Thanks for the proper vb tags Greg. I went and read up on the vb Code help after you pointed that out.

Doug,

Here's an example of what one of our autonomous program scripts looks like. We don't recode as in my beginners example above, but we change the script instead. It makes it simpler to change the autonomous movements quickly with less risk of introducing coding errors. We have a graphical interface where you drag and click the cursor on an image of the playing field where you want the robot to go and the script gets generated automatically. When each command is executed a subroutine specific to that command does the proper setup and it gets submitted to a master control routine.

The basic command format is: COMMAND, SPEED, DISTANCE
These values are defined constants. Other commands have some variation on the arguments, for instance, some commands have "on/off" arguments and the arm commands are really POT readings.

The commands are stored in EEPROM by the DATA statement and READ in sequence like a script.

Wow! Thanks for the info. Very cool.

Did your team create the graphical interface?

If so, what language did you use?

(My son worked on a robot at JPL, called "Urbie", short for "Urban Robot". It was a backpackable robot and with a graphical interface that allowed them to outline a door and the robot would head for it. If something got in the way, Urbie would keep going, avoiding obstacles, while it looked for the "door".)

Hi Doug,

One of our student programmers wrote the graphical interface in a couple of hours using Visual Basic 6. VB is great for knocking off graphical interfaces quickly. He used the image of the playing field published by FIRST as the background and simply made each pixel represent one inch of distance. You have to account for the extra distance over the slope of the ramp though.

One of the nice things about doing it this way is how small the program actually ends up being. Our basic autonomous program takes up 50% of a program slot.

Sounds like your son has valuable robot navigation experience to bring to your team. An obstacle course might be fun for a FIRST game.

That is very impressive, especially the fact that one of your students wrote the interface in such a short time. Sounds like we should have some students learning VB.

Thanks again for the info, and also for the code for beginners in autonomous. Hey, even I can understand it. This week, Team 696 is sponsoring a programming workshop at the S. Calif. Regional. I will have your code there. :-)