Understanding PDP Data

Yesterday when the team was testing their mecanum robot (from 2022 season) trying to drive onto the Charging Station to see if they felt they could build a mecanum this year, they noticed that only the front wheels of the robot were spinning (by power) when trying to climb onto the Station. (The other two were just rolling.) In an attempt to understand if it was a code, electrical, or mechanical issue, we wrote some data to Shuffleboard. The test was performed with the wheels off the floor to reduce the number of variables. My expertise is not electrical, and I’m having trouble understanding the data collected.

The test was with the robot wheels spinning only forward; therefore all the encoders should relatively be the same. Which they are (as can be seen) so all the wheels are getting power. What I don’t understand is the data coming from the PDP. I believe from what I had read it is showing the current for each channel on the PDP. Why is there such a large variability? The motors for the drivetrain are on channels 14 (left front), 0 (right front), 13 (left rear), 12 (right rear). Because these are all identical motors (NEOs) with identical motor controllers (SparkMax) shouldn’t they all be the same? If they aren’t, what does that mean? Also all the motors on the robot are NEOs except for one.

If the encoder values there are velocity, then it looks like all the wheels are spinning at about the same speed. If you’re using PID control, you’d expect the same speed, but a different current, but not as different as you’re reporting here. With the robot off, can you move all the wheels freely?

We could say more if we could see your code. Are you logging the speed/power being sent to each wheel?

I see your Shuffleboard graphs are suffering from Issue #720.

The encoder values are actually position. This photo was taken while the robot was not moving and didn’t have any inputs from the controller. The code is not using PID control… is just taking the joystick readings and passing into driveCartesian(). When the robot is off, the wheels spin freely and all appear to spin with similar force. Right now the only data logging is seen here. This was a quick test to see if it would help uncover the problem before spending more time on it.

Here is my code… Mecanum Test Code

Yeah, I messed up the graph. I was going back and forth between two different code bases to see if I saw a difference in how the motors acted. I didn’t clear out the graph properly.

I looked through this code and didn’t see anything obviously wrong. My next suggestion would be to log velocities for each wheel and see if it’s consistent with what you’re observing.

(As an aside, if you’re going to have code in dozens of places that does the same thing for each wheel, please have them all in the same order. :slight_smile: )

Not your fault. It’s a bug.

We can go back and log more data for the motors in code, but what we were really hoping to understand was the big difference in the values for the PDP readings and if it means anything before spending more time in code. We had issues with the robot not moving well at the beginning of last season, and it turned out to be a motor that was failing. We want to make sure some bigger issue with electrical or mechanical is not the root cause.

And yes, agree the lines should all be in the same order. Working quickly with limited time led to sloppy code.

What firmware does the PDP have? From https://store.ctr-electronics.com/content/user-manual/PDP%20User's%20Guide.pdf

4.5. Firmware <1.37: Current may read ~2A when there is no current.
The current sense circuitry has biasing (similar to a gyro). Firmware 1.37 and on will zero the
output so that 0A is read when there is no load.

I don’t know. Will look into this.

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