PreciseFlex Arm Driver

[miikee]

Untested Driver

This adds:

• ArmBackend base class
• PreciseFlexBackend
• TCP(IOBase) class
• Arm front end class

Docs haven't been updated yet.
There's a warning included in the PreciseFlexBackend docstring that it's untested.

[miikee]

Rebased to main.

• Updated with PreciseFlexBackendAPI, PreciseFlexBackend, ArmBackend, and Arm. Including integration tests with robot (marked with a pytest.mark.hardware).
• Pytest.ini updated to ignore 'hardware' marked tests.
• Updated TCP base class since original testing. So this may need to be retested, but should still work.

[rickwierenga]

@miikee could you please enable "allow edits by maintainers" so I can work on this PR?

[miikee]

@rickwierenga just sent you an invite for the branch. Let me know if it doesn't work.

[rickwierenga]

thank you, this works.

do you know if there is a way to convert between JointCoords and CartesianCoords using their API? like do they expose a kinematics model?

[miikee]

There's a method that converts Cartesian and Joint in the GPL code on the robot, but it's not exposed through the TCS server. We'd need to write some custom GPL to expose it; and the user would also need to upload it.

[rickwierenga]

noob question: how do I define a profile?

with

await arm.backend.move_to(CartesianCoords(location=Coordinate(x=x, y=y, z=z), rotation=Rotation(x=roll, y=pitch, z=yaw)))

I get PreciseFlexError: PreciseFlexError -2817: *Undefined profile*

and with

profile_id = 20
api = arm.backend.api
await api.set_motion_profile_values(
    profile_id,
    speed=25,
    speed2=0,
    acceleration=10,
    deceleration=10,
    acceleration_ramp=0.5,
    deceleration_ramp=0.5,
    in_range=10,
    straight=False,
)

I get PreciseFlexError: PreciseFlexError -757: Object not instantiated. An object is being assigned to on the left-hand side of an equal sign or is being referenced in an expression and the object value block has not been allocated. To correct this problem, use the "New" qualifier in the DIM statement that declared the object to allocate its value block. -

[rickwierenga]

what fixed this: setting the port to 10100 instead of 10000

(nmap sometimes shows 10000 as open, and has never showed 10100 as open, but specifying it in the api did work)

[rickwierenga]

@miikee what are your thoughts on moving the api code into the backend? a lot of the code is just passing data. is there a reason we need that layer of abstraction?

[miikee]

@rickwierenga Do you mean combining the class PreciseFlexBackendApi and PreciseFlexBackend? My idea for keeping them separate was to make PreciseFlexBackend more human readable and to keep PreciseFlexBackendApi 1:1 with the TCS documentation.

[rickwierenga]

firmware commands are a common pattern in PLR 😅 and I think it almost always makes sense to have one method per firmware command.

in some cases I think it also makes sense to have wrappers around those raw firmware-command-methods, to make them more user-friendly or have a version compatible with an abstract backend

but in cases like this where the firmware api is actually nice, it introduces more complexity than it reduces imo. for example, to home you have to read Arm.home -> PreciseFlex400Backend.home -> PreciseFlexBackendApi.home to see it's just a string "home" where it could be the more minimal Arm.home -> PreciseFlex400Backend.home (which is a common pattern in PLR). it would still be 1:1 with the TCS docs, but that then lives in the PreciseFlex400Backend. if needed we can add some more methods to PreciseFlex400Backend that then call those firmware-methods

[miikee]

@rickwierenga combining the two would be fine if you think it'll lower complexity.

[miikee]

@rickwierenga I also wanted to mention a complication with the pick/place/approach methods. These work by setting a station location in the robot's memory. Then the robot grabs from from that location. But it grabs differently depending what access type is set to that station. This is an internal flag it keeps with each station.

• access type 1 = vertical (like a deck plate pad)
• access type 2 = horizontal (like a hotel nest pad)

So the movement changes for each:

• access type 1 place - the arm travels above the location and drops down
• access type 2 place - the arm travels in front of the location and makes a "box" movement - up, forward, down, open gripper

Depending on access type, the z-clearance changes meaning:

• access type 1 - z-clearance = distance above
• access type 2 - z-clearance = distance in front

So this can be a bit confusing... plus theres a few other access parameters that can be changed. I've added a commit here to fix this with a AccessConfig dataclass to describe how to access the plate. Let me know your thoughts.

[rickwierenga]

awesome, thank you!