Robot drive becoming jittery, help me read this log

Chassis started acting weird with 70ish seconds left in our last match at INDCMP. Rookie mentor without a lot of experience troubleshooting this kind of stuff in FRC. Nothing stands out in logs different than our other matches other than a small drop in CAN%. Amperages and voltages all seem fine. We suspect it might have happened when compressor kicked on. Can’t get robot out of bag right now, but hoping to have a game plan when we get to Detroit.

Green dots near the top - do they have messages if you hover over them?

Getting some “Info communications timeout”, but frequency seems consistent with our other matches. Also some isolated “watchdog not fed” messages, but once again sort of random and consistent with what we’re seeing from other matches without problems.

Edit: I’m realizing that " Info communications timeout" does not appear in other matches quite as much as this one. However, it doesn’t seem isolated to when the robot was acting up in this match.

That’s a lot of latency and packet loss. Especially right when the CAN percentage drops.
Are you doing a lot of control algorithms on your RIO?

The compressor is an interesting theory. Might be worth putting the robot on blocks in your pit to see if you can replicate.

Not really any control algorithms. We pretty much just run a lot of if and if else statements to turn motors on and off based on controller values. Very basic (other than our endgame lift, which is automated sequence, but ran fine in this match) I will say I’ve been pretty unimpressed with our DS laptop. I’ve tried to make sure nothing else is running to slow it down, but I wouldn’t be surprised to find out that Dell interfered with some sort of system check popup (though our driver didn’t report anything like that).

Could be a laptop issue.

What does the plot of the voltage look like?

Is there anyway you can upload the actual .dslog and .dsevents files instead of just a screen capture?

Here ya go. 2019_04_13 15_31_58 Sat.dslog (683.2 KB)

Dang, what do you have plugged into PDP 4? It looks like you’ve got a 100A spike around the 15:37:30 mark and an 80A pull earlier around 15:36:15. PDP 1, 2, and 3 are all jumping up to 40-60A regularly.Your total current is 247A at 3:36:44 PM if I’ve parsed the log file right?! Are PDP ports 1-4 your drive train motors?

I don’t understand why your voltage plot doesn’t drop lower. Usually with those kind of pulls, my team would be seeing our batteries drop to 7V and have brownout issues. Which… brownouts can look like a jittery drivetrain. But you’ve got no brownout flags and your voltage doesn’t drop to critical levels.

The small compressors have a max draw of 10A, which may not be reported in the dslogs since they should be powered off the PCM which should be powered off the designated PCM port of the PDP, not one of the numbered channels. So it’s possible towards the end of the match when you have some 180A-200A pulls on PDP ports 0-15, that you add the 10A from the compressor and trigger a brownout. I’m not sure why that wouldn’t show up in the logs, but I’m used to offboard compressors so there may be something going on there that I’m not familiar with.

Regardless, I would suggest you guys add some current limits to your code. (Don’t add before a match unless you have the ability to test the robot on a practice field first.) Current spikes over 200A are usually asking for trouble, especially at the frequency you seem to be pulling them in that match. Although I suggest this with the caveat that I’m using a homebrew dslog file parser/viewer. You may want to verify in the real viewer to see if you see the same voltage/current numbers that I do.

Might also be worth comparing this log to some from your other matches to see how similar/different it is. We once went from 50A spikes on our drive motors to 80A spikes on our drive motors after our drive frame took a hit and bent which put a lot more load on that side of the drivetrain.

I believe PDP 4 is our hatch grabber. We have a limit switch on it, but it hasn’t been triggering the way we want it to. We’ll put fixing that on our list. It’s running off a Talon SR, and I don’t think current limiting is an option (if I remember correctly).

PDP 0, 1, 2, 3 are our drive motors. We can current limit those, as they are on Talon SRX with Victor followers. How do you typically decide what a good limiting amperage is? We like the ability to push, and haven’t had any problems with brownouts other than this match. Would adding some kind of ramp rate be beneficial, as it might be about quick changes in direction. Once again, I wouldn’t know what ramp rate values to start at. We are running KOP chassis with 2 CIMs.

Do you print anything out as debug? Your CPU is kinda high and you are dropping packets.

Are you calling a set method on a WPI object every time in the main robot loop?

We have printed debug in the past, not sure if it’s still in code. I will have the programmers check and remove if we are.

Not sure what this is.

@suPURDUEperAndy It would be any method on a wpilib object especially like a solenoid, relay, etc in the main loop that looks like this:

if (GetButtonPressed())

In this case the object is being changed whether a button press or the desired subsystem object is active or not. The method is changing the state of the object and needs to grab a lock, which produces delays in the main loop.

Something better:

if (GetButtonPressed()) {
    lifter = true;
} else if (lifter) {

I think I understand, but should that “else if” also include a “lifter = false;” ? Otherwise, I still see it using a set command every time.

I suppose it would also be worth developing code to only execute the “if” part on the first press of the button, rather than repeatedly as long as the button is held (though I understand you were just giving a quick example).

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