I have decided to pursue the challenging road of designing my own quadruped. I am in the early stages of designing the kinematic linkages and was trying to aim for a design that did not require a recalibration after every boot with homing switches, as well as having an incredibly small backlash as to not complicate the inverse kinematic equations and control system that much.
After some searching, I found a guy on YouTube named Steve Bruton who built his own quadruped. He is using a belt and a ball screw to drive the links which I thought was pretty smart since it facilitates virtually no backlash. In addition to almost no backlash, I would think having a ball screw would give the joint more resistive torque since the direction the force needs to primarily act in to get the joint to bend is radially (i.e. bending the joint directly would mean that your forcing the slider to work its way up the ball screw which seems difficult to do unless your turning it radially). Below is a video and picture of Steve Bruton’s linkage mechanism:
I would like to implement something similar in my design, however, unlike Steve Bruton’s design, I would really like to not have to recalibrate after every reboot with limit switches. So my question is, how exactly can this be done?
I know the topic of not recalibrating has come up in several thread discussions here, but I thought this problem was slightly different given the gear ratio with the belt drive and the ball screw. I was thinking of using an absolute encoder at the joint instead of on the motor. I know there is sort of support in the firmware in the future branch for absolute encoders, but thought it would be even trickier with absolute encoders that were dissociated with the motor; this is because it seems like the firmware has mainly been tested not only for incremental encoders, but for encoders that are attached directly to the motor.
I may be wrong, but at first glance there seems to be additional benefits feeding encoder values directly into the odrive since it seems to use the encoder as a feedback system to give you some good control over the motor (as well as various other metric values about the motor?). I would ultimately like to leverage as much as the odrive has to offer so I am not reinventing the wheel.
The odrive encoder documentation describes resolving the issue of constantly having to recalibrate at every boot by using an encoder with an index signal. If I attach the encoder directly on the back of the motor, this doesn’t seem like it would do me much good because it seems like the index can only be found within a particular revolution. Given the increase in ratios with the belt drive AND the ball screw, being within one rotation on the motor will not map well to the actual joint.
Alternatively, I can place an encoder with the trigger signal on the actual joint instead of on the back of the motor, but if I pass the encoder values to the odrive, will it be able to make sense of it and provide all the features it normally would if it were attached on the back of the motor.
Please let me know if I missed something or am misunderstanding anything. Any suggestions would be incredibly useful and greatly appreciated. Also would love to hear any criticism on using a belt drive with a ball screw for a quadruped.