Homing J3 & J4

[scottrpaterson]

Using Python 3.7.7 on Windows 7

from dorna import Dorna
r = Dorna()
r.connect()
r.home("j0")
r.home("j1")
r.home("j2")
r.home("j3")

As you can see from the picture the joints 3 and 4 are really off. Bringing the joints to 0,0,0,0,0 and calibrating doesn't fix the problem.

[circuitsforfun]

I have the same problem, I've tried several different combination of positioning the start rotation of j3 and j4 and cannot get it to home properly... I also manually zeroed it out and ran the calibration command to store the offsets and still no luck.
If after homing I manually rotate j4 until the magnets are aligned and then rotate j3 until both hall effect sensors trigger at the same time (making small tweaks to j4).. I can get it to the point that when I rotate j3 in very small increments I verify that both hall effect sensors trigger at the exact same time then that rotation offset on j3 is very consistent and I can manually zero it out.
I don't know why that isn't the way homing works by default... it seems that would produce consistent results on any arm regardless of offsets from the assembly process (the user would just have to specify the j3 offset for calibration on their specific arm).
if the API had a way to read the hall effect sensors I could just write my own homing procedure for j3 & j4.
Also on a side note, I don't know if it's related and might explain why the homing calculations are wrong ... when you rotate j4 in the web gui 3D preview it rotates in the opposite direction from what the actual robot is doing.

[scottrpaterson]

@circuitsforfun

Love your Rick avatar. My robot is actually named Sanchez haha.

I haven't made any progress with homing, but I did come up with a work around that might help you, or others.

Put the robot like this:

This position is useful because you can turn it off and on.

Then move the robot to all 0's using the move comment where the movement variable is set to 1 so that it's relative to the start point.

After it's at all 0's, run set_joint for all the joints and set it to 0's. Now the robot can be moved anywhere and works as if it had been homed.

[circuitsforfun]

Thanks... I actually read a little further down the issues list and saw another similar issue #24
and the person that submitted the issue managed to rewrite the calibration for j3 & j4 and I tried his implementation and it seems to be working fairly well (once you determine the proper offset variable for your arm)

[circuitsforfun]

So I still had some homing issues even with the fix that tloanPhytec came up with, it still wouldn't work correctly in some situation depending on the start rotation of either j3 or j4 so I finally had some time to dig into the issue a bit more.... had to learn some details about g2core
after digging under the hood a bit I found a way to control the rotation directly with GCodes and read the homing (hall effect) sensors directly to see when they get triggered.

I was able to rotate j3 and j4 in such a way that I can get them to line up and trigger the homing sensors at the exact same time (within 0.05 degrees) then using the extra offset parameter that tloanPhytec had implemented I can rotate back to the proper home position and zero j3 and j4 out.

This has the benefit of not only homing the pitch angle of j3, j4 but also the yaw (twist or whatever you want to call it) as well.
This method works no matter what the start rotation is of j3 or j4 even if it is already triggering a homing sensor.

one bit of warning though... I kind of hacked this thing together quick and dirty and I am doing some direct serial port reading / writing, I had to add some extra hooks to get the raw serial return from the receive thread... this is definitely not the best way to do it but I didn't want to spend too much time reworking the API since I am most likely going to write a C++ wrapper for the arm anyway because it will serve my use case better.

you can grab and use at your own risk here:
circuitsforfun@5a493ab