Program Chooser runs the wrong teleop program

[FIMTech]

I ran into an odd issue using program chooser - it doesn't appear to update the teleop program selection until after the NXT is power cycled. Using LabVIEW 2012 with the f5 patch and current FTC Competition toolkit.

Steps to reproduce:.

1. Set up a teleop program, controller 1 right Y controls right motor, left Y left motor
2. Deploy to NXT as TEST1, select as teleop program using Program Chooser
3. Test using FCS - TEST1 operates as expected
4. Set up another teleop program, controller 1 right X controls right motor, left X left motor (something completely different  from TEST1)
5. Deploy to NXT as TEST2
6. select TEST2 as teleop program using Program Chooser
7. Test using FCS, teleop still uses Y axis for motor controls (TEST1)
8. 'Details' button on FCS shows the teleop program is TEST1
9. Download FTCConfig.txt from the NXT, the teleop file is correct (TEST2)
   
10. Power cycle NXT
11. Test using FCS, teleop now runs TEST2 (X axis controls), Details shows TEST2

I also tried deleting TEST1 from the NXT after TEST2 is deployed - running teleop in FCS gives 'file not found' error until NXT is power cycled

I'm going to try a few more test cases, for now I'm advising our Michigan teams to power cycle the NXT after running Program Chooser

Brian Smith

Affiliate Partner, FIRST in Michigan FTC

Technical and Equipment Support

mi.ftc.tech@gmail.com

[mathterizer]

I have 2 questions regardig your 'Steps to Reproduce' list,

• are you 'deploying' through the wi-fi connection made by the FCS (thereby never breaking the FCS connection)?
• do you ever re-'CHOOSE' the NXT from the FCS after running 'Program Chooser'?

By powering off the NXT, you then re-establish the FCS connection by 'CHOOSE'-ing it; this would make the FCS read the current .txt file.

I don't know how often the FCS goes out to read the FTCofig.txt file, but that might be what is creating your issue.

[FIMTech]

Deploy is done over USB, so the FCS connection is broken.

I don't think I ever re-chose the bot from the FCS, just reconnected after downloading the new program and running Program Chooser. I'm planning on playing with this a little more this weekend to see if I can narrow down the issue.

Robots programmed with RobotC don't require a power cycle after running Program Chooser - the change to FTCConfig.txt is recognized the next time the teleop period is started, so at least for RobotC the file is read every time teleop starts.

[mathterizer]

I can't imagine that the FCS would treat LV and RobotC differently on when it goes out to read the file. So, that lends to the idea that the NXT file might not be closed properly by Program Chooser. However, if that were the case, wouldn't it be necessary to restart the NXT even the very first time you run P.C.?

Do you exit out of Program Chooser completely? Maybe could try going to a higher NXT sub-menu?

We just had a 30 hour 4-team lockin meeting and expereinced the issue you describe a couple of times, but escaped it most of the time. But since we had multiple programmers using different laptops - we had a lot of NXT power ups and downs. Next time we have the FCS up, we'll do some more targeted experimenting on this issue.

[FIMTech]

I got completely out of program chooser, started the autonomous program and ran the FCS just like at a competition.

[Philbot]

My experience is that the FCS does NOT re-read the selected teleop program each time it runs a match (or even connects).

I've seen this several times during software inspections, when teams change the selected teleop program, and it continues to run the old one.

You need to be more pro-active to force the FCS to re-read the program name.

Exiting the FCS and re-starting definately has the desired effect.  So this indicates to me that it's not an NXT problem.

It may be enought to manually disconenct the NXT (from the FCS) and then re-connect.

Phil.

[mathterizer]

Bottom line is that the NXT firmware is still 1.31 and the FCS is still v3.0.6 - the same as last season. The change is the LabVIEW 2012 release. Last season these files came in during 'firmware update'; this year we bring them in by running the NXT in 'direct mode' once, as per NI's advisement. (re: Program Chooser, Samostat, NXTShell)

When tracking down the 'Program Chooser' files between the LVLM 2010 and LVLM 2012 releases I noticed a few different sizes in  kB for the .rxe's located (and generated). I posed this queston to  NI a while back. I have posted instructions for locating the .vi and compiling a fresh .rxe using LVLM 2012. https://decibel.ni.com/content/docs/DOC-17939

Today I'll try a fresh compile, instead of relying on the .rxe in the \subs directory where the 'NXTShell' and 'Samostat' .rxe's live also (the ones downloaded too th NXT when you first run in 'direct mode').

Another option to try is using last season's .rxe for Program Chooser - However, if the 2012 version of the 1.31 firmware is not identical to the 2010, this might not work - in fact, that could be what's happening here.

If a good Program Chooser .rxe is made (found), then it could be moved into the \subs directory used for auto-download during 'direct mode'.

I'll provide an update regarding my file locations found (used) and test results within a few days - maybe some of you can beat me to this

[mathterizer]

Today I'll be testing a 'My Chooser' vi that I compiled from the 'Program Chooser.vi located in [ C:\Program Files (x86)\National Instruments\LabVIEW 2012\examples\FTC Toolkit\Program Chooser 2.0 ] directory. (Why they ever named a folder with a 'dot' in it, I'll never know).

I ended up pulling in all the .vi's from that directory and having to change them to 'NXT Targets' to deploy the program.  I have not found a way to add to the 'vi Search Path'. The 'Tools - Option' location has the 'insert' ability greyed out. I even treid to do it from the 'native LabVIEW environment' - no go.

The compile size for this .rxe is 5.31 KB, quite different than the one in the directory where NXTShell.rxe and samostat.rxe are  [ C:\Program Files (x86)\National Instruments\LabVIEW 2012\vi.lib\NXT\Subs\OnBoardFiles ] which is an .rxe that is  3.32 KB (compiled 10/25/13).

So, I'll compare if one works better than the other.

I've been having so many other strange issues the past 2 days, I may be attempting a full reinstall.

I did a deploy for the samostat.vi from the directory [ C:\Program Files (x86)\Samantha Field Control System\Labview ] and the file size was 5.9kb versus the one in the \OnBoard Files directory which is 2.14kb (compiled 10/25/13).

Has anyone had issues with a non-working samsostat program?

[FIMTech]

I re-ran the Program Chooser test last night with more controlled conditions -

• 2 robots, 1 with LabVIEW, 1 with RobotC.
• 2 Teleop programs on each - TelopX and TeleopY (tank drive controlled by the X or Y axes of the joysticks on gamepad 1)
• Current version of Program Chooser for each environment loaded on the NXTs
• Current FTC FCS, Samantha firmware, approved router (Linksys E1200). Running over wifi from computer connected to the FTC_PIT network
• 1 gamepad connected to the computer

1. Used 'Program Chooser' to select TelopX on both robots. Started the driver control period on the FCS, both robots worked as expected - X axis controlled the drive motors
2. Used 'Program Chooser' to select TelopY on both robots. Started the driver control period on the FCS, both robots worked as expected - Y axis controlled the drive motors

I'm not sure what was happening the first time I tried this - the programs were more complicated but that shouldn't matter. I'll keep watching for this, but it appears to not be a problem with Program Chooser at least for now.

[mathterizer]

So far it seems to be a issue we need to keep an eye out for. Sometimes the newly deployed code for the teleop is being used, sometimes it seems the programming changes didn't work (take)...that is, it still uses the old version. This is happening to us when in LabVIEW RC Editior 'teleop' as well.

Initially I thought that deploying from the vi itself would be preferable...but, it appears that using the 'download and run' option from the RC Editor's 'teleop' testing mode is the most effective way to ensure that we get our 'NEW' mapping used.

When it comes to the FCS and Program Chooser?  It's a bit hit and miss so far, but we'll keep watching out for it.

12/11/13  update:  So far we have had no problems with P.C. We just had a 10 team event where 8 were using LabVIEW and all was well