Summary
Sometimes we want to change robot team and/or bot ID, e.g. if we are playing against ourselves.
The configure task in the deploy script currently asks for these parameters and does correctly set the yaml config as needed. But additionally the wifi IP needs to be updated to match the new configuration. This currently needs to be done manually.
Ideally the deploy tool would automatically adjust the WiFi config to match the new configuration (under the assumption that we are inside a valid competition WiFi - an assumption that the deploy script should verify.
A potential challenge is that if we are configuring via this WiFi (which is likely in a non-competitive context where it's also most likely that we would want to use this feature), the deploy script needs to realize that the IP will change and adjust accordingly, switching over the new IP for the build afterwards. This also means that ideally a bash script is send over for configuration that then gets run independent of an ssh session. (a script that somehow needs to have sudo access)
Additionally, we had issues reconfiguration the WiFi when using deploy ALL since apparently the UUIDs are not the same across robots.
Summary
Sometimes we want to change robot team and/or bot ID, e.g. if we are playing against ourselves.
The configure task in the deploy script currently asks for these parameters and does correctly set the yaml config as needed. But additionally the wifi IP needs to be updated to match the new configuration. This currently needs to be done manually.
Ideally the deploy tool would automatically adjust the WiFi config to match the new configuration (under the assumption that we are inside a valid competition WiFi - an assumption that the deploy script should verify.
A potential challenge is that if we are configuring via this WiFi (which is likely in a non-competitive context where it's also most likely that we would want to use this feature), the deploy script needs to realize that the IP will change and adjust accordingly, switching over the new IP for the build afterwards. This also means that ideally a bash script is send over for configuration that then gets run independent of an ssh session. (a script that somehow needs to have sudo access)
Additionally, we had issues reconfiguration the WiFi when using
deploy ALLsince apparently the UUIDs are not the same across robots.