My auto is better than yours.. lol

[Dave Flowerday]

Originally posted by rwaliany
The reason being, the robot takes x amounts longer to load when it has more code to process.

What exactly are you talking about here? The time it takes to download the code from your laptop?

By removing and separating the programs into different files, we were able to speed up our auton from 5 seconds to 3 seconds.

Separating code into multiple files shouldn't have any effect on the time it takes your robot to drive to the top. If it does then something isn't right with the way you structured your program.

[randomperson]

I digress.

Switches can be an effective way to implement autonomous mode if you are storing your multiple autonomous programs in multiple program slots. This is how we do it:

auto_selection 	             VAR tempvar3
	auto_select           VAR auto_selection.nib0
	auto_bit1	             VAR auto_selection.bit0
	auto_bit2	             VAR auto_selection.bit1
	auto_bit3	             VAR auto_selection.bit2


if active_button = 1 then
	auto_bit1 = auto_select0
	auto_bit2 = auto_select1
	auto_bit3 = auto_select2
endif		

if auto_button = 1 OR auton_mode = 1 then 
	
	select (auto_select)
		case 0		'joy 1
			run 2
		case 1		'joy 2
			run 3
		case 2		'joy 3
			run 4
		case 3 		'joy 4
			run 5
		case 4 		'joy 5
			run 2
		case 5		'joy 6
			run 3
		case 6                     
		                run 4
		case 7
			'do nothing... just in case :-)
	endselect	

else
	gosub operator_control
endif

And really, it works quite efficently

[rwaliany]

Okay, Everytime your robot loads for the competition. IT takes time for the RC to read and interpret/tokenize the code. When I use to have four autonomous programs in the same program, it took two seconds longer to tokenize during the loading period like turning it on time.

it was structured rather similar to randomperson's

- Ryan

[Dave Flowerday]

Originally posted by rwaliany
Okay, Everytime your robot loads for the competition. IT takes time for the RC to read and interpret/tokenize the code. When I use to have four autonomous programs in the same program, it took two seconds longer to tokenize during the loading period like turning it on time.

It will take longer to tokenize on the host computer and longer time to download to the robot controller. It will not take any longer on when you power the robot on or when it's executing code.

[rwaliany]

it wont? it DID, im only arguing what happened and happens to me

[randomperson]

Yeah, what he said.

Actually, by loading all of your programs at once you save time because you don't have to recompile and re-load everything at run time.. all you have to do is flip a switch and voila, new program! No loading and crap.. lol, we didn't really use our laptop very much this weekend at all because of this

Idea: post your code so we can see

[Dave Flowerday]

Originally posted by rwaliany
it wont? it DID, im only arguing what happened and happens to me

Then like I said, there must be a bug or design defect in your code. The code on the robot controller does not 'load' like a program that you run on your home computer. Programs on a microcontroller like the BASIC Stamp are stored in FLASH and execute directly from that FLASH memory.

If you'd like to post the section of your code that was deciding which program to execute maybe we can help pinpoint the problem.

[rwaliany]

The code is identical to randomperson's pretty much word for word.

if it's a certain auton program (rc digital bits) then it runs x from the initialization program

I don't know, whatever. I'm just saying from experience, it runs faster for me using less slots and code (auton programs). I see your argument. I see the absurdity in it running slower. But I also see it happening to me.

[Mark McLeod]

Did your code seem to execute faster after you changed, or did it start executing your autonomous sooner?

Slower execution would probably have been due to debug statements left in the code. Depending on how efficient your debug statements are they will make your code start to miss program cycles after 2 or 3 of them.

Just a thought that might help.

[rwaliany]

executed auton faster

[Mark McLeod]

If you still have the old code around you might try monitoring delta_t to see if it is greater than 0 while the auto code is executing. It would be easiest to simply save the greatest value delta_t reaches during loops and then either use the OI user_display_mode or a debug statement outside the auto loop after the auto finishes (so the debug slowdown isn't an issue) to display the high value.

From your description of the symptoms it sounds like the separate slot definitely had an additional delay for some reason and the new implementation doesn't have that delay.