Our autonomous drives forward, turns and hits the hopper, then turns and drives toward the boiler to shoot.
If we run the blue autonomous from the blue side of the field it worked perfectly.
We transferred all the numbers and code to a red side autonomous and ran it on the red side…
It ran short going out and long coming back.
We ran the blue auto from the red side and it also was short going out and long coming back.
So we made some measurements by having our robot move 10’ 2".
Going North, it would go 10’ 6 "
Going South, it would go 9’ 10"
Going either East or West, it would go 10’ 2"
The robot was always driving forwards, so the motors were always spinning the same directions.
We tested in a different location with a different carpet, and it was still long going North and short going south, though the numbers were a lot closer.
We have no idea what the problem could be other than issues with magnetic encoders, or the navx is somehow altering our course…
We are not sold on the magnetic north/south issue, but it is the only working theory we have. Motors are always running the same direction and the distances are too perfect front/back and side/side to not be something physically based on direction.
To clarify how many times we did this.
We ran over 30 tests. At least 10 north and 10 south and at least 3 east and 3 west.
So statistically, if it was drift or friction, we should have seen some sort of variance, but our variance was less than 1/2" either direction.
What kind of path planning are y’all running? Where are the encoders in the drivetrain? I’m wondering if you’re spinning wheels a bit and it’s anisotropic for some reason.
Our drivetrain is in low gear and moving ~5’/second, and the encoders are pretty much in the center of the drivetrain from front to back. (maybe 6" off of center from side to side, I am not positive off the top of my head.)
We thought at first that our wheels might be spinning as well, but when we looked closely while running it, we didn’t see the wheels spinning.
My original thought was that it might be the carpet, but in previous years we haven’t had this issue and the carpet hasn’t changed…
Have you tried running without the NavX? Just drive both sides 100% forward for your 10’ test. This will also check if your drivetrain itself drives straight, or if one side has higher friction.
If I had to guess now, I’d say you’re doing more course correction with the NavX in certain directions, causing you no longer to move in a straight line. Thus, travel different distances.
But really if you want to fix this, we would need more information. It sounds like a ‘funny’ problem that actually has a simple solution, which unfortunately may be out of our power to identify.
Oddly enough, I’ve seen a somewhat similar issue to what you are describing. I haven’t had a chance to look into it as much as you have, but were are definitely seeing a difference between forward/reverse movement (or perhaps it has to do with direction more than forward/reverse) for the same distance travelled (based on encoders). We’ve verified that the encoders are working correctly and we see the same problem weather we are driving the robot, or pushing it by hand. Moving 12’ forward and then moving 12’ in reverse (based on encoders and/or physical wheel rotations) returns the robot to a different spot on the carpet. It does seem fairly consistent. This is the first time I’ve seen this since I’ve been in FIRST. However, this is the first year we’ve used 4" traction wheels that are spaced fairly close together (8 wheel, onmi’s on the outside), so perhaps we are getting some sort of scrub on the carpet that is dependant on the weave of the carpet. We have no solution as of this point, but I will do some tests to see if it is related to carpet orientation this week.
By whether are the encoders, I meant what are they mounted to? What’s the gear ratio between the encoders and wheels?
Any weird problem with the encoders is more likely to be sub-revolution error than whole revolutions. If the encoders are direct to the wheels, sub-revolution could still be pretty large. A whole revolution of your wheels is 12", after all.
Honestly, though, it’s most likely to be mechanical/physical in nature. If you have varying wheel sizes/speeds, you might be doing weird things to the carpet pile that make things work differently in different directions on the carpet.
As others have noted variance in linear distance traveled sounds like encoders not reflecting true distance traveled.
Rotational measurement from the navX-sensor should not change in correlation w/earth magnetic pole orientation - unless the “fused” (9-axis) heading is used and the magnetometer calibration is not ideal. However the standard 6-axis heading (yaw angle) used by most teams is completely based upon inertial sensing and not impacted by earth magnetic pole alignment. In short, if you’re using the (6-axis) yaw angle accuracy should be the same independent of absolute orientation.
You’re almost guaranteed to have repeatability issues, then, and a non-level field surface could definitely cause what you’re describing.
I strongly suggest you use some form of feedback in your drive control if you’re going to rely on dead reckoning. Just using an open-loop constant voltage command that ends when you reach your set distance is not an optimal solution. Since you have encoders, you can use a velocity servo, which at the very least (even if you don’t use a motion profile) will help greatly with stopping on a point. Motion profiling works really well, but there’s a fair bit of overhead to getting it working.
You could call this feedback, but it’s not closed-loop control, which is what you’d really want to use for something like this.
Moreover, if you’re giving it full voltage in low gear, you are without a doubt initially spinning the wheels as the robot accelerates. This will throw off your encoder readings.