[FTC]: FTC Software Requirements

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

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

[Dave Flowerday]

Originally Posted by Dave Scheck

FRC controllers come without code, so downloads are required, and a standard interface is used.

If I'm not mistaken, the FRC robot controllers come equipped with a copy of the default code (same code available on IFI's site). The percentage of teams who choose not to use the default code in FRC is probably much higher than FTC though.

[charrisTTI]

Regarding re-entry into autonomous mode - low battery voltage can cause th e robot to re-enter autonomous mode.
1) Motors pull enough current to reduce the voltage below that required to run the processor.
2) Processor stops running
3) Motors turn off
4) Voltage goes up and processor reboots (into autonomous as if match were starting again)
5) Cycle repeats

[charrisTTI]

At the Virginia FTC Tournament our robots were initially failed at software inspection (we were ultimately allowed to compete, but only after a match was missed by one of our teams)
Our robots (teams 226 and 369) programmed with MPLAB were using the correct version of master code and software libraries for FTC competitions. The software had performed flawlessly on a regulation competition field at the Battlefield scrimmage two weeks earlier. After reviewing the documentation since returning home it is clear that our robots were being inspected according to the criteria specified on page 7 of “Appendix 2 – Programming Information” available from the FIRST web site. The information on page 7 applies only to robots programmed using EasyC. If you look at the table of contents; pages 3-7 apply to EasyC V 2, page 8 applies to EasyC Pro, and page 9 to MPLAB. The first repeat of the master code version, the message “Autonomous(20)”, the repeat of the master code version again, and the message “OperatorControl(254)” shown on page 7 are only displayed when running a robot programmed with EasyC. These were the messages which I was told were not correctly appearing when our robot was powered up. When using MPLAB these messages do not appear. In addition, Interrupt Jumper 6 must be INSTALLED to enable autonomous when using MPLAB. With EasyC installing Interrrupt Jumper 6 disables autonomous. The software inspection procedure needs to be fixed.

[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