Consistently recording at precisely every 20 milliseconds is very difficult without low-level access to the brain (which would likely require removing the Hardware Abstraction Layer(HAL) that is PROS/VexCode)
Instead, if you wish to continue with a continuous recording system like that which has been experimented in the past, feel free to check out the works of lewispinstein-hue, one notebale code has been linked below:
If, however, you wish to continue with a code which records position and uses odometry in a different (in my opinion, more reliable/accurate) fashipn, feel free to check out my code:
Or better yet, look at both of our codes thoroughly and forge you own path forward, adapting the codes of past as you see fit!
In any case, this has very much been done before, and reliably at that. It won my team Think award at Nationals, and at Worlds our drivetrain/odom broke, so the code could not execute.
Carry the torch, and keep it open-source!!!
How accurate/reliable is it? I ran into some problems when testing out this style of implementationā¦ although I switched to a different style, I think I have some solutions to the problems I had with continuous recordingā¦
Make sure to experiment with different solutions as well! You never know which version might workā¦
(also, make sure to open source it after your competition season is over )
so, for the imes, you have to put one motor in two motor groups, and use one motor group for sensor input and the other motor group for drivingā¦ itās kinda weird, but it works lolā¦
lowkey just fork my github it has the exact implementation iām talking about.
for us, the accuracy took a real hit when at Worlds, when our drivebase started malfunctioning. Becasue of that, the IMEs in the motors were unable to provide accurate sensor feedback. I personally would recommend having external odometry wheels, because otherwise if the drivebase skips even once, your auton will be off.
If you have a really reliable drivebase, its fine haha
Finally, definitely use LemLib+PROS, it has a bunch of useful capabilities, such as PATH files (which will be useful if you want curved path recording)
PS.
I feel like I may have misunderstood your message. If by:
you meant using the IMEs WITH Tracking wheels, that would be EXTREMELY precise and reliable, but would likely require an Extended Kalmann Filter for sensor assimilation. Itās a really good idea, but is the overhead during execution really worth it? It may not be, especially if you intend to assimilate: Tracking wheel vertical 1; Tracking wheel vertical 2 Tracking wheel horizontal; IMEs; AccelIMU; Ultrasonic sensor 1; Ultrasonic sensor 2ā¦ although there is really no need to got that far in the name of precision, not in vex v5 for sure.
I am not competing this year, so PM me if you want adviceā¦
Thanks, that makes sense. Iām going to improve it by recording timestamped snapshots with motor positions and heading, then replaying toward those snapshots instead of only replaying joystick values. Iām trying to keep it on the hardware we already have, so no extra sensors for now.
that sounds like a good idea. i would strongly recommend - no, in fact, insist - that you use PID for the auton. It is much easier than people make out, and setting up and tuning LemLib takes only 3 hours if you are by yourself, and much likely less time if you are with others. It requires little extra hardware, and it is much more accurate than using raw motor position values.
)