-
Notifications
You must be signed in to change notification settings - Fork 857
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to use StandardTrackingWheelLocalizer? #25
Comments
Yes, seven quadrature encoder ports are required for the seven quadrature encoders required by three tracking wheels and 4WD with feedback. You can still use three of those motor ports for other mechanisms, but you will have to use current monitoring, I2C encoders, or another sensor for feedback. This is entirely possible with road runner; however, whether it is feasible for your team depends on the design of your robot.
The localization method doesn't really affect the tuning procedure. If you haven't tested your localizer, you should use
In that case, |
Thank you so much for your quick responses. I think this makes sense.
Based on your feedback I will change my question to, is it recommended/required to have encoders for the dead tracking wheels and the DC motors? While we have the ability to operate other motors with alternate feedback, we would like to not have to tackle this right now. However, if it is the only way to get sufficiently accurate motions with Mechanum wheels, we will need to figure it out. This is our first season using Mechanum wheels so it is a bit of a learning experience :) |
@rbrott I messed up my last comment, it is now updated correctly. |
Neither is required per se. Since you have the tracking wheels already, I would stick with those and try without drive motor feedback. |
Note to others that might want to do something similar. If you don't plan on using the built-in PID, you need to remove @rbrott Thanks again, we are getting really close to having something working. Our problem now is turning. It seems like the I am not sure if we should be working to correct our track width or converting the localizer to use the IMU. It seems like if we convert to using the internal IMU there is no point in having the third wheel? If we should convert to using the IMU, where might we start this process. In the TrackWidthTuner it references we should change the localizer, but it really isn't clear. PS: When we are all done, we would be happy to create a PR with some updates to the comments. Let me know if you would be interested in that. |
Have you tried validating that the localizer works correctly with
Yes, three tracking wheels and an IMU usually results in an overdetermined system. You could use least squares or a more advanced technique to utilize the information (of course you'd have to write your own localizer). Alternatively, you can just drop a wheel.
If you're just dropping a wheel, take a look at
Sure, I'd be happy to hear any feedback on the tuning instructions and/or general documentation. You can also PR https://github.com/acmerobotics/road-runner-docs. |
As we understand it, using the 3 wheel localizer is more consistent than using the IMU, for mechanum drivetrains. So we are planning to get the three wheel localizer working. Is our understanding correct that the 3 wheel localizer is better than just an IMU and 2 wheel localizer?
We have run Our initial value for Again thanks for all your help! |
Unfortunately, I have no personal experience with tracking wheel localizer (only drive wheel localizers). Anecdotally, some prefer 3 wheel localizers because the IMU has additional latency and only updates at 100Hz anyway.
That comment cautions against using drive encoders for computing the heading. Neither tracking wheel localizer falls into this camp nor does the default drive encoder localizer (it uses the IMU). The pure drive encoder localizer depends on the value of the track width hence the prohibition. |
We are generally good on how to use the sample now. I am going to leave the issue open so I can remember to send you a pull request with updated comments/documentation. I do have a few other questions/issues. I am going to open other issues for those. Below are the things we think should be address (just so I have it somewhere).
|
OK most of those sound like reasonable additions/clarifications to the documentation.
|
What is the reason for the In our scenario we configured all of them the same, which is why I thought they should be the same. |
"Tracking wheels" are dead wheels, not driven wheels (there's no reason to use a tracking wheel localizer for drive encoder localization; that functionality is built into the drive classes). Teams regularly have different encoders, gear ratios, and wheel radii for their dead wheels. I'd be surprised if your driven wheels have exactly the same parameters as your dead wheels.
Not necessarily. Drive wheel parameters are still required for proper open-loop/feedforward control even if you only use dead wheels for feedback. |
So in our configuration, we don't have any encoders on the drive wheels. Given this, we configured the |
Yes, that's incorrect. Those parameters should always refer to the drive wheels; many are used for feedforward. |
I guess it is confusing to me. How those would work if we aren't getting feedback from the encoders. How would you even calculate them since here is no feedback? |
You'll want to tune the feedback with the drive encoders plugged in. If your motors do not have encoders, you'll have to tune it manually with the dashboard with |
Ahh... So does the following sound like a reasonable sequence of actions?
|
That seems more-or-less reasonable. Have you checked out this list? |
Yup. That is the process we have been using. It seems like our main remaining issue is that we were not tuning the kV, kA, kStatic, and TRACK_WIDTH for the driven wheels. We did it based on the Localizer data or something (we haven't had the drive encoders plugged in). Though, with all of the issues we are considering just using the encoder ports so we can just use the built in velocity PID. Our first competition is next weekend :) |
@rbrott two more questions.
|
The units of velocity, acceleration and jerk are in/sec, in/sec^2, and in/sec^3, respectively (keep in mind you can substitute any distance unit you like; the quickstart tacitly assumes inches).
|
So is it that when an alternate localizer (i.e. StandardTrackingWheelLocalizer) is set, the error in the drivetrain PID loop is then derived from the position the localizer returns instead of the drive wheel positions, which renders encoders on the drive motors unnecessary (or are there still velocity control benefits)? We are just recently beginning to understand the process (related); it would be great that we do not need seven encoder ports just for the drivetrain. |
The localizer determines how the robot's position is computed. The default localizers use the drive wheel encoders. This position is used by the various followers, including the PIDVA follower. This is independent of the onboard/built-in motor velocity PID that is recommended for drive encoders if available. If you need to reclaim encoder ports, it's probably better to sacrifice velocity control (i.e., remove the drive wheel encoders). That said, velocity control is useful in addition to just position control; in essence, it helps prevent velocity error from "spilling"/"transforming" into position error. |
So if I understand correctly, the goal of both drive characterization with
Would you elaborate in the distinctions between position control and velocity control in the context of roadrunner? We have been visualizing PID in 1D scenarios, and imagine that the controller makes changes to the velocity based on the error computed from position—how are the two quantities controlled separately? We are probably not familiar with how the followers work, and how they use position—some explanation would be very helpful! |
Yes, that's the essence of their function. The goal is to translate wheel/shaft velocities into motor voltages. This can be accomplished with feedforward/open-loop control based on the (idealized) linear relationship between voltage and velocity (this can be augmented by considering acceleration and static friction through kA and kStatic), or it can be accomplished with feedback/closed-loop control by manipulating the voltage to achieve the desired velocity. The later feedback mechanism is preferable due to its robustness to changes in input voltages, friction, and other unmodeled effects/dynamics.
The position and velocity controllers form a cascade where the output of the position controller becomes the input for the velocity controller. In this case, the position controller manipulates velocity to affect position error, and the velocity controller manipulates applied voltage to affect velocity error. The trajectory followers are controllers that compute the robot's velocity and acceleration from the current trajectory and current position (they fall into the category of reference trackers). Some of the followers in Road Runner use PID with VA feedforward terms (the holonomic PIDVA trajectory follower source is pretty readable and understandable at a high level) while others use more sophisticated techniques. |
@rbrott thanks again for all of your help. I am going to continue to keep this open so it reminds me to work on some suggested improvements to the docs (not sure if there is a better way to manage that). We still have problems with the tuning, but I am going to open a separate issue about that. @Calvin-Xu thank you for your addition to this thread, you asked some great questions that helped me understand this from a different perspective. |
@EddieDL , We are also embarking down this path, and did these steps work for you? You also mentioned that your encoders were not on center. Were you able to get them to work with a non 0 x position? |
It isn't 100% clear how to use the StandardTrackingWheelLocalizer. I have read issue #24 and I have gone through the examples and the documentation. However, I am still not sure on a few things.
getWheelPositions
,DriveConstants.TICKS_PER_REV
,DriveConstants.WHEEL_RADIUS
, etc.Also, in my situation we are not able to install our lateral odometery wheels inline. In our case they are offset from the center line of the robot. What measurements should I use to utilize this configuration?
Thank you for any help you can provide.
The text was updated successfully, but these errors were encountered: