You guys are right, I just put 255 there by force of habit, an arbitrary full forward number. Also, I did not nest my serin/serout loop inside mainloop, it was completely outside of it, perhaps at the end of the program. You have a structure like this:

mainloop:
serin
code
if autoswitch = true then autoloop
serout
goto mainloop

autoloop:
serin
code
if autoswitch = false then mainloop
serout
goto autoloop

This assumes you have some condition to check if autonomous mode is active, arbitrarily called autoswitch. This is not correct pbasic syntax, just sketch code to illustrate my point.

Another way to avoid a "dead reckoning" robot would be two count wheel rotations. However, this can be a little tricky. Two years ago in my team's auto bridge balancing experiments, we tried this idea. What we did was stick magnets every x degrees around our wheel, and put a reed switch on the frame next to it. We found that this did not give us a good enough "resolution" to balance the bridge, but it may be accurate enough to do something as brutish as knock a bunch of boxes onto your side of the field.

If the two SERIN/SEROUT commands are identical, which they should be, you are trading off your personal style for processor resources. Its probably a small amount of downloaded code, but you are repeating commands that could be accessed by branching. You could accomplish the same thing using:

mainloop:

SERIN ...

if autoswitch = 1 then autoloop
'insert operator code here
goto loop_complete

autoloop:
'insert autonomous code here

loop_complete:

SEROUT ...

goto mainloop

<EDITED>
One additional remark. In the code snippet quoted above, a state transition would cause a double SERIN read without a SEROUT. In either loop you would grab the inputs, do some stuff, check the mode, then switch to the other loop without performing the output step. I don't know whether that will cause the chip to reset of not, but if you've done it then it would be fine.

From the programming guide, it looks like the input/output uPs will reset the controller if they have to wait more than 5 cycles (5 x 26.2 ms). So, as long as the longest path is less than that, it should be ok.
</EDITED>

On the other hand, you're version is doing several extra operations that Skabana's did not. In any case, I don't think it really makes a big enough difference either way in terms of performance. It comes down to personal style. Personally I think Skabana's version is more tidy.

Why so complex? I think there could be a much easier way to do this.

A few quick notes
1)autonomy mode doesn't need a serin.. that just checks the OI wich will be set to 127 or 0 for pwms and relays respectivly.
2)most of your program doesn't need to be repeated in both sections. Things like pump delays, drive algorithms, and sensor readings can all be done outside of the autonomy loop where they will take effect in either case.
*drive algorithms were included because you can direct control the pwm, rather than adjusting the joystick input variables.
3)The only thing you really need to be able to do in the automated section is read sensors and move wheels for most cases.
So you get a code that is much simpler:

mainloop

manual program

if autoswitch = 0 then noauto
drive (move)
look (sensors)
noauto

overriding stuff (takes precedent in both automatic and manual program because it has the last chance to edit any output)

serout

goto mainloop

Are you sure? The docs from InnovationFIRST say specifically that missing 5 Serins in a row will cause the RC to reset. Not a good thing.

i missed that
 

i missd that section, thanks for the info...

however, if you look at the code I put up you'll see that it still gets the regular serin at the beginning of the code. The autonomy is nothing more than an if statement with more embedded if's.

Also, the SERIN is where you get your data from your robot's onboard sensors...so if you're using any sort of sensor input during autonomous mode, you would have to run SERIN...

Not only that, but the serin is where you get the auton_mode variable. Without the serin, you wouldn't know when the autonomous phase was over.

Re-Initializing
 

I've never played with this, and it's never been needed, but can the Master uP be initialized more than once without reseting the robot controller? This may help save a few precious bytes that are no longer needed after auton_mode is over. Also, does anyone know the purpose of user_display_mode?

This is code i wrote for the edurobot to follow a line with two optical sensors, that are supposed to initially straddle the line. When a sensor detects the line, it will reposition the robot to straddle the line.

*note, there are some previously declared variables in here like drive_r and drive_l. These are the motor values. Also, the time it runs is adjustable through the 'last_iter' variable. If you still don't get it, consider it more or less pseudocode*


autonomous:

foo VAR word
low_val CON 0
hi_val CON 254
correction_count CON 2
total_iters VAR word
last_iter CON 20
keep_truckin:

drive_R = hi_val
drive_L = hi_val




if left_sensor = 0 then lefts_fine

for foo = 0 to correction_count
drive_L = low_val
drive_R = hi_val
next
lefts_fine:



if right_sensor = 0 then rights_fine

for foo = 0 to correction_count
drive_L = hi_val
drive_R = low_val
next

rights_fine:

if total_iters < last_iter then keep_truckin

goto MainLoop

Good idea, but it isn't going to work as I think you are planning. The for/next loops really serve no purpose as motor speeds won't change until you do a SEROUT. You can always just copy and paste your serout from the bottom of your code to the necessary places (immediately before every NEXT), but it would be much slicker if you could find a way to do it that doesn't require multiple SEROUTS.

On the other hand, this code will follow a line. It just has some extra overhead.

That looks like it'd work, but are you missing a total_iters=total_iters+1 line in there somewhere?


Anyway, I had a question about autonomous mode, and I hope you guys would be able to answer it...

The default code says this:
"' 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)."

Is there any other way to get it to think it's in autonomous mode (i.e. automatically setting all inputs to 0 (or 127) and making the LED blink)?

I realize that a switch input can set the auton_mode variable, but how do you get to the "built-in" autonomous mode?!

The for/next loops are there so time will pass while the robot is moving/changing direction. I had this thoroughly commented, but the coments wouldn't fit in this text box with out making the code ugly.


i was in a hurry, and the caffiene was wearing off :).

You're definately going to have to explain that one to me. Unless you put a Serout inside your loops, motor values are never going to change.
Also,
if total_iters < last_iter then keep_truckin
will go through your loop 20 times, right? However, until you do a SERIN, you won't get any new data and your code will always follow the same execution path.

This is just a guess, but you could probably delete everything except

And it would still work exactly as you expect.

[edit]Oops. I meant to leave the goto MainLoop in there. It won't do much otherwise :D[/edit]

Um... I posted the code for a kind of idea of how to follow a line, i know i missed a lot of details so umm.... yeah. You get the general idea though, right?