Yesterday we were successfully testing our lift mechanism. We have two Spark Max and Neo motor controllers connected to gearboxes.
Today, we’re seeing current spike up to about 40A (via the driver station log viewer and PDP output), and then almost immediately dropping down to about 10A. We have no idea why that is.
The motor controllers are not reporting any faults.
We updated the firmware yesterday before we tested. We upgraded to the .33 code tonight as a last ditch effort to try something else. We updated our APIs too.
We created a new basic robot program just to drive the motors on our mechanism. We still see the same problem.
Any ideas? Here’s a picture of the driver station log showing the peak and then drop:
I’m not sure I entirely understand what your question is, but I’ll try to answer it anyways.
Are you seeing a 40A spike right when you start moving the elevator, but then once it’s up to speed it settles down to 10A? If that’s what it is, then that sounds normal to me. When accelerated from rest, motors tend to spike in current draw for a fraction of a second. This is called “inrush current”.
I feel like that sort of addresses the body of your post but I don’t think it speaks to the title. Please let me know if that helped or if you need further clarification on a different issue.
EDIT: I think I see the issue. When the current spikes occur, you lose battery voltage (which is normally what happens). That would cause your lift to struggle to work since it’s dropping belowo 9V. Try replacing the battery and see if the issue persists. Also note that the scale for the PDP amperage is on the right side of the graph not the left side.
Thanks for the response, and sorry for being unclear.
The problem we are seeing is the motors stall when our robot is about 12" off the ground. That is the red and blue spike you see on the graph. There is no movement after the robot gets 12" off the ground. We’re also perplexed by the fact that both motors are showing basically identical draw.
We don’t expect the current to drop to 10A if the motors are stalled. If anything, we think the current should go up. It doesn’t appear to be a code issue. We’ve factory reset the Spark Max controllers too.
I saw your edit while replying. We’ll try a new battery tomorrow and see what it does. You are correct, PDP amperage is on the left. We put the motor controller amperage on the right.
I don’t think that’s it; based on the description, the lift is running after the second voltage drop, where it’s hovering a little above 11V. That should be okay.
As far as I can tell, the scale on the left isn’t related to amperage at all. You should be reading the scale on the right, which means you’re spiking up to 150A, then dropping to 40A for a few seconds, then going down to 0A. To clarify, the second spike climbs from the ground to 12’’, then the red and blue jitter is the current draw while at 12’’, and then you shut the motors off?
In addition to the questions asked above, I’d also like to ask what voltage you’re commanding to the NEOs. The SPARK MAX current limits (which are enabled by default) measure output current as far as I’m aware, not input current, which means the amperage you see here doesn’t directly correlate to hitting the current limits without knowing the percent output.
EDIT: Though now that I think about it, it seems you might be tripping the 40A breaker, depending on how fast they reset (I don’t have much firsthand knowledge there).
I totally screwed up the part that you quoted. The Neo amperage is on the left and the PDP amperage is on the right.
To clarify, the second spike climbs from the ground to 12’’, then the red and blue jitter is the current draw while at 12’’, and then you shut the motors off?
That is correct
I’d also like to ask what voltage you’re commanding to the NEOs
I don’t believe the programmers told the Spark Max a specific voltage to send to the Neos, I believe they are using +/- 1, after having testing fractional values. We have tried ramping to 1 over 1 second with no noticeable difference.
EDIT: Though now that I think about it, it seems you might be tripping the 40A breaker, depending on how fast they reset (I don’t have much firsthand knowledge there).
I thought about that too, and my quick perusal of the datasheet on AndyMark indicates it could trip as fast as .5 - 1.1 seconds at 300% overload, and longer the less overload there is. However, I don’t understand how the current would then drop to ~10A. Why wouldn’t it be 0, then cycle back up to a very high number, and then cut out again? We can try swapping them tomorrow to see if they are faulty/marginal.
To reiterate a question from above, has current limiting been set on the Spark Maxes? We had a similar condition with a drivetrain, but setting current limiting completely removed these issues. Try it, there’s a high chance it might fix your issue.
Just to clarify, the PDP current is on the right, the left scale is not a current measurement at all, and the driver station log does not log the NEO current directly. The scale on the left is for Packet Loss %, CAN %, and roboRIO CPU %. You can log the NEO current by reading it in your code using the getOutputCurrent() function.
So that analysis is correct that the current is actually spiking to ~150A then staying at ~40A, and I expect based on the graph that the breaker may trip. Do you hear the breaker tripping on your setup?
So in my experience the “Total Current” is usually Pink, so I’m assuming the blue and the red are the 2 NEOs which means cumulatively the spike is ~ 150A + 150A = 300A and if that’s the case, I’d expect you to trip the breakers and I’m surprised your battery voltage doesn’t drop even lower. On the basis of this paper, generally ~240A draw is assumed to be an instant brownout. Are you getting brownout flags in your logs?
Regardless of brownouts, it looks like you’re spiking up to 150A each on startup, which if you’re lifting the whole robot isn’t necessarily surprising but is concerning, and then it’s settling to ~40A per motor. If your motors are stalling and isn’t able to lift the robot, my assumption would be that the power being supplied isn’t enough to lift the whole robot, and the stall is pulling 40A while keeping the robot level.
What did your dslogs look like when you were able to successfully test your mechanism? Were the current draws lower? It’s possible that something has broken between then and now. When we bent our drivetrain frame ~2 years ago, we went from 50A draws to 85A draws from the extra friction on the chain.
No, @epylko is correct (I’m on the same team). The current scale is too small to see detail, so they changed which scale it was mapped against so we could see better. It’s definitely ~40A
Ah, okay. I’d still be interested to see the logs from when the mechanism was working successfully vs now when it’s stalling.
If you guys want more access to analyze your dslog data, we have a script that will export it to a csv file. Might be easier than plotting data on differently labeled scales.
Does it make a screeching sound when it stalls? Can you monitor the encoder value in this state? Does the mechanism move if you give it slightly less power?
We ran into similar issues with a NEO in a 100:1 AM Sport. Our mechanism would look like it stalled, but decreasing power would get it moving again. We strongly suspect the motor shaft is spinning inside the pinion.
Thanks for clarifying, this is important to note in the initial post, otherwise you can see how it can be misleading to a community used to reading this log according to the chart labels.
I would recommend logging the values read by the SPARK MAX as well, including applied output, voltage, and current.
This is right, and important to keep in mind. The current limit is on the output current (actual current in the motor winding) and will be different than the input current reported by the PDP. The difference between the two can be much greater compared to what we are used to with brushed motors since the internal motor resistance is much lower. This is also why we turn the current limit on by default and do not recommend removing it.
Do you change the current limit at all in your code after the restoreFactoryDefaults() command?
