Have other teams successfully implemented swerve drive with position control for drive motors instead of velocity? What are the drawbacks to this approach?
Looking at the way the systems work, it seems like using positional control for the drive wheel position would allow for more precise control over the robot’s location, and strikes me as something more akin to what one would see in the industry (moving information and responsibility to the motor controller as possible to do what it’s there to do). I ask because we have a team member who is insistent that such a thing is not only ill-advised but flat-out impossible, and is attempting to create a rift in the team (an issue I need to deal with) over this approach, (but is unable/unwilling to articulate reasoning). Is there something to this calculous that I am missing
I get that speed control fits better with the idea of teleop, (we are planning on integrating some autonomous driving WITH teleop) and that we will need to take into account the robot getting hung up on walls etc. Is there another angle we need to consider this from?
Biggest question in my mind : what would be the plan for converting from teleop joystick inputs to robot position? Normally teams have the joystick magnitude scaled to wheel speed … or some even run open loop duty cycle for the drive wheels based on joystick magnitude. I’m not sure I’ve seen any teams use position control (except maybe switching to it for holding the robot in place when stopped?).
I’ve seen some ideas to motion profile all drive base motions, converting joystick direction magnitude into desired-position-in-the-future via some sort of calculations. As a team that has tried something similar just for robot rotation, it’s not easy to tune to something that feels as good to drive as just having stick magnitude scaled into robot velocity.
If you are going to leave all turn motors facing the same direction, and you wish to travel a certain distance without rotating the robot at all, I could see where position control might work. Same if you wish to rotate your robot without changing position. But if you wish to move and also rotate your robot at the same time, I am not sure how position control would work, since the combination of translation and rotation require precise vectors for each wheel (both direction and speed). Unless you are going to come up with some sort of path planning algorithm that determines the position of each motor for each time slice.
Assuming the problem is “Drive X meters”, and you keep your azimuths pointed in the same direction the whole time, it’s possible this will work fine for small X.
For Large X, you’ll want motion profiling, which now means you aren’t just doing position control.
For anything other than a straight line, this technique will stop working very quickly.
Rewording my take from before… You mentioned some opposing ideas currently floated. Do you feel your team is on the same page about your primary goal?
The reason I ask is because teams are gonna look at this problem differently. Maybe you’re looking to just learn about the basics of motor control. Maybe you’re looking to score lots of points on the field. Maybe you’re looking to make a robot that moves fast and looks cool. Maybe you want to try something new and innovative in the hopes it becomes a competitive advantage.
All approaches are valid for one reason or another, but not all lead to the same answer on technical direction to take.
Most teams today are doing Velocity based PID Controllers built around motion profile of the drivetrain characteristics.
I recommend this Championship Motion Planning conference video presented by 254 and it discusses a lot of different techniques teams have used over the years.
One of our students had a very good way of describing the way to translate the joystick input to motion control: a carrot on a stick: the robot keeps trying to drive to a point on the field, and you keep moving the point, but limit how far you move it away from the robot. Every command cycle you update the target of the motor controller perpertonaly concerning the joystick input. Imagine that pushing the joystick to the edge in any direction maps to moving the center of the robot to a point 2 feet away from the current center for the robot. pushing the joystick halfway maps to moving the center of the robot 1ft away from where it currently is. Letting go of the joystick essentially drops the “carrot” on the field and the robot goes over and stops on it. To make this work we need a motion profile that starts at around 100%, otherwise, as I understand it, we would keep restarting the profile and never get above the throttle/torque value at the beginning of the profile. Aside from that I am having a hard time seeing a downside, given that it also makes driving to specific locations on the field that much easier.
As to rotation, I see what you’re saying, but my understanding is that we can typically count on the rio command cycle happening >>10/sec so we can continuously account for error and re-calculate our vectors to adjust. (wheels aren’t our only means of tracking our progress) As I understand it then, over short distances, this should lead to large enough differences in location setpoint for the drive wheels that we end up approximating those positions and timeslices as we go. (or close enough for wheels on carpet) Clearly, longer distances could be an issue, but if our joystick control is never trying to move the robot more than “2ft”, there is no such thing as long distance, and for autonomous actions, I would expect we could manually ensure our plans have a minimum angular velocity for the robot so we avoid that situation.
A large piece of what we want to showcase is our motion tracking system, which is based around some often overlooked hardware that is giving us very good results for field positioning, and we are hoping will give us the ability to include some autonomous action during the matches, not just at the beginning.
As mentioned by others, I think you would want to do this with a motion profile. This would mean you have planned motion over time, and this includes position and velocity. If are using a motion profile, you’re going to be replanning on every iteration, based on driver input, with the expectation that you don’t ever reach the setpoint or the robot will stop. With this solution, aren’t you just driving with velocity anyway, since you’re not actually planning to reach the position setpoint?
Based on the way you wrote the question, it seems like you’re planning to drive each wheel in position mode, not running a control loop over the pose of the robot. Again, as mentioned by others, this means you have to plan for rotation and the positions of the wheels will vary based on the rotation and translation vectors.
It seems like your solutions are somewhat mixing the idea of running a control loop on the position of the robot vs. running a control loop on the position of each individual wheel. Most likely what you want to do is run the loop on the position of the robot. You can use profiled PID controllers (which use position and velocity over time) to drive straight to a position. You can also use tools like PathPlanner or Choreo to plan complex paths that don’t just drive straight between waypoints.
