Robot Configs as resources, and the like

[FTC0417]

I wanted to mention one feature of the 2.0 release that perhaps not many have yet run across: robot configurations can now live as resources in your robot controller application APK (in addition to files on the RC phone, where they have always lived).

Any .XML file found in (e.g.) TeamCode\res\xml\myConfig.xml whose root XML element is "Robot" and which has a "type" attribute with the value "FirstInspires-FTC" will appear as one of the available configurations in the "Configure Robot..." user interface. If the root "Robot" element also has a "name" attribute, then the value of that attribute is used as the name of the configuration; otherwise, the name of the XML resource file is used. Robot configurations found in resources cannot be edited and saved using the UI on the RC phone, but they can be edited and then saved under a different (file-based) configuration name.

Placing robot configurations in resources in this way ensures that the configurations appropriate to your opmodes are available wherever your opmode code happens to travel; you no longer need build the needed config from scratch each time. To create a resource-based configuration, you can copy an XML configuration from your phone and paste it verbatim into the appropriate Android Studio directory (if they've been edited under 2.0, the necessary "type" attribute will have automatically been added), and / or you can edit the XML file by hand directly.

This approach is made even more useful with the new 'fix' and 'swap' functionality in the configuration editor UI. If a USB controller is present in a configuration but missing in action (ie: not connected) when the configuration is edited, but there's another unused USB controller of the same time which is attached, then a 'Fix' button will appear that when pressed will substitute the latter for the former in the configuration. Got a dead motor controller? Swap it out for a new one, edit the configuration, press 'Fix', and you're done. 'Swap' works in an analogous manner to allow interchange of like-typed USB controllers: it's more general, and consequently has a another nested screen in its user-interface. You won't see both 'Fix' and 'Swap' appear simultaneously: think of the former as a special case of the latter.

[GearTicks]

+1
I assume that if you "fix" or "swap" a configuration, you have to apply that fix in the resource file on a computer as well?

[FTC0417]

+1
I assume that if you "fix" or "swap" a configuration, you have to apply that fix in the resource file on a computer as well?

Yes and no :-).

First, to be clear, 'fix' and 'swap' work on all configurations, not just resource-based ones. For file-based configurations, you can just save the fixed/swapped configuration back in place, like any other edit. For resource-based configurations, you can't save them in-place, but you do have the option of saving the edits as a (new) file-based configuration; that's probably the quickest and easiest thing to do during a match, for example. Later, yes, you'll want to go and update the configuration in the resource back in Android Studio.

[GearTicks]

Is it possible to set the selected configuration file from the OpMode? It would be really nice to have all the code stored in our Git repository, where the OpMode code would just pass in the resource containing the required configuration. That way we wouldn't have to worry about making sure to change the selected configuration when running different OpModes.

[FTC0417]

That's not currently possible, no. It would be easy to invent some means by which an opmode could declaratively indicate its desired configuration, and it would be easy to check that that config was in use, but it's a good deal harder to automatically switch to that config, given how things are sequenced in the robot controller. Also: remember that configs have embedded in them the serial numbers of the usb controllers; if one of them goes bad, and you need to make a new config in the middle of a meet (remember that resource based configs are read-only), you're not going to want to be tied only to the original config, so some means of overriding the associated opmode would seem desireable. Thoughts?

[mikets]

Thank you FTC0417 for the info. we have integrated two robot config files in our sample project as an example.

https://github.com/trc492/FtcSamples/blob/master/FtcSampleCode/src/main/res/xml/wildthumper.xml

Several notes:
- the xml file name must be in all lower case so if you want to have mixed case name, you can do it in the name attribute.
- null.xml is illegal because null is a java keyword.

[FTC0417]

But wait, there's more: if instead of a type of "FirstInspires-FTC" you use a type of "FirstInspires-FTC-template", what you have is not a populated configuration that shows up as something intending to directly be used but rather a template that will show up under "Configure From Template". In this case, it's best to just set the serial numbers "n/a"; they will be filled in when a user populates from the template. Templates are a good choice for those providing samples (thanks for the seque, mikets), as your users bots don't share any serial numbers in common with your own on which the samples were tested.

[mikets]

But wait, there's more: if instead of a type of "FirstInspires-FTC" you use a type of "FirstInspires-FTC-template", what you have is not a populated configuration that shows up as something intending to directly be used but rather a template that will show up under "Configure From Template". In this case, it's best to just set the serial numbers "n/a"; they will be filled in when a user populates from the template. Templates are a good choice for those providing samples (thanks for the seque, mikets), as your users bots don't share any serial numbers in common with your own on which the samples were tested.

Thank you for the additional info. Template config is now added.

https://github.com/trc492/FtcSamples/blob/master/FtcSampleCode/src/main/res/xml/wildthumper_template.xml

[GearTicks]

That's not currently possible, no. It would be easy to invent some means by which an opmode could declaratively indicate its desired configuration, and it would be easy to check that that config was in use, but it's a good deal harder to automatically switch to that config, given how things are sequenced in the robot controller. Also: remember that configs have embedded in them the serial numbers of the usb controllers; if one of them goes bad, and you need to make a new config in the middle of a meet (remember that resource based configs are read-only), you're not going to want to be tied only to the original config, so some means of overriding the associated opmode would seem desireable. Thoughts?

I suppose that, at the very least, you could give the name of the configuration you'd like to use and it would use the resource file unless an edited version had been saved onto the phone's file system. Perhaps OpMode could have an overloaded constructor such that you could call, for example, super("tank2"); in the constructor of your team's OpModes that use the configuration file. You could then create a tank2.xml configuration file containing the configuration and if you edited it on the phone, it would save a new tank2.xml to local storage which would get used in place of the resource file. You would probably have to manually update the resource file to match the edited version, but at least you could swap out control components in competition without needing a computer. I assume you could either delete the phone's configuration file once you transfer it to the resource file, or the phone could automatically delete it if the devices in the resource file match those in the config file.

[skatefriday]

I suppose that, at the very least, you could give the name of the configuration you'd like to use and it would use the resource file unless an edited version had been saved onto the phone's file system. Perhaps OpMode could have an overloaded constructor such that you could call, for example, super("tank2"); in the constructor of your team's OpModes that use the configuration file. You could then create a tank2.xml configuration file containing the configuration and if you edited it on the phone, it would save a new tank2.xml to local storage which would get used in place of the resource file. You would probably have to manually update the resource file to match the edited version, but at least you could swap out control components in competition without needing a computer. I assume you could either delete the phone's configuration file once you transfer it to the resource file, or the phone could automatically delete it if the devices in the resource file match those in the config file.

I think there's value in keeping things as simple as possible, but no simpler.

There are a couple of problems that I could see tripping people up with the proposal. If you have two configurations with the same name and the rules for which one is chosen are more than a few words long, then I can see teams being confused when tank2.xml is being used, but they think tank2.xml'prime is being used. Ambiguity without clarifying transparency can be problematic. The first iteration of the configs as resources did not allow editing of a resource config at all on the phone. That was added later and I can't remember offhand if we enforce a unique name when a config is edited locally on a phone. But I tend to think we probably should if we don't.

You can still swap out control components without needing a computer by using the aforementioned "save locally" feature of a resource config and then just modifying as you did last year by hand, on the phone. But phones should never automatically delete files. Configuration or otherwise. You'll have all sorts of "where'd that file go" questions.

The motivation behind configs as resources was ease of use by packaging configurations automatically with the RC, and facilitating editing of device names from within Android Studio. Need to swap out a phone in competition and your configuration is stored as a resource? Awesome. It's trivial. Deploy the RC to the new phone and there's your config. No need to spend 15 minutes manually entering your robot's configuration into the new phone. No need to know how to push a config via adb either, which means anyone on your team, programmer or not who knows how to push the green deploy button in Android Studio can get the new phone up and running. Tired of using the phone keyboard? Run a USB scan, use adb pull to grab the config file, drop it into the res/xml dir of your project and edit the names in a nice Android Studio editor.

The follow on feature to simplify even further is to be able to scan for usb devices from directly within Android Studio via a plugin.

I'd like to see a focus on simplicity of use and I'd like to avoid layering rules, especially ones that might be opaque and little understood, onto configuration selection.

[GearTicks]

I can't remember offhand if we enforce a unique name when a config is edited locally on a phone. But I tend to think we probably should if we don't.

It is indeed impossible to save a config file with the same name as an existing one (either a resource config or a local config).

I'd like to see a focus on simplicity of use and I'd like to avoid layering rules

I agree. My original suggestion was to add a way for an OpMode to specify a config file to use so that drivers wouldn't have to manually coordinate them. Last season, there were many times where the programmers had selected a different config file because they were using a test setup and had forgotten to change it back, and then the drivers could not figure out why hardware devices were reported as disconnected and the tele-op program would refuse to run. I don't think drivers should have to know how the apps work in and out, so it is just an added hurdle that running an OpMode designed to run with a specific config file requires the drivers to remember to select the correct file. FTC0417 pointed out that this would create complications if you wanted to edit the resource configuration file, which is why I proposed that (complicated) solution. I think it would be useful to be able to select the configuration file from the OpMode, even if it prevents it from being edited. If a team wants to be able to edit their files, they should just use local config files rather than resource config files. In our case, we have two RC phones, so if we needed to edit the config, we would need a computer anyways to transfer the changes to the other phone. Since I don't think most teams are aware that you can create resource configs, they would have to be aware of the fact that they can't be edited without a computer if they opt in to using them.
In summary, it would work like this:
- An OpMode may or may not specify the name of a configuration to use. If no config is specified, the selected one on the RC is used.
- If an OpMode specifies the name of a config, either a resource config or a local config, it is used. If the config doesn't exist, an error is thrown.
- If you want to be able to edit the config, use a local config. If it is more important that the config be included in your Android Studio project, use a resource config and accept the fact that it can only be edited on a computer.

I would argue that this increases simplicity of use for people with little knowledge about how OpModes work with config files.