NEO motor stuttering with Python code

Yesterday my team started testing with NEO motors (planning on using them at an event this weekend due to weight). We are using two NEOs in PWM mode. We used the Rev tool to update firmware/configure (brushless, current limit, voltage ramp) and test (seemed to be working fine). However, when using our Python code to control the motor, the NEO did not give a consistent output and stuttered violently. This seems to indicate something with our code is incorrect.

With only two hours of unbag time left to diagnose this issue, I was wondering if the community had any suggestions to solve this problem. We think it might have something to do with our code running too slowly (~20Hz) triggering motor safety. Would this cause the observed symptoms, or are there other possible issues? I can provide more details if needed. Any advice would be greatly appreciated!

1 Like

I’ve not tried the NEOs in PWM mode. We’re using them via CAN, and it works great.

You might try creating a program that only controls the NEO and see if the same behavior results. If it doesn’t, then it’s something about your code.

While motor safety could definitely do something like that, I don’t think you should trigger motor safety at 20hz… you should only trigger it at 10hz. And if you trigger it, you’ll get error messages. Also, I believe it’s turned off by default, except for drivetrain motors… so if you turned it on, don’t do that?

In simulation, you might try adding print statements to your code and print out where you call set() on the neo, and see if you’re seeing values that reflect that sort of behavior.

We are using neos with CAN and LabVIEW but also experienced significant stuttering issues. We did the following to resolve the issue:

  1. updated the Spark controllers to the latest firmware.
  2. changed the smart current limit on the Sparks from the default of 80 A to 40 A.
  3. set an acceleration limit in Begin.vi (not sure what the equivalent is for Python) of 0 to max power in no less than 100 ms.

We’ve also experienced stuttering when running live code instead of permentantly deployed code. But that’s because we’re greedy with our loop cycles and we know that.

Typically when I witness a team’s motors stuttering, it’s due to the team setting the motor output in two different parts of their code.

2 Likes

At the risk of asking the obvious, you do have the NEO’s internal encoder connected, right?

The encoder must be connected even if you are not using it for feedback.

.

Does that mean you were running your loops too quickly or too slowly? Could you expand on that because I think it might have something to do with our issue (loop timing)

Yeah we have the encoder cable plugged in, although we aren’t using it. I suppose the encoder connection could be messed up, we can look at that today. Is it possible for the Rev Tuner to work without the encoder plugged in?

The rev tuner will work without the encoder cable, but it will not drive the motor correctly. Also, in order to drive the motor from the tuner, you need to power the spark max externally (from the pdp) as well as have the usbc cable plugged into the computer. I second Virtuald’s recommendation of trying the simulator. It continues to help us separate code errors from cabling/firmware errors.

1 Like

We are running our loops “too” fast. Specifically, they’re too fast when we’re running live and the driver station is doing something in the background but the RIO overhead is just fine when the code is deployed.

We had our motor controller plugged into the PDP of the robot, and the orange USB cable into the controller and laptop. When you say the motor won’t work correctly in the Rev Tuner without an encoder cable, what exactly do you mean? When we tested this, we were able to control the motor to a setpoint output with the tuner. Does this indicate the encoder cable is fine, and the issue is elsewhere?

I’m fairly confident we are only setting the output once per iteration. Today we will test a nearly empty project with just this to be 100% sure.

Yes, I think that is a logical assumption. Unless it is working intermittently, then it sounds like the encoders work.

Yesterday we tested our NEOs again and got some surprising results. One NEO worked in both the rev tuner and code, while the other NEO did not work in either. Furthermore, when we switched the Spark Maxes to power the opposite NEO, the issue stayed with the Spark Max, not the NEO. This seems to indicate that the issue was electrical not programming, and somehow related to the Spark Max.

The specific issue we are running into is the motor stalling under medium load. Even as one motor stalls, the other motor is able to power the same mechanism. Has anyone run into this problem before, or have any troubleshooting ideas?

I do not know if this helps or not, but we ran into some incredibly odd issues with our wiring.

We have two Max/Neo combos powering our lift.

The team zip tied the cables in a bundle when working on the motors, we had to unplug the Neos.

When we re-attached everything, we noticed really odd behavior. It was inconsistent, but frequently was simillar to what you are describing, or running fine if both are connected but always inverting one motor.

The issue was the data cable and power/control cables were swapped when we plugged everything in.

It was an easy fix, but odd.

Thanks for everyone’s help. After reflashing our Spark Maxes and double checking all wiring, we finally were able to get our NEOs working yesterday. Thanks for all your support.

1 Like