I was kinda hesitant to post this here since the problem seems too large yet specific to be dealt with over the Internet, but maybe I can get some best practices tips or some examples of actual code from other teams that did it.
When just starting out on motion profiling I was hoping to find an autonomous system that worked better than just PIDs. Last year we just used PIDs and the turning was inconsistent (would turn + or - 7 degrees or so of target on a bad round), and we had no way of driving in anything but straight lines.
I read the Talon SRX Motion Profiling Reference Manual from CTR and Team 900’s Positional Motion Profiling for FRC. I generate motion profiles either from CTR Motion Profile Generator or from Jaci’s Pathfinder. The basic framework of the code set-up is from the Motion Profile example code CTR has on their github repository. I calculated my f-value by running the robot full speed on carpet and then dividing 1024 by that full speed (in native units per 100ms).
The problem is that it horribly inaccurate. It follows some sort of motion profile (ramping up and then ramping down), but always way short of what we’re telling it to do. If we use a PID to help it out, it goes a bit farther, but honestly I think just a normal PID itself was better. Sometimes the error will go out of control randomly too and the robot wont stop.
We succeeded in getting it to drive a set distance in a straight line, but we could already do that. We would really like to get the robot to turn in place a set number of degrees consistently or follow a curved path to like 4 meters forward 1 meter to the left.
Some things we’ve tried to make it better are fiddling around with the f-value, max velocity, max acceleration, max jerk, thinking that maybe we set one of these to an inaccurate value or to something the robot could not accomplish, but nothing seems to be working too well.
Reading this, I realize it’s all horribly vague and you guys probably cant fix it without the code and testing the robot yourselves, but perhaps you have some insight or some code I could look at? Maybe I set it up wrong. Idk.
Thank you for your time.
It sounds like you just have a PID tuning issue. Mind describing your robot’s drive system (motors, gearing, wheels, wheel base width, drive style), and PID constants? Are your encoders working reliably? Try running it slowly and graphing the PID error for both sides of the drive base.
I thought the PID was more for the fine-tuning stuff though. Our motion profile currently only carries the robot around 50% of the way towards it’s goal (if that sometimes).
I’m a bit inexperienced in the physical aspects of the robot, but I’ll try my best. We use 4 SIM motors in a drive-train system. The wheels are rubber and have a 6-in diameter. The wheel base width is 25-in. PID constants we’ve been changing a lot and didn’t really settle on one for long, but the P was typically around the range of .01 and I .001, with 0 d.
One magnetic encoder has a green light and the other a yellow. I wouldn’t say they’re 100% reliable, but normally are decently accurate.
Hm, trying to spin on a dime, telling both sides to turn in opposite directions, while graphing the error, showed a quick rise to around 2000 error on both sides and then the profile ends.
Thanks for the help btw.
I tested the motion profile using a breadboard similar to yours a few months ago. A few suggestions that may or may not apply to your case:
- A decent P value is needed besides F value. In my case, P was set to at least 0.5. Actually P = 2 was used. My guess is there was too much friction around.
- F value need be increased from initial calculated value by experiment in order to make the robot trajectory closely followed the calculated trajectory. A chart with actual and calculated trajectory will be very helpful.
- The effective wheel base need be empirically determined in order to turn the robot consistently to the desired angle using PathFinder generated profile. The effective wheel base is not same as the physical length of wheel base. In my case, it is much larger.
- To further improve the accuracy, the effective wheel diameter need be empirically determined. In my case, the effective wheel diameter is about 6% smaller than the physical wheel diameter.
You can search this message board. There are many good posts that tell you how to do these empirical measurements.
Hope this helps.
Well, this points me in new directions, so I’m happy 
Thank you! It’s very much appreciated.
If your motion profile is only getting you 50% of the way there, you should be tuning that.
I would highly recommend setting up a system to allow you to graph the distance/time of both the real robot and the motion profile’s target - I’ve found that that’s almost essential for tuning, and is a really useful thing to have in general.
PID/error values aren’t useful unless you specify the units that they’re in - Are you converting from encoder ticks to a physical value? If so, is it distance (in, m, ft, etc) or angle (rad, deg)? What is the time unit?