104H / bcratos

0 stars 0 forks source link

Programming Grasping Commands #22

Open 104H opened 9 months ago

104H commented 9 months ago

The hand needs to be programmed independent of the arm to grasp and release the object.

Requirements:

  1. Receive a UDP packet with a a range of grasp from 0 to 100, where 0 means fully open and 100 means holding the object in a grasped state
  2. In the event of having fully grasped the object (touching the boundary of the object) send a UDP packet as confirmation of the same
aagudel commented 9 months ago

Requirement 1 is correct.

A better formulation of requirement 2:

  1. Return a continuous feed-back signal with the value of the current position on the target command, i.e., a value from 0 to 100 indicating how much of the command has been successfully achieved. This can be probably obtained from the robot internal encoders (either thumb or index or a combination of both). Note that this "has" [current state] signal is different from the "must" [objective state] signal. An example: we ask the robot to reach 95 of closed but the hand found the object at 83. The "must" [Objective] signal is still 95, but the "has" [Current] signal will stall at 83. The value can be encoded as a UDP packet with a similar format to the original "must" [Objective] command, sent at the same frequency of reception (20ms or 40ms, I don't remember exactly which one we decided to use). In any case, as the reception thread is always waiting, we probably don't have to worry about timing on your side. It probably suffices to just:
    • Receive the UDP "must" [Objective] command
    • Command the Hand to move to the objective position
    • Read out the current position
    • Sent back the "has" [Current] signal
    • Get ready to receive the next command

I could be wrong about the functioning of the hand and maybe this is handled different, I would expect there is such a parameter internally. However, the hand might have a collision mechanism in place? We probably need to test and see.

104H commented 9 months ago

Do we need two threads? A listener and a speaker, where the listener is listening for an in coming position command and the speaker is broadcasting the current position?

If this is done in a single thread then we can't know the position in real time.

104H commented 7 months ago

Closed in 0799e2a