• aditya mehrotra.

chip updates: let's get setup on the leg side [updates]

So I thought my robotics final was today, it's actually tomorrow. Better thinking it's today and having it be tomorrow than the other way round. So today I have some quality time with chip. We're going to mostly do setup things we said many times that we should do/were going to do, and never got around to because there's so much to poke around in the code. So these things include:


(1) Finding a better way to zero the robot/better position.

(2) Saving this better zero position and accounting for the translation in the code.


^We're going to start with that because that needs to happen before most of the other software goes in, not because it can't happen after but because it's so much more convenient. We'd really want a new zeroing position that doesn't require us to balance the robot on the flats of the motors because while, in theory, that works great, it really doesn't always work.



I feel like this is a much better zeroing position. The reason being, we can actually see where the legs are definitively supposed to be in this position, instead of eyeballing/guessing. We're going to go with this for zeroing then. What this means is, to not change the math, we'll have to do the IK and everything else assuming the OLD zero position and then offset all the commands which will not be that hard. (We just subtract the distance from this position to the old position).


We're going to do this by guessing a little, yes, we are just going to say that looks like about 30 degrees which is 30/360*100 rotations of the motor which means "0" should be at ~-8-10 rotations. For BOTH of the joints. We're going to try that at first, and see how accurate that is and adjust. ALL of the motors will be offset by the same number of rotations, I think, but we need to double check that of course. Note the theta_2 (hinge joints) zero positions will not be affected.


We're also going to make a procedure for placing the robot on the ground because we need to account for slop. We can even write a method called publish_val(data): which accounts for the zero offsets so we don't have to in all the other parts of the code. In fact, we really should!


So that's what we're going to do:

(1) Turn the robot on

(2) Test the -8/-10 rotations pick the number that brings the legs to zero (we can actually calculate this by measuring the exact angle).

(3) Fix the code so that we have a method that publishes a command and deals with the OFFSET.


It's actually roughly 25 degrees so let's start with -8 rotations and see where that gets us.



We're doing all this editing in the NEW ROS package which is starting basically from scratch. The IK is in the master remember (everything is), and we tried all of this right. We put those two lines in the TEST mode in case something went horribly wrong and we needed to abort this.



And voila, we didn't think it was going to be that hard and we were right, it wasn't. First try! Using a little math and some good old fashion python functions. NOW every time we want to publish a command to the motors we'll use the publish_CMDS() function because it automatically accounts for the new leg zero positions.


In other news, we changed trajectory's default to [0,0,0,0,0,0,0,0,0,0,0,0] because I think we're going to use trajectory more with the CMDS instead of with the XYZ positions. This way, no matter what, the platform starts out at the [0] position.


One more thing before we have some fun - we said we'd limit the joints to -180-->180 degrees when publishing because why the heck would we need to spin more than that? We shouldn't spin pass that so wires (and later fabric) don't get tangles. So in publish_CMDS we're going to check the values. But first, we need to figure out what those values even are.


-180/360*100 --> -1/2*100 = -50. So we want to limit the motion on -50-->50 rotations. So that's what we'll implement next in the publish_CMDS() method. We shove all this into publish_CMDS so no one ever has to worry about it ever again. We are also going to limit the hinge joints from -5-->50 rotations because it can swing out as far as it wants but it can't swing in much.



So we'll unit test that later, I have no desire to send anything to like -400 rotations right now, we're fairly confident this works because we've tested the clip function already. So the robot can now move its shoulder and knee joints from -180d, 180d which is more than it will ever reach, and the hinge joint can go from a few degrees in to 180 degrees out. These limits help the robot not (a) crash into itself, and (b) not get tangles in its own wires and body.

So all that above was setup, see? Things we had to do now and before we get to re-programming/overhauling the entire platform. These things are important because if done now, we don't need to completely change programming style later, like we've done seven times already.


Honestly, did not think it would take that short an amount of time to figure that out but at least I have time to play now.

We can try some of these maneuvers today and put them in the dance section!


SO ACTUALLY for documentation purposes we're going to end this post here and make the fun-stuff a separate post so we don't like confuse things.


#updates #omgrobots #setup_tools #getting_a_little_closer

0 views0 comments
© copyright 2019 | aditya mehrotra