This is my first time using pathweaver, so forgive me if my question is kinda stupid.
Basically, our robot frame got bent the other day while doing a climbing test, and our climber malfunctioned. The gear ratio is 125:1 on a neo so it packed some serious punch, and it ended up screwing up the right side of our frame, such that it’s bent enough that our robot drifts off course when driving straight by a decent margin. We’re currently trying to fix it, but fixing the hardware issue probably won’t be amazing. While this should be fine in TeleOp due to drivers being able to account for it, I’m very worried over autonomous.
Due to this bend, I’d assume the robot’s ability to follow paths would most definitely be impaired, and I don’t know how accurate it’d be just using encoders and a gyro. Is this concern justified? If so, how can we adjust for it?
An idea I had would be to utilize a limelight to better correct for the odometry stuff, but I don’t know the first place as to how to do this. I could read through some other teams’ source code in order to pull this off, but given how different code structure can be, I’m a bit hesitant to scrape through codebases. Is there a tutorial or something someone could recommend?
Thanks in advance.
I may not be a programmer, but can I see the damage?
you might benefit from the pose estimators released this year. just crank up that std deviation lol WPILib Pose Estimators — FIRST Robotics Competition documentation
Once I get to robotics today, I’ll record a short video demonstrating it. We used a square across the back corners, and it got pretty clear when it started wobbling like crazy on one side.
A bent frame should not mess with PathWeaver. Are you sure none of the encoders on the drivetrain got damaged (internal or external)? What about the Gyro? Unless one side of your robot weights significantly more than the other side because of the damage you should be fine.
How come? The robot curves when it’s supposed to turn straight. For example, when I was trying to get the kv ka values and what not, the robot was curving throughout the duration of the testing. As stated previously, I have no idea about pathweaver, but intuitively it’d make sense for there to be some issues with pathweaving?
As far as I know, no encoders or gyros were damaged, and weights of the robot are exactly identical.
Wait a minute, I think I get what you’re saying now. Due to pathweaver getting info from the gyro, it’ll know if the robot’s curving when it’s not supposed to, and it can correct for that in the pathweaving. Am I correct in guessing that, or is there something else you meant?
this doesn’t sound like a software issue honestly, if your robot cant drive straight, you should either account for the difference and scale the power of the motors in the drive train or just ask build to fix the robot so it drives straight
Issue rn is that it gets worse with faster speeds, so it’s not a simple solution to remedy. As far as build goes, they’re going to try to fix it, but they’re not confident they can iron it out fully due to the issues with it. Hopefully it’d make more sense after I can post a video after school today.
Assuming you’re a software person, is my previous edit reason to not be concerned?
the motor compensation doesn’t have to be linear keep in mind so i would try scaling it exponentially, not a lot of course but even if you undercompensate as long as it works good enough that it can roughly stay on a trajectory for 15 seconds, you wont be using auto after that
how would I go about doing it? Would I have to form a regression of sorts and then account for it that way? Sorry if I’m being stupid about this, as aforementioned I have more or less no clue what I’m getting myself into with autonomous troubleshooting
well i dont know exactly what your robot looks like or what the curve of its motion would be but as far as weighting the sides, you could do x (where x is the side whose speed you are scaling) ^ 2 or 1.5 or whatever you end up wheghting it as
I guess that’s worth a shot. Thanks for your suggestion. I’m gonna hold off marking as solution though, because I wanna see what the other person who said it wasn’t an issue with pathweaver has to say first.
First I would like to separate PathWeaver from trajectory following. PathWeaver is the software that generates paths/trajectories, you can think of this as a “plan” for how things should go. Trajectory following is the code on the robot that is actually adjusting robot outputs to try and follow that trajectory.
Trajectory following can try to handle problems that it can sense. I agree that in broad strokes it should be able to overcome minor damage. You are correct that it can use the gyro to overcome unexpected changes in direction. This however can diminish the peak performance / accuracy. My guess is that if implemented well you will be surprised how well it work assuming the robot is in reasonable driving shape.
Thank you for clarifying their statement. I guess I may as well try it out before panicking. I could also just have the robot drive a bit slower so the curving isn’t as drastic.
Unless there’s anythinge else I should know before trying this out, I guess I’ll check back once I’ve done some testing and I’ll mark a solution then. Thanks for your clarification