This might be a bit of a weird question, but I’ve seen multiple instances of teams, even high performing ones, just suddenly start spinning in place at the start of the autonomous period. My team used to have this issue last year maybe once every ~10ish matches, but it eventually just stopped, and we never really found out why it did that. This year, thankfully, our autonomous has worked just fine, but does anyone know what might be causing this issue?
Either because there is friction or because the motors were too hot
That might cause occasional circling, but when robots spin in place, it looks like one half of their drivetrain is going forward and the other backward, and as an effect not making much overall movement. After they’re done spinning, driver almost always seems to go off fine.
I’ve seen some teams do it just for fun.
4 Likes
In our case it happens because we use a basic P loop to turn (tank spin) using IMU readings. Sometimes the IMU is returning garbage and the code never sees the “target” degree number so the robot just spins in place until field control disables motors. It doesn’t just skip because the loop is too fast or bad code, it just spins forever and if we display the value from sensor it kinda jumps between a zero and a 30 or so it seems to the naked eye. We’ll try to log it but of course it only happens in matches, never in testing.
Now it is interesting to me that you noticed this as this has been puzzling us recently. We use same code as previous years (just basic PID but because of all the slop and friction in a VEX robot, we only use the proportional factor), yet this year it started happening for all teams. The brain log does not report any port disconnect (which would usually be the cause for something like this and we would see the orange screen but we don’t). We replaced IMUs several times as the first reaction is to say “oh well it broke just replace it - just like all modern auto mechanics do”. We are currently forbidden to buy more IMUs as the financial powers at be, well, they’re pissed… We use an overabundance of IMU calibration in our code. This trend started at events where they yell at you to be ready with robot on and controller in hand but they keep you waiting 10 minutes because of some score dispute on another field or some h. sapien tripped over some wire and the Raspberry Pi is rebooting. Well in those 10 minutes you’ve already “drifted” several degrees. So currently we sacrifice 2 seconds of autonomous to Gyro, the God of IMUs. Is it because this game is more physical this year and there is more stress on the flimsy-ish V5 ports and connections and there are microsecond disconnects on the port that do something bad to the IMU? Our solution right now is to unplug and replug the IMU wire and then all of a sudden readings are normal again. We can’t figure it out and we’re in conspiracy theory world right now (IMU planned obsoletion, like the iPhone batteries? the new “smart field control” sends malware?). So yeah, that’s our story of the spinning robots during auton.
1 Like
I get where you’re coming from here, but you’d be better off just setting its rotation to 0. That way you can have your full auton period.
Yeah we do that when all 15 seconds are needed. We noticed that drift accelerates after robot on for a long time that’s why the excessive calibration.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.