My team has been trying to get our first swerve drive going the past few months using 364’s Base Falcon Swerve and SDS MK4i’s. It’s running fairly well now, with the exception that the drive motor on one of the modules [2] is running 5-6cm/s faster than the others at full speed, which is enough to make it drive a very noticeable arc when driving in robot-centric mode, and in field centric, it turns until the robot is at a 45 degree angle to the direction it’s going with the faster module in the front. It also drifts to the side while trying to make it drive straight while turning. Here’s the link to our github:
https://github.com/BlueCrewRobotics/FrenchToast
We’ve tried pretty much everything we can think of, including making sure it’s not trying to rotate (like if the joystick was drifting) and that it’s telling all the motors to run at the same speed, and driving it in closed-loop. Any insight would be greatly appreciated.
We’ve had a similar issue with our mk4is. Will be watching this thread.
I didn’t look at your code yet, but this is most likely a mechanical issue.
- Check that all four modules spin freely and that one module isn’t easier to spin than the others.
- SDS has multiple gearing options for the MK4i modules (L1, L2, L3, and alternate spline gears). Is it possible that you don’t have the same gearing in all four modules?
- Try a simple robot program that just runs all four drive motors at 50% duty cycle. Do the wheels turn at about the same speed? If they don’t, something mechanical isn’t right or a motor is misbehaving.
In theory this line should have taken care of that:
I would check around to ensure swerve module states are behaving as expected around there.
I don’t think SwerveDriveKinematics.desaturateWheelSpeeds would help if one wheel is running faster. It could be the problem if some wheels appeared to be running slower.
Desaturating makes sure that no wheel is commanded to go faster than it’s max speed. If one module would exceed the max speed, all modules are scaled down. Without desaturating, a wheel that is being requested to exceed it’s max speed would appear to run slower, in relation to the other wheels.
In addition to what everyone else has said (especially to try a simple, non-swerve-library program that runs all motors at 50%!), it’s good to make sure the angle offsets for all of the modules are set correctly. You can bypass this temporarily by aligning them by hand.
Remove as many other factors as possible to isolate the problem – this is the key to debugging anything.
This is a good case to make a point of: if you’re not sure why something is behaving weirdly in open-loop, you will have a bad time trying to close the loop around it, or it will come back to bite you later.
@usbcd36 has a good point, verify you are seeing what you think you are seeing. I assumed you looked at telemetry to know that one wheel is running faster the others, but I shouldn’t assume. It could be a different problem, like misaligned wheels.
We aligned them by hand to run sysid to tune the KS, KV, and KA parameters, and it drove in an arc then too.
I used print statements to print both the speeds in the swerveModuleState that each module was being sent, and what they were actually running, when trying to go straight, all of them were set to the same speed, all of them were actually running a bit slower than they were being told. 3 of the modules run slower by a very similar amount, and the other one runs a fair amount closer to what it’s being set to, and is therefore faster.
Originally (just from watching it’s behavior) we assumed that one of the modules was running slower, as it would turn until it was at a 45 degree angle to the direction it moved and then stop turning. Running it the opposite direction then caused it to turn 180, so that the same module was always behind all the others, but after checking their speeds, we saw that the module diagonal to the one we thought was slow was actually faster than the others, which still explained it’s behavior.
I will try running all the motors at 50% like you suggested, but I probably won’t get a chance to until Tuesday. I can also post a video of the swerve and what we are reading from the motors then as well, if that would be helpful.
Thanks for the suggestions!
We were unable to meet for almost two weeks until today due to storms and the holidays, but we did run some tests today:
-
We ran a simple program that just ran all the motors at 50% output and printed their speeds with all of the wheels off the ground, and the one motor was still faster.
-
We took all the drive motors out of the swerve modules so that there was no load on them at all and ran the motors again, and the one motor was still faster.
-
We swapped the drive and steering motors on the faster module, to test if it was the motor controller being weird, and the new drive motor was, again, faster than the others.
Then we saw that all of the slower drive motors are plugged into our PDH in a row (ports 15-19), and the faster drive motor is plugged in to the other side of the PDH (in port 9) all by itself other than the cancoders and one steering motor. We ran out of time today, but tomorrow we’re going to reorganize the wiring to balance it more. Does anyone know if/why exactly this would make a difference (i.e. do 15-19 all draw from one circuit, and 5-9 have a different one), and if this is why we are having issues, what’s the best way to have them plugged in? (i.e. all together in one group, or spread out)
Can you clarify,
After the swap, the motor in the drive position^ was running faster?
^(previously was the steer before the swap)
Question (that would probably be answered by looking at the code) : you running Falcons, Neos…?
Yes, the motor that was previously the steering motor but is now the drive motor is running fast, and we are using falcons.
Well this would imply that the issue is deeper than the swerve lib.
Can you try different CAN IDs for that drive motor? That would involve some code tweaks but may help isolate the issue further.
First off, it would be very helpful to know the magnitude of the speed differences – 10%? 20%? 1%? Were these different while the motors were installed in the modules, versus running free?
Assuming that the issue truly moved from one motor to another, and isn’t just coincidental (which it could be!), you have a few things to look at and check now. These are the things I can make an educated guess about, but you have a lot more information about the motor swap, the things you changed, and the things you kept the same – it’s worth taking a critical look and trying to figure out exactly what changed and what stayed the same. Be scientific.
When you swapped drive and steering motors, did you change which PDH ports they were powered from? If not, you’ve seen this issue on two different PDH ports already. Regardless, you might be able to isolate this issue by displaying the result of the TalonFX’s getBusVoltage and getMotorOutputVoltage methods. If getBusVoltage is different for the faster Falcon while that Falcon is running, it implies an electrical problem. If it is different all the time, it implies a problem with the Falcon’s electrical calibration, or perhaps a very odd PDH issue. If getMotorOutputVoltage is different while running, it implies a software/control issue.
Second, on regular MK4i modules, the pinions for the drive and steering motors are the same, but they are at different heights, set by spacer configuration and retained with a screw. If you left the pinions on when you took the motors out of the modules and tested speeds, this is something to look at – are there differences between how you have the spacers and pinions set up on different motors? Did this stack of parts move from the old drive motor to the new drive motor?
Is it possible that, say, the other three drive motors have too many spacers on their shafts and the spacers are rubbing against the face of the motor? This also seems like a long shot, as you’d probably notice the heat and eventual melting of plastic spacers. That said, you might also be able to debug this issue by displaying getSupplyCurrent and getStatorCurrent – if it’s a mechanical problem, the voltages above will be the same, but the three slower Falcons will be drawing more current.
Honestly may just need to graph the signals. (Which is a good thing to do anyway). No sense in flying blind.
Weird that the motors that were plugged in closer to the power source were running slower. My electrical mentor told me that the farther the port was from the power input (channels 9 and 10) the less power they would get. This may be wrong and it could be wired in a loop starting at channel 1 and ending at channel 19 resulting in the higher numbers getting the leftovers from the lower numbers. It could also be a completely unrelated issue from the amount of power they get as some other people are saying.
I really hope your electrical mentor was referring to increased resistance over long wire runs and not trying to suggest different ports will supply a proportional drop in power delivery.
This isn’t quite how electricity works. The “water through a pipe” analogy is a useful one, but it does fall apart beyond basic description.
There are others on here that can supply a much cleaner and accurate description than myself.
So, with more testing via observing it’s behavior, a wide variety of print statements, and three Phoenix tuner, the faster motor seems to run roughly 0.6-1% faster than the others, not a ton, but enough to make driving it annoying, and any autonomous impossible to make accurate. This seems to hold true while driving on the ground, with the wheels in the air, and with the motors out of the modules. For clarity, I will refer to each of the motors by the number of the swerve module they are in (0-3), the motor that’s running faster is motor 2
When we swapped the motors, we also swapped where they plugged on on the PDH, and their can bus id’s. We have since swapped around the wires to different ports, swapped breakers, as well as the can bus id’s with no change.
Using using the getBusVoltage and getMotorOutputVoltage like you suggested, all of the motors reported slightly different bus voltages (after running all of the motors at 50% output for roughly 5 seconds multiple times), on one of these tests, the lowest (motor 0) was 11.8 volts, and the highest (motor 3) was 12.05 volts, while motor 2 was usually somewhere in between.
When we swapped the drive and steering motor we swapped the pinion gear and spacers on them too.
We printed out the supply and stator current for them too, using the same method as when we tested the voltage, after all the motors got up to speed, 3 of them (including motor 2) reported a very similar supply current of around 0.45, while motor 0 (which seems to consistently go the slowest, but not by much) reported a supply current of around only 0.25… which has only been confusing us more.
We also ran each of the motors independently one at a time at 100% output using Phoenix tuner, and used the self-test snapshot. Motor 2 was still the fastest by about 0.6%. Two of them reported a voltage of 12.4, and the other two said 12.44. I can’t remember which motors said which, but that’s a pretty small difference that could just be due to a difference in time between starting the motor and taking the snapshot. Motor 0 was drawing about 3.6 amps, while the others were close to 3.85
We also used a multimeter to test the resistance on the PDH between the input and outputs, on all of them the multimeter flickered between 1.2 and 1.3Ω
I’m hoping to go back tomorrow (and if not, then Saturday) to test it some more, maybe using the DataLog tool (unless there’s a better way?)
Ok. I am just as confused as you are.
imho the small difference in open-loop behavior isn’t the issue – these things vary – the more concerning problem is that running in closed loop doesn’t seem to yield identical results. i’d suggest focusing on that problem. maybe the outboard PID isn’t tuned? looking at your closed-loop code, it seems like maybe the feedforward is too high? can you measure the error that the outboard controller thinks it is maintaining?
another thing to think about is your claim that, in field-centric mode, the “fast” module leads the way. that seems to indicate that the theta controller isn’t firm enough.
another thing to think about is voltage compensation, if you’re using a lot of current, you might be running out of voltage. set the saturation voltage lower to address this issue.