Has anyone gotten the REV NEOS and Spark Max to perform acceptably in closed loop velocity or position control yet?

Technical Technical Discussion
1

I’ve only spent about half a Saturday trying to write code in LabVIEW based on REV’s examples and setting up a test rig for the Neo’s and Spark Max’s.

Neo’s are clamped down with no load. Thus far there is a laggy, jittery behavior I get every time I try to control via closed loop PID. Under percent Vbus, it is ok but it still seems to jitter. I’ve updated to the latest API’s for labview, firmware and client for the Spark Max.

I’ve tried the Spark Max connected to CAN and PWM. CAN seems to be a bit more jittery. But it’s there with PWM as well. It just seems to send a random stop single.

I saw posts on the internal hall effect sensors sending zeros randomly. I believe REV is working on this problem. I sounds like a fix is coming soon.

Just wanted to know if someone’s gotten this to work. Or if I should stop trying and wait for updates from REV.

Thanks.

2

Check your driver station for packet losses. We were getting similar jitters until we discovered one of our laptops wasn’t playing nicely with the network. The issue went away immediately when we switched to a different computer that didn’t have the same network issues.

3

I’m connected directly to the RIO via USB cable. Shouldn’t have network issues via USB correct?

So you’ve been able to get closed loop controls working?

4

We still got network errors while connected over Ethernet with the problem laptop. Can you check the Lightning Bolt tab in driver station? The first number on that tab is network errors, if it’s not zero, you might be having the same issue.

5

Using the “velocity closed loop control” example in the rev github (c++), I was able to get closed-loop pid control working. It came preloaded with constants that seem to work fine for an unloaded motor, so that made the bench to test a little easier.

There was definitely a bit of jitter when the joystick was zeroed, but watching the smartdashboard output showed the test code provided no deadzone for the joystick, so if it wasn’t perfectly zeroed(like well-used joysticks tend to be), it obviously tried to keep running.

When running, I didn’t feel any variation in motor output speed (just a nice steady hum)

6

You can check out our repo on Github to see how we’ve implemented closed loop position control in the Elevator subsystem and the setElevator command

7

So I check the lightning tab and we did have losses.

I just tried a second laptop. This time, connected wirelessly. And no losses, and the motor stayed jitter free for 30sec that I just tested it which was 10x more stable than it was before. Thanks for the advice that seems to have solved it.

8

Can you tell me what your preloaded gains were? Labview doesn’t seem to have those preloaded?

9

We haven’t bothered tuning yet as the mechanism isn’t ready, so it’s just a free spinning motor. Just using P=0.001 and everything else at 0 to start with.

Also make sure you set max and min output to 1 and - 1 as they default to 0.

10

You can find them here:

11

What is the izone setting? Is that just the max error summation from the I term?

12

It’s the maximum distance from your target that the I term (accumulated error) will be included in the calculation.

13

What does the Izone do? I’ve heard of limiting the I component to reduce overshoot. But this doesn’t seem to do that.

14

So I is used to correct steady state error, basically you system is tuned such that it gets almost to the correct spot and doesn’t oscillate, but is still off by a bit. This is where I is useful as even a small error over time will cause the I term to build up.

So you don’t need the I term in the output calculation for most of the movement, just a small zone around the target. By limiting the I inclusion to this small zone, you can tune it to be quite responsive to the small steady state error you are trying to correct without affecting the rest of your tuning.