reprogram during a competition

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

[Vashts6583]

"<R14> Prior to the competitions: After the close of the "FIX-IT WINDOW"and prior to the competition, the team must put down their tools, cease fabrication of robot parts, and cease all software development. Take this opportunity to rest, recover from the build season, and relax. Teams may scout other teams, gather and exchage information, develop game-playing strategies, collect raw materials, prepare tool kits, plan how to make repairs, etc. in preparation for the upcoming competitions. But no construction or fabrication is allowed."

I take this to mean that you cannot create unexisting code, but you can tweak existing code to make it function properly.

Also, <R16> states: "The purpose of this Rule is to allow teams to make critical repairs to existing parts to enable them to compete in following events." Also, the total weight of Repair parts cannot excede 25lbs.

First of all, critical repairs can mean non-wroking coding that you did not have the time to fix. Second, existing parts includes the code since the code is a part of the robot, else it would not work. Third, total weight<25lbs. A floppy disc with the correct code weighs alot less than 1 lb., and the code can be uploaded easily, as long as someone brings along a laptop or some other method of moving code onto the robot.

All in all, I believe that tweaking code after the "FIX-IT WINDOW" is allowed, just as long as it tweaks already existing code on the robot. However, this is not an official ruling, just a rookie's opinion.

[Astronouth7303]

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.

I ran out of space with just the default code with the scripting and camera code early in the season. There were virtually no modifications to the code except to put the 2 together, which was extremely little.

The way I solved this was to just enable more obtimizations. If you do advanced debuging, read the compiler manual first. A few of them change break points, which I presume apply to the simulator, too.