• aditya mehrotra.

chip updates: we're back! getting the IK on chip two to work [chip updates]

Sooo we're back from a new location!

Here's the new, Jersey office of robolab. If you count everyone else part of robolab stuff we have offices all around the country now! Hehe!

So today I'm bored and I'm going to try to write my own test code for the robot. And then have Ronak write better code later. I'm going to try to write an IK function, and a move leg function that calls the IK function. Refer to this post:


(note we need to replace L1, and L2 in this math with L3, and L6 respectively)

The first thing to do is to update the LEG model of chip.

Since this is the leg model. The leg class will need to know what the leg lengths of each section are, L1-L6. So we're going to feed the leg class an array that asks for those lengths. Then we're going to write some functions that take in desired xyz positions, and set the motors to the required angle values.

WE used the following lengths (in meters) for the leg model: {0.055, 0.075, 0.235, 0.1, 0.03, 0.32}

Those were all measured according to the above diagram. What I'm now going to do is zero the front-left leg on the smart dashboard in the position we set the zeros to, and then we're going to try to make it move to a desired position. JUST that leg, when we hit enable. FIRST, we're going to try the position (0,0,0) and then we will try the position, (0, 0.5, 0).

So we're going to deploy this and enable the robot and see what happens. THIS SHOULD DO NOTHING. The NEXT ONE when we set yDesired to 0.5 should move the leg and likely very fast so we will need to be ready to disable the robot.

So we deployed after fixing some things, moving some things to ArrayList, moving some other things to other things. And the robot clicked and then lost comms.

So, I think what's happening is the robot is clicking because it's over-currenting or something. I'm going to try to drop the KP value.

THAT WORKED! But the leg moved to the completely wrong place, So I'm going to try something different, hold on. I'm going to try to set a negative x value of like 20cm and see what it does with that. I'm going to increase KP again. WE don't think the KP was too high. (My brother is helping me out, the coding GOD).

KP=0.03 this time! Okay, it lost COMS again. Which means it is the KP that is way too high. So what we will do is drop it to KP=0.005 just for testing! (I think this is also because we are using a POWER SUPPLY not a battery). It's most likely a supply issue not a battery issue.

It's doing some weird things... I'm going to try to set it to (0,0,0) and see what happens. This should NOT work, this shouldn't be possible. And indeed it didn't it over-currented which means we will need to implement some form of checker to see if the points we are sending the legs are in the workspace of the leg.

But now let's try that -0.5 again!

Okay so that kind-of works. There seems either to be some drift in the motors that's getting multiplied by the gearbox. OR there's some motor that's reversed.

The leg/motor directions are correct according to the smart dashboard. To me. That means there's something wrong in the math. Which is likely because this model we are using is really bad.

But now that I think about it, we're sending the robot to -0.5, 0, which is definitely wrong because y is positive in the downwards direction. Huh...

Okay I'm going to try things like switching the x and y axis and seeing what happens to test my math.

Okay so clearly this is a math issue because I told the robot to go to (0.5, 0, 0) and it went to roughly the correct position for (0, 0.5, 0). It has some x-drift probably because the leg model is garbage but, hm...

Hold up...

Okay I really just have no idea what is happening. We might just need an overall better control strategy/better model/better zeroing thing for this leg. But nothing the leg is doing is making any sense to me. Which means what we'll meed to come up with a better way to control it period.

But I want to know why it's doing what it is doing just so we can figure out what the leg is thinking it's doing, sop we know what to fix.

Let's see if its the orientation or something. Let's try the front-right leg. And accounting for incorrect directions of motors.


Now let's test this on JUST the back-right leg because it has the same coordinate frame!

Whatttttttt is happeeenninnnnnggggg I do not knowwwwwwwwwwwwwwwwwww. I have no ideaaaaaaaaaa. Okay so this works for the FRL only. Not the FLL, not the BRL. Testing the BLL now. And that one didn't work either. Some of them really act like the axis have been reversed, some of them act like nothing at all like what they're supposed to. So I really still don't know what's going on you know.

So I need to consult some really smart ppl and go through this is much more detail. In the meantime I want to run a test to see if this over-currenting thing can be solved by using battery power.

Let's bring KP back to 0.05! And plug in our dual 6s Lithium batteries with 50C discharge ratings.

Nope, powering from the battery didn't work either. So there's some other issue going on here.

So, honestly, it may be worth going through the Jacobian model for all four legs and setting at each theta value. Iterating by time-step. That's likely what we want to do. With KPs this high, we need to be careful not to overcurrent the device, we will also need to do some trajectory planning to get this thing to do what we want it to do.

I think the next step is to try the Jacobian and NOT this simplified model.


What we will try doing next time is powering the roborio separately from the Sparks because they’re all just in parallel right now on the main 12V line. Then we’ll need to do some EE to isolate it.

#chip #updates #robotics #omgrobots #model_be_too_simple

5 views0 comments