![]() |
reprogram during a competition
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 |
Re: reprogram during a competition
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. |
Re: reprogram during a competition
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:
Code:
int c;Code:
a+=b; |
Re: reprogram during a competition
Quote:
Our driver code is both complex and long, and we go over it hours at a time trying to make it shorter, and it’s still huge. We use sensors to measure rotation and two direction acceleration, and make changes to the motor outputs based on where the robot is and where the operator wants the robot to be. And all of the arm controls, limits, etc take up space too. The memory on the RC is limited to start with (a couple of KB). It doesn’t help that the chip was designed to run assembly and we compile C++ to it… C is a complicated high level language that uses lots of libraries that take space. Then IFs “default” code is a beast (its got to be compatible with every team), but you cant ditch it because they wont give you total control over the RC (it’s a boot loader, ugg). And some of our programming team members write crummy code. All and all, memory is precious, and the more the better. I hope this answers your question, jsd Quote:
Quote:
Quote:
Thanks though – jsd |
Re: reprogram during a competition
I believe your effort would be much better spent optimizing your code to make it smaller as others suggested. There is a lot you can legally and safely strip out of the default code. Additionally, once you have your code debugged and in a stable stage, you can start rewriting stuff to sacrifice manageability and "good" programming practice for smaller size.
BTW, we are programming in C, not C++ and every robots code that I have seen uses very few extra libraries. |
Re: reprogram during a competition
Quote:
Look at the Additional Parts flowchart in section 5 of the manual to determine if this device is legal or not. If you don't get a satisfactory answer, try the FIRST Q&A. One more note on the practicality of this: maybe our programming computer is different from yours (1.8GHz seems like enough), but it takes a bit longer than 1.5 seconds for me to send code to the RC with IFI Loader. |
Re: reprogram during a competition
Quote:
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). :confused: plz tell me if im horribly wrong or something... thanks, ~Stephanie |
Re: reprogram during a competition
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. |
Re: reprogram during a competition
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?
|
Re: reprogram during a competition
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, |
Re: reprogram during a competition
Quote:
|
Re: reprogram during a competition
Quote:
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. |
Re: reprogram during a competition
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
You have gotten rid of the IFI printf code, right? |
Re: reprogram during a competition
Quote:
Quote:
Quote:
|
Re: reprogram during a competition
im sorry if you misunderstood my question. i was wondering if reprograming the robot was legal durring the compitition.
Quote:
Quote:
Quote:
Quote:
Quote:
Im not a "newbie" programmer, ive have been the head of our programming team since my freshman year. I have taken collage level CS in JAVA and C, as well as many, many courses on programming in just about every other modern high level language. However, i have been doing this for a relatively short period of time -- there are people that are much better at this then i will ever be, and many of them participate in FIRST. i never pretend to know everything, so i respect everyone on the forums, and assume they know more then me, and in turn I hope they respect me also i try very hard to keep delphi threads to the point... but stuff like Quote:
external processing is what our team has planned thus far. and i will be sure to try Marks optimization process... i wasnt looking for a lecture on how to optimize code (read the thread title!) i was looking for the legal implications of reprogramming the robot during a match. Thanks anyway – jsd |
Re: reprogram during a competition
Quote:
Fortunately, I have something of a knack for efficient implementations. :] |
Re: reprogram during a competition
Quote:
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. |
Re: reprogram during a competition
Quote:
Quote:
|
Re: reprogram during a competition
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. |
Re: reprogram during a competition
thanks for the answer
as for Quote:
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 |
Re: reprogram during a competition
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. |
Re: reprogram during a competition
"<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. |
Re: reprogram during a competition
Quote:
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. |
| All times are GMT -5. The time now is 14:09. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi