[FTC]: FTC Software Requirements

[Al Skierkiewicz]

Everyone,
You may have received a message that you need to upgrade software for the FTC Challenge. I want to reiterate that current FTC rules require that you have version 7 of the Master Code loaded on your robot controller. This is the final item on the FTC 2007 Inspection List. If you are competing in an upcoming event, please be sure to upgrade as soon as possible. This upgrade is not a trivial matter and requires some additional work on your part following the upgrade.
At the Chicago Regional, over the weekend, most of the delay in inspecting was due to the need to upgrade the software. Don't be a team that misses a match because you needed to do a critical software upgrade.
Good Luck and have fun!

[Richard Wallace]

Many teams experienced the same difficulty at the Missouri FTC Championship Tournament last week in St. Louis. The delays that this created were no fun for the teams involved, or for the event staff.

Having incorrect master code in your robot will not only cause it to fail the final inspection checklist item. It will prevent your robot from behaving correctly when its controller is connected to the FTC field control system.

[Jessica Boucher]

If you're wondering "How do I find the master code?" in easyC, here's how:

1. Connect your robot to the computer using the Programming Cable. The USB end goes to the PC, the phone-connector end goes into the robot controller port labeled "Serial". Turn on the robot.
2. Go to the "Build & Download" menu and select "Terminal Window". (Note: at this time a window may pop up reminding you to download the master code. This will pop up whether or not you have downloaded it. You have the option to turn the reminder off, but click "Close" to continue.)
3. The "IFI/Intelitek Loader" window should pop up. Go to the "Options" menu and select "Download Master Code". A box will come up asking you if you really want to download the master code. Click yes!
4. An open box will appear. Double-click on the "Vex" folder, and then double-click on the file "VEX_MASTER_V7_4EASYC.BIN". It should be the only file in the folder.
5. The open window will close and the download bar should appear. When it is complete, the terminal window should reappear, with a prompt to download your user code.
6. Download your user code. You're done!

If you are receiving connection errors, please refer to the help file (search for "COM Port"). If you have any other questions, please feel free to contact intelitek via phone, email (support@intelitek.com) or post on ChiefDelphi.

Thanks!

[Dave Flowerday]

For organizers, keep in mind that some teams may not even own the programming kit or EasyC, and therefore will have no way of upgrading their robots before arriving at the competition.

Also be aware that flashing new master code onto the robot will erase the user program. I think we had some trouble with this in Chicago, where teams had to get their master code upgraded but then did not have a copy of their code with them to re-download.

Richard, did someone tell you that the older master code will prevent your robot from working with the field? That seems unlikely given the way the Vex robots work - I assumed the newer master code was more related to correct operation of autonomous mode.

[Richard Wallace]

Originally Posted by Dave Flowerday

Richard, did someone tell you that the older master code will prevent your robot from working with the field? That seems unlikely given the way the Vex robots work - I assumed the newer master code was more related to correct operation of autonomous mode.

Correct operation of autonomous mode is the issue. We saw a few robots with incorrect master code that entered auto mode at the wrong time; i.e., after it was over and the referees were trying to record the auto mode scores. (This happened during morning practice rounds.)

However, this disruption may have been caused by other factors such as incomplete electrical connections to the field control system, or incorrectly inserted crystals. We'll set up some tests under controlled conditions and report what we find, probably later this week.

[Dave Flowerday]

Originally Posted by Richard

Correct operation of autonomous mode is the issue. We saw a few robots with incorrect master code that entered auto mode at the wrong time; i.e., after it was over and the referees were trying to record the auto mode scores. (This happened during morning practice rounds.)

This is off-topic but it's probably a good thing for people to know. Unlike FRC, the Vex field control system does not control autonomous mode. The only thing the field controller does is turn the Vex transmitter on or off. Autonomous operation is handled entirely within the Vex RC. What they've done is set up the Vex RC so that it operates autonomously for the first 20 seconds, and then goes into driver control mode. So, if you're seeing robots go into autonomous mode when they shouldn't, you can be nearly certain that it's a problem with the robot. For instance, I believe if the Vex RC resets for any reason it will re-enter autonomous. Perhaps the robots you saw had low batteries and that was causing their robots to reset?

As I understand it, when the Vex robot is powered on, it waits until it sees a signal from the transmitter (any transmitter that is on the right frequency - the team number is not part of the signal like it is in FRC). Once it sees this signal it will begin autonomous mode, and I think it will continue until the 20 seconds is up (even if the transmitter signal goes away). Because of this, we've seen problems where the Vex robots will take off in autonomous mode even when the team's transmitter is disabled by the control system and the cause ends up being that someone else had a transmitter on the same frequency and that triggered the robot to start moving. Thus it is really important to make sure that teams are not operating wirelessly when they shouldn't be.

[GaryVoshol]

Originally Posted by Dave Flowerday

Richard, did someone tell you that the older master code will prevent your robot from working with the field? That seems unlikely given the way the Vex robots work - I assumed the newer master code was more related to correct operation of autonomous mode.

Originally Posted by Richard

Correct operation of autonomous mode is the issue. We saw a few robots with incorrect master code that entered auto mode at the wrong time; i.e., after it was over and the referees were trying to record the auto mode scores. (This happened during morning practice rounds.)

However, this disruption may have been caused by other factors such as incomplete electrical connections to the field control system, or incorrectly inserted crystals. We'll set up some tests under controlled conditions and report what we find, probably later this week.

Originally Posted by Dave Flowerday

This is off-topic but it's probably a good thing for people to know. Unlike FRC, the Vex field control system does not control autonomous mode. The only thing the field controller does is turn the Vex transmitter on or off. Autonomous operation is handled entirely within the Vex RC. What they've done is set up the Vex RC so that it operates autonomously for the first 20 seconds, and then goes into driver control mode. So, if you're seeing robots go into autonomous mode when they shouldn't, you can be nearly certain that it's a problem with the robot. For instance, I believe if the Vex RC resets for any reason it will re-enter autonomous. Perhaps the robots you saw had low batteries and that was causing their robots to reset?

As I understand it, when the Vex robot is powered on, it waits until it sees a signal from the transmitter (any transmitter that is on the right frequency - the team number is not part of the signal like it is in FRC). Once it sees this signal it will begin autonomous mode, and I think it will continue until the 20 seconds is up (even if the transmitter signal goes away). Because of this, we've seen problems where the Vex robots will take off in autonomous mode even when the team's transmitter is disabled by the control system and the cause ends up being that someone else had a transmitter on the same frequency and that triggered the robot to start moving. Thus it is really important to make sure that teams are not operating wirelessly when they shouldn't be.

This corrolates with my experience at a tournament. Two teams had problems with erratic operations, including one who specifically said it was switching into auto part way through teleoperated mode; this happened on several of their rounds. We concluded the problem had to be with their robot, as the other 15 teams had no problems. Unfortunately I have no means of finding which version of code they were running.

We did have an issue where crystals may have been the reason for erratic behavior in another match; it was replayed.

Interference from another team was unlikely, as the pits were in a different room across the hall. Is there any evidence of cell phone interference?

[Dave Scheck]

I was one of the software inspectors at the Chicago competition and have a few comments/thoughts.

This single biggest problem that we had were teams that hadn't done any programming whatsoever. These teams came to the competition with the thought that they weren't going to move in autonomous, and were going to use the default tank/arcade code to drive. This is all fine and dandy except for the fact that they didn't have the latest master code, nor did they have the latest template. Upgrading the master code wiped out the default code. As far as I could tell, there isn't "default" code available that follows the latest template. This required someone (read me) to quickly come up with simple drive code for them before they had to play in the first match.

Another problem that we faced was upgrading teams from old to new templates. The issue was that EasyC doesn't allow copy/past from one project to another (as far as I could tell). I got a tip from a team to do the following.
1. In the old templated project, create a new function (i.e. MyAutonomous, MyOperator)
2. Copy/Paste all the code needed into that function
3. Save the project as a library
4. Open the new template
5. Load the recently created library. This will add the functions in the library (MyAutonomous, MyOperator) to the User Functions section
6. Drop the user function blocks into the Autonomous and Operator blocks.
7. Save the new template as a new project.

The best advice I can pass on is to start the software inspection process early. This took way longer than expected and caused a few teams to miss a match.

If you are on an FTC team and know about software, please talk to the teams around you in the pits and make sure that they understand what needs to be done to be compliant with the rules.

[Mike Betts]

Originally Posted by GaryVoshol

...Two teams had problems with erratic operations, including one who specifically said it was switching into auto part way through teleoperated mode;...

A thought from the peanut gallery:

An intermittent power connection could cause a FTC robot to reset. I've seen a lot of students swinging their batteries by the cables. Also, I have had issues with FRC backup batteries having intermittent connections at the Molex connector.

I would check the suspect robot by gently pulling and shaking the power wires.

Mike

[Jessica Boucher]

Originally Posted by Dave Scheck

Another problem that we faced was upgrading teams from old to new templates. The issue was that EasyC doesn't allow copy/past from one project to another (as far as I could tell). I got a tip from a team to do the following.

Dave,
Copying and pasting between projects is not allowed, but you have the ability to copy your code as a user function and import it into the new project.

To do this:

1. Right click on "Autonomous", select "Copy"
2. Give it a unique name, just as you stated above. Do the same for Operator Control. Save the project.
3. Open a new template and right click on "User Functions". Select "Add Existing Function".
4. Select your file and click on the Expand icon to see your created user functions. Select one and hit "Add". Do the same for both functions.
5. Copy your code from your created functions into "Autonomous" and "Operator Control". You do not need to delete your imported functions afterwards.

[ManicMechanic]

Originally Posted by Dave Scheck

This single biggest problem that we had were teams that hadn't done any programming whatsoever. These teams came to the competition with the thought that they weren't going to move in autonomous, and were going to use the default tank/arcade code to drive. This is all fine and dandy except for the fact that they didn't have the latest master code, nor did they have the latest template. Upgrading the master code wiped out the default code.

We had also had several teams at our tournament with this problem.

Originally Posted by Dave Scheck

As far as I could tell, there isn't "default" code available that follows the latest template. This required someone (read me) to quickly come up with simple drive code for them before they had to play in the first match.

Last year, Blake created a program that fit within the 2006/2007 template. We tested it at home for the limited conditions of our robot, and it worked, but we didn't test it for various and sundry strange configurations. I'm wondering if it would be difficult to embed the program within the new template and distribute it to tournament organizers and people intending to be helpful. For teams that had had simple programming (2 - 4 motors, using the transmitter in default condition), it was easier to create a program with 1 or 2 R/C commands.

[Dave Scheck]

Originally Posted by ManicMechanic

Last year, Blake created a program that fit within the 2006/2007 template. We tested it at home for the limited conditions of our robot, and it worked, but we didn't test it for various and sundry strange configurations. I'm wondering if it would be difficult to embed the program within the new template and distribute it to tournament organizers and people intending to be helpful. For teams that had had simple programming (2 - 4 motors, using the transmitter in default condition), it was easier to create a program with 1 or 2 R/C commands.

I think that this is exactly what's needed. The code I ended up writing for teams was nothing more than a pre-made drive block that fit the style that they wanted. I don't see why a collection of these shouldn't be distributed to each competition as a safety net. Even better, the default code that comes on the controller should be available in a templated format. That way the teams don't have to change anything at their transmitter.

[gblake]

Originally Posted by Dave Scheck

I think that this is exactly what's needed. The code I ended up writing for teams was nothing more than a pre-made drive block that fit the style that they wanted. I don't see why a collection of these shouldn't be distributed to each competition as a safety net. Even better, the default code that comes on the controller should be available in a templated format. That way the teams don't have to change anything at their transmitter.

1st - What Iwrote last spring shold certainly be streamlined and otherwise improved. It worked, but it left a lot to be desired.

A better version of it would be useful as a teaching aid (allow teams to use it but not distribute the source?); but let's not forget that the students are supposed to learn how to give their machines software instructions...

Who has the right brilliant suggestion that stikes the correct balance between supporting learners and not rewarding sloth?

Blake

[rswsmay]

This happened last season and will continue to be an issue especially with new teams constantly being introduced to the FTC. The scrimmage that was held at Georgia Tech on Nov. 18th had several similar issues. I spent about 2/3rds of the entire competition inspecting robots for the correct master code and template. Despite repeated announcements to teams that they NEEDED to have this done or else things may/will not run properly, many still fielded robots without the check being done. Since this was just a scrimmage, we did not have a hard and fast rule that teams MUST pass inspection prior to competing.

During the day, my role grew from just verifying correct code to:

• Uploading the master code
• Applying the competition template
• Rewriting entire operator programs
• In some cases writing brand new autonomous routines

Many teams that did write their own code did not bring a copy with them so their program was lost when the new master code was loaded. Now obviously for the purposes of a scrimmage and to benefit the majority of brand new teams that did not even know what a competition template was, I obviously went ABCD. (That’s short for above and beyond the call of duty for those wondering). But during a competition, I can pretty much vouch for most inspectors and say that their roles will be limited to purely pass/fail with regards to robot code.

My take is that a pre-competition scrimmage is invaluable to teams if inspections are done comparable to that performed at the competition. When we have our pre-competition scrimmage in February, we plan to perform inspections just like those teams will encounter at the competition. They will get a copy of the inspection check list with things to correct. We did this last year and it worked very well, although there were still one or two teams that did not correct the deficiencies and were gigged by the inspectors at the competition.

Finally, I agree that the default code in all 3 FTC acceptable programming languages would be a great benefit if available to embed in the competition template. Even an abbreviated version could prove to be a time saver to those teams that just want to plug and go. The EasyC version would probably be the most utilized.

[Dave Scheck]

Originally Posted by 1885.Blake

A better version of it would be useful as a teaching aid (allow teams to use it but not distribute the source?); but let's not forget that the students are supposed to learn how to give their machines software instructions...

I agree, but in the case of FTC, teams are required to purchase the programming kit as opposed to FRC where it the "programming kit" is nothing more than a compiler and a standard serial cable. In both competitions there are requirements on the firmware that needs to be on the controller as well as the libraries/templates used by the software. The difference is that with FTC default code is already on the controller, so there is no need for a team using the defaults to purchase the programming kit. FRC controllers come without code, so downloads are required, and a standard interface is used.

rswmay - My experiences definitely sound similar to yours. I have been saying that had my (and the other software inspector) not been involved in FRC/FTC and were just random people off the street that the day would have turned out very differently.