This weekend the programmers moved from using a POT to select Auton to using the LCD. They got the auton working with the comp switch. However, when trying to use the controller and selecting a skills programming run, the V5 system does not enter a disabled state to select form the LCD. I counts down (3 sec) and runs the select program slot. Auton does not run because it has not been selected on the lcd. If we push run on the brain, it drops out of skills on the controller.
Has anyone using the LCD to select auton got it working with the controller based skills programming selection?
It’s tough since this isn’t something we can solve in the PROS kernel - your bot starts in autonomous mode, so we run your autonomous code. There’s no disabled period when you run programming skills with the controller.
You can put your autonomous selection logic inside of
. You should be aware that if you have any code which blocks the robot from running, you could get stuck in a real competition and lose time because you would need to go through some LCD screen menu.
solves this by only running this code when the bot is disabled before a match (just like
only runs in operator control mode), but as you noticed, you don’t get this disabled period when using the controller to run skills.
I thought as much but hope they were just doing something wrong. This means I need to keep the comp switch or move to a less elegant solution.
Would you suggest using the file system to save a number associate with the autonomous selection? They are using a function pointer now so they could make an enum of auton functions, (which is what they had when using a pot). If the auton_ptr=no_auton, code could read a file to see if a selection exist there.
Hopefully VEX will fix the skills programming feature on the remote to allow auton selection (disabled mode) before running the program from the selected slot.
Thanks for your input and btw, the programmers really love PROS and are happy with the selection of LVGL (now that they’ve used it – pc simulator has been very helpful).
yes, we understand this feature needs improvement, an update will not make the next vexos release but perhaps the one after that.
This would be a reasonable approach in the short term.
We do have an API that was not released to 3rd party developers yet that allows a small amount of persistent data to be saved with the program. The use for this would not only be things like autonomous selection, but also perhaps things like PID constants found as the result of tuning. This is not intended for a large data set, we only allow 128 bytes to be saved that are organized as 32 words. This data is valid for a program slot, it would be up to the user code to determine if the values were valid or were left over from an old program. In other words, we do not clear this data every time a program is downloaded into a particular program slot.
Great thanks for the response. Knowing that its not supported right now is enough since the comp switch does work.
As for the file system or persistent data storage, and since I’m not a strong coder (just a coach/mentor), would saving the function pointer address (as selected by the gui) as a 32-bit value (assuming 32-bit vexos?) work? Meaning would the same function have the same address every time the program is run?
I would not save a pointer.
The address of a function would be the same each time the program was run, but would most likely change if the program was modified, compiled and downloaded again. Best to just save a simple index, 0, 1, 2 etc. and use that to access an array of function pointers if that’s the preferred way of running different autonomous functions.
Right, when they were using a pot they had an array of function pointers b/c it was a two step process. When they added the GUI they used a direct assignment on the button press. That was the difference between the main coder and the GUI coder.