reprogram during a competition

[jacob_dilles]

At the risk of poking at a delicate subject – could the robot legally reprogram itself during a competition?

With a normal match the UI and the RC are in constant communication, but until the 15 sec autonomous mode is up, none of the joystick inputs (read – any input that operators can control) are active. As we have covered in other threads, a switch set before the match started could be detected by the robot before the controls were nulled. However it is blatantly wrong to have the robot be reprogram itself based on, say, at the location of the vision tetras: although theoretically possible with a 16F84, a flash card, and some clever coding and a 6 way switch.

My question pertains to reprogramming of the robot, by the robot, at the end of the 15 second autonomous period. My team has had problems with limited memory of the PIC, and with camera tracking and accelerometer algorithms we are close to the maximum size, without any of the operator-assist code.

Consider this example: When the 15 seconds of self control time is up, the autonomous flag is cleared; the RC pulls a digital output high. A carefully programmed microcontroller would emulate the serial port of a PC, putting the RC into boot loader mode and handing it the second set of code from an external EEPROM or “flash drive”. After the 1.5 or so seconds that the process takes, the robot is reset with its new code and on its way for the 2 minutes of user control.

anyone have any comments? does this violates any FIRST rules?
Thanks – jsd

[Kyle]

I am not a programmer but could you explain why you would need to do that after Auto mode is over the robot is in driver mode and the only programing that you would need is what is need to run from the controller to the robot, right?


Just remember that i am not a programmer, I would just like to know why that would be needed. so please be nice if I sound really dumb.

[jgannon]

I would suggest a much simpler way of achieving the same results: optimize your code. It's free, and much less likely to malfunction. I truely doubt that you actually are going to run out of memory, but if you do, come up with creative ways of doing things. Use fewer variables. For example, if you were trying to swap two variables, instead of doing:

int c;
c=a;
a=b;
b=c;

...do:

a+=b;
b=a-b;
a-=b;

The first law of programming is that there are always ways of doing things quicker and in less space than you already are. (The ternary operator will be your friend in this pursuit.) Everyone is going to face the same problems that you are, and I doubt that anyone is going to absolutely need one of these devices. Good luck.

[RbtGal1351]

Originally Posted by jgannon

I would suggest a much simpler way of achieving the same results: optimize your code. It's free, and much less likely to malfunction. I truely doubt that you actually are going to run out of memory, but if you do, come up with creative ways of doing things. Use fewer variables. For example, if you were trying to swap two variables, instead of doing:

int c;
c=a;
a=b;
b=c;

...do:

a+=b;
b=a-b;
a-=b;

The first law of programming is that there are always ways of doing things quicker and in less space than you already are. (The ternary operator will be your friend in this pursuit.) Everyone is going to face the same problems that you are, and I doubt that anyone is going to absolutely need one of these devices. Good luck.

Ok now please bear with me, im a rookie programmer, but why would the above example save any memory space on the actual robot controller? when you build it, it just makes it assembly language (the .hex file), and both those (above) are the same. thats the whole goal.

in order to save memory, my team is using #define s for as much as possible, so when you compile/build it, as much as possible is already done. also, the same for some of the autonomous calculations--look up tables are faster and smaller than calculating something. (especially for trig functions, which you might need for autonomous--distance).

plz tell me if im horribly wrong or something...
thanks,
~Stephanie

[ericand]

If you need a sufficiently small number of values, table lookup will
save space. It just depends on how many you need. In the general
case, an algorithm will save space and table lookup will optimize for speed.

The use of #define will not necessarily save space (except in your
source files, where you don't care). It depends on how you are doing things.
To save space with constants, you want every reference to the value of the
constant to be to the same memory location. If you just use the define, you
will be storing the constant value everywhere it is used.

[russell]

I might be totally missing something, but like jgannon says it takes (me at least) way more than 1.5 seconds to download a program to the RC. More like 1.5 minutes. And why dont you simply do the processing on something else (how much does a 386 cost?) and just use the RC for I/O?

[Mike Betts]

Jacob,

At the risk of sounding condescending, I can't believe that anyone is running out of space. If so, take a good hard look at what you are doing.

Programming an embedded system is absolutely nothing like programming a PC.

First rule: Never, never, ever use floating point arithmetic.

Second rule: Never, ever use dynamic allocation of memory.

Third: Avoid pointer manipulations unless you understand what it does in the machine (some dereferencing manipulations are murder).

Look at the assembly code being generated by the compiler. You can see it in the .lst file that is generated when you build your project.
Good Luck,

[Alan Anderson]

Originally Posted by Mike Betts

At the risk of sounding condescending, I can't believe that anyone is running out of space. If so, take a good hard look at what you are doing.

Significant processing between operator input and motor action.
Navigation (and all the trigonometry it requires).
Multiple independently-tuned PID controls.
Adaptive autonomy.

Finally, lots and lots of text for communicating with the camera.

I can easily understand someone running out of space. Last year's robot only did about half of what we have planned for this year, and it's using about 65 percent of the space.

[Mark McLeod]

I have to agree with Alan that if you try to dump everything possible this year into the program it can grow large.
Maybe not what you are looking for, but have you tried using the built-in compiler optimization to reduce your program bulk?

In MPLAB

• Project -> Build Options... -> Project
• MPLAB C18 tab
• pulldown categories and select Optimization
• click "enable all"

I tend not to use the compiler optimization unless necessary, because we've all had problems with optmizers in the past. Just test afterwards to make sure everything is working properly.

You have gotten rid of the IFI printf code, right?

[Alan Anderson]

Originally Posted by Mark McLeod

Maybe not what you are looking for, but have you tried using the built-in compiler optimization to reduce your program bulk?

With all the text strings and all the interrupts and associated volatile variables floating around in this year's code, I wouldn't expect a whole lot of extra optimization. It's my guess that most "reduced bulk" will still have to come from effective algorithms and efficient implementations rather than compiler tricks.

Fortunately, I have something of a knack for efficient implementations.

[Mark McLeod]

Originally Posted by Alan Anderson

With all the text strings and all the interrupts and associated volatile variables floating around in this year's code, I wouldn't expect a whole lot of extra optimization.

Made me look.

The default FRC 2.4 version of the code comes in at 18,927 bytes or 55%.
Optimizing gets you down to 14,743 bytes or 43%

Sorry for the thread hijack Jacob. Us old folks tend to ramble on sometimes.

I don't know of any rule that prohibits the downloading of new code as long as it's occurring within the custom circuit rules, and I can't think of any harm that might do from a safety or IFI control perspective.

P.S. My wife was a warhawk. Just had a reunion in Vienna this past summer.

[Mike Soukup]

Originally Posted by Mike Betts

Third: Avoid pointer manipulations unless you understand what it does in the machine (some dereferencing manipulations are murder).

Can you explain this one a little more? I'm used to UNIX programming where I never have to worry about this being a problem, so we used pointers quite a bit last year and plan on the same this year.

Originally Posted by Ryan Foley

He brings up a very good point. I believe that in 2003 the Wildstang 111 robot had a Motorola processor on it to do all of the calculations and processing, and the RC itself would be used for only a little bit of the program and the I/O. Go to the Wildstang website and click on "Stang PS" for a bit more information.

You've very close. In 2003 & 2004 the Custom Circuit kept track of our position on the field and every loop of autonomous the RC would ask the CC for the robot's position & heading. Then the RC would determine the path to get to the target, do the driving & arm moving, and recognize when we got to our target. The presentation on our site doesn't show the interface between the RC & CC. For this year we're planning to offload almost all of the positioning & guidance to the CC and have the RC focus on determining what to do based on the strategy, and vision tetra positions.

[russell]

How do you guys connect the RC and the CC? If you used the ttl port then you are going to have to (actually you probably already did) find a way to hook two things to it at once assuming you are using the camera.

Back on topic however, It seems to be legal to reprogram in a match, but you might have a lot of explaining to do. The thing that will worry the judges the most is the possibility of you screwing with their master code. I would stay away from it for this reason, not to mention all of the reasons already mentioned. You are asking for trouble with both the technical and "legal" aspects of it, when it seems like you could accomplish something the same or better more easily, without the concerns over the rules. Thats just what I think.

[jacob_dilles]

thanks for the answer

as for

Originally Posted by russell

How do you guys connect the RC and the CC? If you used the ttl port then you are going to have to (actually you probably already did) find a way to hook two things to it at once assuming you are using the camera.

serial communication is over digital IO lines. you can copy IFIs buffers, or write your own. you end up with 16 some odd serial ports (of course, you need to make your own connectors)

the chip by itself runs TTL levels (+5v) for the signal. with serial comunication, most things will cope just fine with +5, (rs232 spec goes to +15v, but we would use +12v), but some things are just pickey. so if you want to be "fully" compatable with all devices, your going to need a RS232 converter chip. any electrionics provider will sell them... you can get 4 converters in one IC for a buck or two

[Joe Ross]

If you are going to have another processor on your robot to do the programming, why not use that processor to offload some of the work?

You also need to check with IFI. I wouldn't be suprised if the field controllers freak out while the User processor is being programmed.