MAXSwerve with Vortex not moving properly

Technical Programming
, ,
1

A part of me never thought I would make a topic on cd, but I suppose the canon event is inevitable… So let me make this thorough:

Repository: Robot2.java

Video: Imagur Link

A couple of things to note:

  • We are up to date on firmware for all sparks. All wires used are new and came with the new motors/sparks which have never been used before. We are using an old Rio 1 and a PDP from CTRE. We just bought a Pigeon 2.0 and also have that plugged in to CAN, though I really don’t think that there is much of a difference.
  • We only have 9 IDs on the CAN network, 0 is a Rio 1, 1-8 odd is Vortexs and even is 550 turning motors with an absolute encoder, 9 is a Pigeon 2.0, and 30 is PDP.

Okay story time :slight_smile:

We intend on using MAXSwerve this year, but are currently having some major issues with our motors. Whenever we try to move our motors, they decide they would rather jitter back and forth. My best guess is that this is an issue with the PID, so the rest of this post will explain some testing data that has been accumulated with respect to that.

Upon making two CANSparkFlexs, having one with P = 0 and FF = 1, and the other with P = 0.04 and FF = 1, the one with P = 0 works fine but the one with P = 0.04 start jittering back and forth as seen in this video. D doesn’t affect the extreme oscillation, but reducing the velocity conversion factor (to around 0.00001) in REV hardware client makes it so that the motion is a bit more reasonable, but still not up to speed.

Now while that is strange… what’s really strange about this issue is that it persists even if the settings that were just spoken about were applied but we instead talk to the motor through Swerve.java rather than making it inside of Robot2.java (See Main.java if you are confused on its origins, it replaces Robot.java which we did to try to isolate communication with the motor). Something inside of swerve may be doing logic or changes to the settings on the Flex, but when the same settings are applied inside of MAXSwerveModule (P=0,FF=1), then the motor doesn’t move at all. The PIDFF constants (as explained above) are confirmed to be applied to the motors through REV Hardware Client. The moment we add a P of 0.04, they start jittering again.

One last quick mention is that the Spark Flex documentation/api just isn’t here yet… Which is why I am resorting to you wonderful people.

TLDR:

No matter what values are set to the PID, if it was done through MAXSwerveModule.java rather than Robot2.java, it jitters extremely.

Please let me know if you have any questions, findings and/or similar experiences. Thank you!

  • 4738
3 Likes
2

Terribly important detail I forgot to mention, This error exists only when using the ControlType.kVelocity (or SmartVelocity, anything velocity, etc…) parameter in the setReference method, as the control type position works fine. I’m currently in the phase of forget so I will respond to this very shorty to confirm or deny this statement.

  • Edit: I am back, and incorrect. No matter the setReference ControlType, it still has very choppy PID when trying to get to where it wants to go.
3

You have restoreFactoryDefaults after configuration. This should happen before.

4

Thanks for the notice. I had an oversight there. Unfortunately, inside of Robot2.java there is no call to swerve, and thus, no call to that line of code. This issue still exists in Robot2.java when there is a P value to the motor even though there is a restoreFactoryDefaults before the edits to the configuration. Also, inside of getConfigCommand, the restoreFactoryDefault method is called correctly and even has a Timer.sleep() event to ensure that there are no issues with configurating the motor, which was highlighted as an issue in this thread. If the world was perfect and this code worked first try :crossed_fingers:, then getConfigCommand would have been run, but I have commented it since then because I am going a bit insane. I appreciate the help :slight_smile:

5

This is probably not it, but check your phase wires. If one of them has a poor connection, I have seen it manifest in the same way as a PID issue with much jittering.

1 Like
6

The wiring has been triple checked to be done correctly, and the Neo 550s run perfectly. As mentioned above, when there is a P of zero, then the vortexes run perfectly. I think it has something to do with the ControlType in the setReference, but that’s just an educated guess.

7

Plug into your Spark Flexes/Maxes via USB-C and check if your PID values are actually being set on the motor controller. If not, its likely that you need to do retries on several of your settings to make sure that they are set properly.

There is a lot of CAN traffic on bootup, and config set calls can get timed out. Our library, PurpleLib, attempts to set a config up to 5 times before failing and printing the error. You want to loop and try to set a setting (like kP) and then get that setting to make sure the value is set to what you expect, and if not, loop again.

3 Likes
8

As mentioned in the OP, REV Hardware Client confirms the pid is being set. Even if we set PID through the client, the issue persists. Thank you for your recommendation, but I’m sure there is a way to get this to work without the usage of outside libraries. Have you ran vortexs yet yourself? If it’s just me having this issue I would love to see an example of what works.

9

Have you checked if your encoder conversion factors are being set?

I haven’t gotten to run the Vortexes (Vortices?) yet, but I will somewhat soon :crossed_fingers:

We just got the modules built today with them.

10

The factors were set, and roughly approximated to something around 0.0008, which is the same as what we had in 2023 when we just used Neos to drive our MAXSwerve. Should the factor change from motor to motor? It’s the same gearing reduction and wheel diameter, so I wasn’t expecting it to.

11

ALAS, AN UPDATE (thank you so much @Rezq for keeping me sane through this process and helping more than I can thank you for)

For some reason, simply calling the Pigeon2 constructor in the code makes all of the vortexs jitter and jolt (not oscillate). If the constructor is removed (doesn’t need any calls to it, it is just the constructor) motors get very angry and start going every which way. I would have thought that this was a CAN bus utilization issue since we have never used Pigeon2 before, but I had thought that it would be fine with a swerve drive chassis… Either way, if there is something I should be doing to make the pigeon happier with me please let me know, I tried using the constructor with a can bus name and set it to “rio” because that’s what phoenix tuner x says when looking at the devices, but do I also need to make sure that the neo motors are on that can bus? I am not using a canivore or anything the connection goes from the pdp to the pigeon to all swerve modules and ends at the rio (which has been upgraded to a rio 2 with persisting issues).

12

This of course doesn’t solve the issue of having some motors work while others don’t as shown in the video up above, but my best guess was that the FF set to 1 was just astronomically too high and it only really worked with a P value of 0. This would explain why an extremely low velocity conversion factor appeared to stabilize the motor.

13

This is something we saw earlier when testing an intake prototype (use a neo vortex/spark flex).

It would be great to understand what’s going on here.

14

There have been several reports of this and similar behavior on discord as well.

15

I believe it’s related to the CAN traffic on the bus.

image

CTRE arbitration IDs are higher priority than REV, so they eat the CAN traffic first. REV devices apparently struggle above 65% CAN utilization when CTRE devices are on the bus for this reason - CTRE uses up most of the bus, and REV can’t handle it for some reason. During initiatlization, you’re probably sending out a bunch of CAN messages that don’t play nice with the REV devices.

This is hearsay but it makes sense to me. I’ve heard of REV CANbus issues at high bus utilization before, but I’ve definitely heard about it more with Vortices. I don’t have enough devices to test this theory myself, and it seems a little tricky to do well enough to document. I think it’s up to REV to figure out the specifics.

16

Would this force a team to use a canivore to split the bus if there isn’t a way to make the pigeon/vortex play nice?

1 Like
17

This is not entirely true. Device type is higher in the CAN arb ID than manufacturer, and both CANcoder and Pigeon 2 use a higher device type than motor controllers, so those should be lower priority than REV motor controllers.

To give some more information, we have not done any testing of our own at this time. However, I have worked through the issue with a couple teams to try and narrow down the root cause. One of the minimum reproducible examples reported by a team was under the following conditions:

  1. Remove all CTRE devices from the CAN bus.
  2. Remove all CTRE devices from the robot project.
  3. Call Unmanaged.setPhoenixDiagnosticsStartTime(-1) to disable the Phoenix Diagnostic Server (and also load the Phoenix libraries in the process). At this point, only our enable frame should be sent over the CAN bus.

Additionally, so far we have not had any reports of failures with the SPARK MAX, only the SPARK Flex has had issues.

5 Likes
18

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.