You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One issue I have been seeing quite a lot is where people are using their robot's theoretical maximum velocity and acceleration values for their initial tuning, even when they almost definitely shouldn't be.
This is a problem since there is no clear note that the values given either by the maximum velocity tuner or just calculations are just metrics of the highest values that should be used, rather than the recommended values one should start with.
Views vary as to a good starting point for one's initial tuning of roadrunner, but in my opinion, drive encoder users should start at 30-35 in/sec and dead wheels users 30-40 in/sec, with 180-270 deg/sec for angular. Regardless of what is considered a good starting point, however, I don't believe it is contested that one should not start with values like 50-60 in/sec for their very first tuning, not to mention that almost all autos do not need this high of a speed to complete in time (our 1+5 auto this season only uses 40 for velocity and 43 for acceleration), and any faster movement negatively affects localization performance.
All of this applies to the constraints for angular velocity and angular acceleration as well, where the guide suggests that the values returned by the tuner should be used as the constraints, which again leads to users running much higher constraints than they need or is advisable, negatively affecting localization performance.
What do I think is needed here? I think that first of all, the wording on the velocity PID and feedforward pages, including the other places constraints are mentioned, should be re-written to include a few key points:
Users probably shouldn't use the maximum theoretical velocity to initially tune roadrunner. The values returned by the maximum angular/regular tuners are metrics of the maximum advisable constraints, not the recommended ones.
There are very few situations where the maximum possible speed is ever needed. There are often other limiting factors such as mechanism speed that will prevent running faster.
The faster your drive base moves, the faster your localization will drift in most cases, especially for odometry-based systems. In particular, drive encoder users need to carefully limit their movements and speeds to avoid drift.
Dead wheels are not immune to drift either, and going slower is almost always better for consistency.
(All of these points apply to the angular constraints as well)
Another great place to put a small warning would be in the Drive Constants file returned by the configuration tool on LRR, above the fields for velocity and acceleration. This will be seen every time a change is made to the constraints by new users and is harder to miss than a note on the website.
These are just my thoughts for changes to solve one of the issues I've seen from people seeking assistance so far this season, whether it be from velocity tuning issues caused by constraints being too high or otherwise. At this point in RoadRunner's life, there are many more newer and perhaps less experienced teams who are attempting to tune their drive bases, and as such it may be a good idea to start distributing some of the advice previously given through community platforms (Reddit, Discord) to this guide, since it is clear it that this is a very common problem.
The text was updated successfully, but these errors were encountered:
One issue I have been seeing quite a lot is where people are using their robot's theoretical maximum velocity and acceleration values for their initial tuning, even when they almost definitely shouldn't be.
This is a problem since there is no clear note that the values given either by the maximum velocity tuner or just calculations are just metrics of the highest values that should be used, rather than the recommended values one should start with.
Views vary as to a good starting point for one's initial tuning of roadrunner, but in my opinion, drive encoder users should start at 30-35 in/sec and dead wheels users 30-40 in/sec, with 180-270 deg/sec for angular. Regardless of what is considered a good starting point, however, I don't believe it is contested that one should not start with values like 50-60 in/sec for their very first tuning, not to mention that almost all autos do not need this high of a speed to complete in time (our 1+5 auto this season only uses 40 for velocity and 43 for acceleration), and any faster movement negatively affects localization performance.
All of this applies to the constraints for angular velocity and angular acceleration as well, where the guide suggests that the values returned by the tuner should be used as the constraints, which again leads to users running much higher constraints than they need or is advisable, negatively affecting localization performance.
What do I think is needed here? I think that first of all, the wording on the velocity PID and feedforward pages, including the other places constraints are mentioned, should be re-written to include a few key points:
(All of these points apply to the angular constraints as well)
Another great place to put a small warning would be in the Drive Constants file returned by the configuration tool on LRR, above the fields for velocity and acceleration. This will be seen every time a change is made to the constraints by new users and is harder to miss than a note on the website.
These are just my thoughts for changes to solve one of the issues I've seen from people seeking assistance so far this season, whether it be from velocity tuning issues caused by constraints being too high or otherwise. At this point in RoadRunner's life, there are many more newer and perhaps less experienced teams who are attempting to tune their drive bases, and as such it may be a good idea to start distributing some of the advice previously given through community platforms (Reddit, Discord) to this guide, since it is clear it that this is a very common problem.
The text was updated successfully, but these errors were encountered: