chip updates: IK the right way and PID [updates]
So today we're going to get to work on the actual inverse kinematics we laid out in the post about Jacobins and torque control and etc. We're going to use the SAME leg model for ALL four legs, the only difference is for the right legs, the L1 and similar links pointing away from the robot will be negative. Before we even do that though, I want to tune the PIDs a bit to see what we can get this thing to do.
So PID gains work like this:
KP-really is the "strength" of the leg in this case because KP deals with disturbance rejection. Higher KPs will send more current into the motors even for small disturbances. The problem with this is that if you give the system a big error, it will likely overcurrent. Which means we need to keep the increments small in trajectory generation.
KI-deals with the steady-state error. We will need some KI so drift in error because the system is loaded doesn't occur so much.
KD-deals with "snappiness" of the system, but it also helps attenuate KP and KI to make the system stable. It allows for smooth tracking during large changes in error.
So what we are going to do is set a high KP=0.5, set a high KD=0.1, and set a low KI=0.05 and try that. Then we're going to play with numbers until we get a good response that does NOT overcurrent. Let's see what this does, I feel like it might overcurrent but it might surprise us.
What we will do eventually is build an isolator that isolated RIO power from system power (design a portion of the PDP).
So... at the moment we're getting the error that there's No Robot Code even though it's deploying properly. No idea what's going on, going too google and try some things. Hopefully this isn't something broken. Code's deploying fine and rio is imaging fine. *shrug*
(Honestly, it's probably windows -- restart!)
Ah yes. I have, um, found the issue. Let's just fix that real quick.
SIDE NOTE: The roborio keeps turning off when the current spikes because of undercurrent/brownout protection. Which is good for an FRC robot but not so great here because we aren't using an FRC PDP. We'll have to isolate that at some point.
OTHER PROBLEM: We still have no robot code and its saying because it can't retrieve the CAN IDs for SparkMAXs. According to this dude: https://www.chiefdelphi.com/t/sparkmax-errors-when-robot-program-is-deployed/370068 we need to check our wiring.
^ LOL one of the connectors had fallen right out when the robot fell yesterday. Oops. Back to your regularly scheduled programming. let's try again. YES comms and robot code-yeet!
Okay KP=0.5 is clearly way too high. Let's try Kp=0.1, KD=0.05, KI=0.001!
Considering the legs are always moving, this isn't very stable. I'm going to increase KD and KP. Kp=0.2, KD=0.1, KI=0.001!
Still being weird... Kp=0.2, KD=0.01, KI=0.0005! We're going to drop KP because this overcurrents at very small values. Plus, KI should fix and steady-state error.
So actually. I don't know if the movement is because of the fact that the joystick has no buffer. It could be so let's set that up. We're going to attenuate anything less than a magnitude of 0.1! KP=0.1, KI=0.0005, KD=0.01 and these seem to be working well right now. But the system is still overcorrecting slightly. What this tells me is we really really need to isolate that roborio.
So we're going to keep the PID gains as is and go try to do that. The reason is until we isolate that this thing will keep over-currenting and we won't be able to even tuned the PID to what it can be. That system can handle almost 40 amps of current draw the rio cannot.
We'll figure that out eventually - but in the MEANTIME. I want to analyze the tracking error of this thing. I want to see if I set the legs and move them around a lot will they move back to the same positions. IE: Did KI help at all?
Even this KI of 0.005 has made a WORLD of difference in being able to control the position of the motors. The steady-state error is really not terrible. Like there's definitely some error but even when we sat it back down, the error does track back to a point that's acceptable considering KI=0.005! So of course we will change this once we fix the overcurrent issue-but I'm also wondering if the KI gain is more important than the KP in this case ...
FOR NOW though, we're going to stick with those gains.