Writing an autonomous code is a very tasking job. I’ve been thinking for a while now, and it occurred to me to wonder over whether or not it was possible to create a robotc code that would write its own autonomous code as the robot moves.
An example of this would be attaching shaft encoders to a chassis, and as one manually moves the robot, the robotc program records the movement and is able to generate a code that corresponds to the manual movement of the robot.
However, what I cannot think of a solution to is where robotc would display the output code. It can be outputted as a variable and copied and pasted, but that seems very inefficient to me.
Thoughts?
(I’d like to add that I am relatively new to the VEX robotics world – second season only, so answers obvious to others may not be as obvious to me (lol))
That would be called rerun. There are many versions of this and it is used pretty widely. There is output based which uses sensor values. There is also input based which uses controller input.
EDIT: I wouldn’t recommend it this year as it involves a high level of accuracy.
We have thought about using this, however, like NyQuil implied, it is better for games that are not as precise. I’m not saying that it couldn’t be done for this game, however the amount of accuracy you need this year just makes it not worth it. If you would like to use it, you can research about debug streams.
ROBOTC rerun program idea. Video contained inside. Code attached in video comment section.
I toyed with the idea back in 2015 when the skyrise season just finished. The basic idea is to run your joystick-to-motor control not directly but via a variable target PID velocity control loop, with a reasonable refresh rate such as wait 200 ms per loop to not print out ridiculous amount of data. Then you drive your robot and program the debug stream to print out those joystick values in a neatly formatted way. You directly copy those bunch of comma separated numbers into an array variable in your pre-written rerun program itself. Then use a for loop to feed those joystick values every 200 ms to the variable target PID velocity control loop. The result should be a high fidelity rerun.
The reason with operating, recording and re-running all via a variable target PID velocity loop is to make the rerun as battery-voltage independent as possible. If things are simply timed, then of course your robot will traverse shorter when battery is lower. Also, the joystick value to motor free spinning speed curve is linearized in my code based on my experimental data, to get the PID velocity working better. Driving with these excess controls on may feel different, but whatever you recorded, hopefully that’s exactly what it will play back. I only got the code working with one joystick operating one motor, and the sensor setup is simply one big red encoder. I didn’t get this working with multiple inputs and multiple motors simultaneously. I think that’s completely doable. You just need to do a little bit of thinking, whether you wanna multitask loops or precisely record and time everything in one loop.
At the end, I wouldn’t recommend doing this for competition purposes. I don’t know if this is any more reliable for your autonomous. I’m guessing it’s probably not. And I’m not sure how things will go wrong. Robot running rogue and breaking things because of a minor error, etc. The amount of thinking you need to put into your coding to do the rerun is no joke. And most of the times you want things to be as simple and straightforward as possible. Nothing wrong with procedural programs for autonomous. It’s something you wanna try out when you have a lot of spare time facing a finished robot to add to your excellence notebook. And usually in VRC you don’t have spare time.
I know that for some of the challenges that needed less accuracy i.e Starstruck it was incredibly useful. I want to do more testing with it for ITZ but I don’t have a full field setup yet.
There’s another option: employing a neural network that learns how to code and going through thousands of real-world runs to train the software.
But no one would actually do that. (please prove me wrong)
I think people have tried in the past. You’d have to set up the field every run, and looking at how many game pieces are there this year, I don’t think its feasible, but it is possible .