Hello last week our team for the first time got a swerve drive to work, and now we’re looking to start to prepare for next season. So Ii have decided to start to work on autonomous, ive had a look at path weaver but ultimately came down to decide to use path planner. I got the robot to follow the path but it will always undershoot and never reach the correct distance (e.g. i tell it to drive 1 meter it drives 0.88-0.93 OR i tell it to drive 2 meters it drives to 1.3-1.4). Its very confusing the code is linked here please let me know if you have any ideas. Also we used YAGSL code.
Hello! Sounds like an exciting project.
These symptoms usually have many possible root causes. There’s a lot of things you’ll wanna check to help drive to which specific root cause is creating your problem.
One of the most effective tools you can use is Glass, specifically it’s Plotting feature.
Make graphs of the robot doing it’s thing and showing off the symptom. Specifically, you’ll want to see plots of desired and actual things on top of each other, with the same units.
For example, produce a plot of desired X position and actual X position on the field. Or, make a plot of desired wheel rotational velocity and actual wheel rotational velocity.
These things help you slice the large problem into smaller ones.
- Check if the actual (measured) value is correct. Manually move the robot, measure with a tape measure, and ensure your sensor (and its processing) is returning the right physical values.
- Check the desired (commanded) value is correct. For example, If you wanted the robot to travel 3 feet in 3 seconds, you should see the velocity averaging around 1 foot/sec.
- Check that Actual value converges to the Desired value quickly and nicely. If it doesn’t, it’s time to look at the closed loop controller that Desired/Actual feed into.
- If all of the above check out, look downstream. What’s the output of this controller? What does it feed into?
Rinse wash repeat till you find the right answer.
So that being said. What’s your next step? What plots could you produce to start to debug the issue?
Thanks I’ll have a look into it tomorrow
Hello!
Confirm your diameter for your drive wheel, any wear will show in the form of consistently missed auto’s.
You should plot the velocity of the drive motor desired and current state first and try to get that as close as you can to an erratic driver while the robot is off the ground, likewise for Angle motor PIDs.
Then you should use the PathPlanner Telemetry tab and a simple path which goes straight and turns and tune the discretization until you reach a point of diminishing returns.
Then you should tune angular velocity correction until the PathFollowing is nearly perfect.
This should take a day or 2 to do but the robot will perform amazingly by the end of it!
This 100%, ESPECIALLY if they are colsons as they wear down far more vs roughtop on a wheel. Also double check the gear ratios, just in case you are using a 10t pinion in reality, but the code assumes 11t.
You will NEED to revisit these numbers if you put new wheels on the modules for next season, changing gear ratios will also need a revisit.
Already checked over this we have brand new colsons that we’ve only used maybe once or twice on rough concrete (because there isn’t much room to test anywhere else). Also double checked our gear ratios and seems to be correct we have L2 mk4i so I set the value to 6.75 I belive
Colsons behave differently depending what direction they drive on carpet (long complex story). Roughtop is more consistent.
Have you tested your distances on a different surface / different directions on carpet?
One other thing to consider is do you have achievable max speed and acceleration on your constraints. If you have your max speed set to free speed max your robot will never achieve that speed put path planner will make trajectories based on that speed and acceleration.
So if I had the max speed on path planner set to 1meter but in code max speed was set to 0.1 meters it wouldn’t reach the final destination?
Not sure what you mean by max speed in the code. I was referring to physical max speeds vs the path planner constraints. But I’d you have code restricting your top speed that would also apply.
The generated trajectories are states at a specific time slice. If it generates a trajectory you can’t physically achieve you won’t reach the end of the path by the time the trajectory is finished.
It would, bc the code one is slower than PathPlanner’s AFAIK.
I would think if path planners constraints were lower than the max speed of the robot then path planner would succeed (not overshoot) the goal because it would plan a possible path it just wouldn’t be as fast as possible.
You’re right, my bad! I was thinking of acceleration. We had some problems last year that took a meeting to debug.
Hi, could you clarify on what angular velocity correction accounts for? Does it aim to factor out the delay in when the gyro reading was taken vs when we are using that gyro input? Is it something as simple as robot_rotation.plus(angularVelocity * angular_velocity_correction_constant)
Also, is tuning the discretization and angular velocity correction primarily to help with translating while rotating?
Thanks in advance!
Here is the last post I made about it, sorry for not wanting to rehash it rn!
We are having a similar issue with all of our pat I’ll upload our code here, would anyone be able to browse through it and check to see if they see anything obvious that could be corrected or tested? Thanks!
554 src.zip (50.6 KB)
Thanks for all the help got it working!
Now, I’ve ran into two different issues, first is how do I change over to using “autos” instead of “paths”? And when the robot gets to the final position it overshoots and then redirects itself, is that normal and is there a way to make it drive less extra?