Changing name of Auto in GUI does not remove old name from RIO or Chooser on Driver Station

[OhHey-ItsDave]

Describe the bug
Editing the name of an Auto or Path within the Pathplanner GUI does not remove the old filename from the RoboRIO on the next deploy. This results in a copy of the file in question with both names to be present on the RIO even though the GUI only shows the new name. Most obvious when editing the name of an Auto and using the "buildAutoChooser()" function to add an Auto Routine Chooser to the driver station. Both the original and the edited names of the Auto will appear on the Chooser list on the Driver Station. Needed to Anonymously FTP into RIO to delete originally named files.

To Reproduce
Steps to reproduce the behavior:

1. Create an Auto using the GUI.
2. Deploy code to RoboRIO.
3. Edit name of Auto within the GUI.
4. Deploy code to RoboRIO again.
5. Check options of the Chooser object on Driver Station, both names will be shown.

Expected behavior
Delete original file(s) for renamed Autos on RoboRIO when deploying renamed Pathplanner files. Only Autos shown in GUI should appear on Driver Station Chooser.

Versions: (please complete the following information):

• OS: Windows 10
• GUI Version: 2024.1.5
• PPLib Version: 2024.1.5
• PPLib Language: Java

[WarrenReynolds]

Hi Dave,

This isn't really anything to do with PathPlanner, so its a stretch to call it a bug. The files are copied onto the RIO by Visual Studio when a deploy code is done. The PathPlanner GUI doesn't directly access the RIO file system, but rather puts files into the deploy folder inside your project folder on your coding computer, that will get copied on to the RIO. So as you said in Describe the bug, you have to manually FTP into the RIO to delete excess files from the deploy folder that you don't want there, as both VSCode and Pathplanner don't have any idea what files are currently on the RIO in the deploy folder.

Maybe there is some way that the VS Code Deploy option could be modified to delete the entire contents of the deploy folder on the RIO and then copy every file across again. This would add to your deploy times, but it would fix your problem.

Personally we don't use BuildAutoChooser for this exact reason, but rather use the RIO preferences table to hold a list of strings that will populate the auto chooser. The keys are named Auto01, Auto02, , , Auto12. When we want to have an auto listed on the dashboard we modify one of these entries in the preferences table to include the filename of the auto we want displayed. NB: A RIO Reboot is required to make this entry appear in the AutoChooser.

This does introduce another step to adding an auto to your robot, and it also introduces a potential source of error if the file name isn't typed exactly the same, but for us, this gave us complete control over what appears in our auto chooser and in what order and it also didn't require us to recompile code to add an auto to our robot. The only thing that needs to be done, was a "deploy", to copy any new/modified pathplanner files onto the RIO.

This is code in the robot container constructor that builds the chooser. It's a bit messy, but it gets the job done.

  char autoCount_ca[7];
  std::string autoName_s;
  for (int x = 0; x < 12; x++) {
    sprintf(&autoCount_ca[0], "Auto%02d", x + 1);

    autoName_s = frc::Preferences::GetString(autoCount_ca, "");
    if (autoName_s.length() == 0) //If next to the auto option is blank, move onto next entry
      break;

    try {
      if (autoName_s.compare("default") == 0) {
        m_autoChooser.SetDefaultOption(
            autoName_s,"default");
            fmt::print("Added pathplanner DEFAULT: {}.path \n", autoName_s);
         } else {
        m_autoChooser.AddOption(
            autoName_s,autoName_s);
        fmt::print("Added pathplanner OPTION: {}.path \n", autoName_s);
      }

    } catch (std::runtime_error& error) {
      fmt::print("Error with PathPlanner file: {}.path\n", autoName_s);
    }
  }

  frc::SmartDashboard::PutData("Autonomous Run", &m_autoChooser);

This code lives in the Robot.cpp to populate the preferences table if the keys don't exist.

 frc::Preferences::InitString("Auto01", "Auto1Filename");
  frc::Preferences::InitString("Auto02", "Auto2FileName");
  frc::Preferences::InitString("Auto03", "Auto3Filename");
  frc::Preferences::InitString("Auto04", "Auto4Filename");
  frc::Preferences::InitString("Auto05", "Auto5Filename");
  frc::Preferences::InitString("Auto06", "Auto6Filename");
  frc::Preferences::InitString("Auto07", "Auto7Filename");
  frc::Preferences::InitString("Auto08", "Auto8Filename");
  frc::Preferences::InitString("Auto09", "Auto9Filename");
  frc::Preferences::InitString("Auto10", "Auto10Filename");
  frc::Preferences::InitString("Auto11", "Auto11Filename");
  frc::Preferences::InitString("Auto12", "Auto12Filename");

Using this method also give you the ability to have different chooser values on different robots. While we didn't have a 2nd bot this year, we have used this feature in the past when prototyping code on different robots.

[OhHey-ItsDave]

I'd guessed that was how Pathplanner deployed everything to the RIO (i.e. get VS Code to do it). Sorry for the "bug" label in that case, the lack of a way to handle changing or deleting files natively in the GUI isn't really your fault if VS Code is the root of the problem.

Annoying that the deploy doesn't populate the RIO folder with what's on the laptop exactly, including renames/deletes. I haven't seen anything on editing the way the deploy happens myself but can look and see if I find something.

I can try your RIO preferences method out the next time we have the bot powered on (sometime this summer most likely). Though reading through it I'm guessing in the first code segment that builds the Chooser the "break" statement in the first IF block is intended to be a "continue". Break exits the entire loop, so the remaining entries would be skipped.

[WarrenReynolds]

Hey Dave,

In regards to your statement.

isn't really your fault

Just to be clear. I can't take any credit for writing Pathplanner. This amazing program, that is supplied free of charge to all teams is all Micheal's doing. I'm just a programming mentor from a team that uses PathPlanner that was offering a suggestion as a work around. This is not an official response from the authors of Path Planner and I suspect Micheal would be horrified at that poorly written code I supplied, but it works for us.

I did a bit of looking around the web and I think you could automated the clearing of that deploy folder if you wanted to.
An option would be to modify the gradlew.bat file in the root of your project to include something along the lines of this at the top of the file

if "%1" NEQ "debug" goto SKIP
ftp -i -s:ftp.txt
:SKIP

Where ftp.txt is another txt file that has the ftp commands needed to delete all files in the deploy folder.
It been years since I've done this stuff but I think the file would need to hold something like this

open 10.TE.AM.2    (where TE is the first digits of your team number and AM is the last two digits)
lvuser

cd \home\lvuser\deploy
mdelete *
quit

A quick google search should tell you what is needed here. I just tested it with an ECHO This is a deploy operation statement instead of launching the FTP client and it worked a treat, only printing the message when a deploy happened. NB: There is no error checking here to see if you are actually connected to the robot, so it could hang for a while until it timed out if you weren't connected.

Also, there is a post on chief delphi talking about this exact topic. I'd check back there as well, as there is something there that talks about tasks happening in parallel. If this code was well and truly before the @rem Execute Gradle line I think it should be OK.

We need an old DOS programmer to step in here and tell us how it should be done.

In regards to

Break exits the entire loop, so the remaining entries would be skipped.

Yep, I'd say you are correct here. This code has been around for a couple of years in our code base and I thing we initially had all our auto entries blank. So the idea was, once you got to a blank entry it would stop populating the chooser.

As it stands at the moment, we just choose the filename with the auto chooser and then built the command at run time when Auto launches. I think next year we will prebuild all the auto command groups on code start and then have the chooser pick which one to run.

This will eliminate the problem where the scheduler gets a little bit behind when auto starts because it has to build the auto before it can run it and this was taking more than 20ms for us.

Hope you can get it working.

Regards
Warren