Replay Robot Movements

I’ve been working to get something like this working for a while, and now it’s working for the most part. This project records values at set intervals and saves them to the SD card and/or to the USB serial connection. I designed it to be easily modifiable to allow for many different configurations of robots.

It’s pretty accurate for a few seconds, but the longer it goes, the less accurate it is. I tried to make it as efficient and the timings as accurate as possible, so it’s more consistent. If anyone has any suggestions on making it more consistent, I’d love to hear them. I’d like to implement encoder values, PID, and things like that, but idk how that would work.

I’ve modified it a little bit since I’ve last used it in order to share it, and don’t currently have access to a robot right now, but it should work fine.

8 Likes

Me and my friend attempted to make this once, but we never got too far. Thanks for sharing!

Neat, I did something like this a while back. I quickly learned that this is impractical for an accurate auton.

3 Likes

This is a cool project, good work! I have seen this idea before over the years and people usually have issues with the consistency and accuracy because they don’t add in a closed-loop control component.

1st Order Control
Essentially you want a controller that will make a robot follow a motion trajectory instead of just a set point. You can record the motor velocity and position and then use a controller that (probably) looks this:

`cmd_velocity(t) = replay_velocity(t) + Kp * ( replay_position(t) - curr_position(t) )`

where Kp is a tunable gain. The velocity would be a feedforward component, and the position is closed loop control.

2nd Order Control - Weird Boring Theory
If you can command raw voltage to motors, you could probably up this to a second-order model and also control acceleration (sorta). Similar to the first model, you would have a feed forward acceleration and the closed-loop feedback on the velocity and position terms.

`robot_acceleration(t) = replay_acceleration(t) + Kd * ( replay_velocity(t) - current_velocity(t) ) + Kp * ( replay_position(t) - current_position(t) )`

This is loosely based on Inverse Dynamics Control, specifically equation 46. There they use acceleration values and then push it through an inverse dynamic model of the robot to get the desired force/torque to apply to actuators,. That is almost definitely out of scope for high-school vex though.

I feel like you might be able to replace that acceleration term with the commanded motor voltage from a user run that you want to replay and it would output a motor voltage instead. It feels like the commanded motor voltage should be somewhat proportional to the robot acceleration. It is certainly more complicated than that, but would probably still see substantial performance improvements over just replaying user input alone.

2nd Order Control - Easy equation to copy-paste, very nice!
Record the analog motor voltages, velocity, and position of your robot over time as you drive it. Then, a robot controller might look like something like this:

`robot_voltage(t) = replay_voltage(t) + Kd * ( replay_velocity(t) - current_velocity(t) ) + Kp * ( replay_position(t) - current_position(t) )`

The velocity and position terms will probably be much smaller than the recorded voltages, but that little bit of closed-loop control could yield substantial improvements in performance and consistency. You could apply these models to any actuated subcomponent of your robot (both sides of drive train, lift).

It is early and I have procrastinated my real job writing this, so take it with a grain of salt, but it seems legitimate on the surface.

Good luck!

7 Likes