chip updates: how we are going to do control [updates]
So here's where we figure out how we are actually going to CODE the Chip Controller, and basically what we will do is a lot of integration to feed-forward PID. It works like this, I'll diagram, then explain.
So the trajectory we want the endpoint of the leg to follow (the foot to follow) comes in as a stream of (x,y,z) coordinates. The trajectory parser extracts one of these (x,y,z) points at a time and sends them to the actuation controller which consists of the rest of the block diagram. The trajectory parser also takes in information on the motor's current position readings, and only sends the next point to the actuation controller when we've reached the point last sent or are very close to it. This will account for things like how long it takes for the system to reach a point in the trajectory instead of just sending a stream of points some of which may be reached and others may not.
The trajectory parser ALSO takes into account where the leg position currently is and the (x,y,z) coordinate it sends isn't an (x,y,z) coordinate, it uses the Forwards Kinematic Equations to find the current position, and it takes the desired position and creates a DELTA_XYZ that may be used in the Jacobian.
Then the (x,y,z) point goes into the inverse Jacobian matrix where the delta_XYZ is transferred to a delta_THETA command for ALL of the motors. These are sent to a Joint Angle Rectifier which essentially takes the current motor position, adds the Delta Thetas, and sends the joint commands to the PID position controllers.
If you're working about motor +/- directions and zeros and such, that's all taken care of in the Leg Class where we set up a leg and set the positive directions, zeros, and thetas.
the trajectory itself:
So there are many issues with this system especially since we are essentially, integrating the Jacobian, we're getting small changes in the Delta_Theta based on desired small changes in Delta_XYZ. The keyword here is this really only works for SMALL CHANGES. So if we send a large delta_xyz coordinate, then the approximation is no longer valid.
What this means is we need to be sending points that are very close together for this to work, so when we command a position, before this whole block, there's a trajectory generator which takes the vector from the current position to the desired position and divides it into a bunch of very small manageable chunks.
I will say - this could be a CRAP idea and it might not work at all. If that's the case, maybe we want to just go with a much more simplified leg model, and use straight trig-based inverse kinematics to solve it. But I have no idea.