Partition optitrack support out of Drake

[jwnimmer-tri]

Supporting the optitrack driver & messages in the pre-packaged Drake binaries is a bit of a chore. I'd like to propose splitting it into a completely separate package to smooth things out:

(1) Enhance https://github.com/RobotLocomotion/optitrack-driver with releases that are easy to use. (For example, provide releases with installable packages that incorporate the generated message types, instead of just source archives.)

• [wheel] Add rules to create a platform-independent wheel optitrack-driver#16

(2) Deprecate stuff inside Drake for eventual removal:

• optitrack_client (the program)
• optitrack lcmtypes
• OptitrackSender
• OptitrackReceiver

(3) Adjust Anzu to directly use the driver repo and its message types, instead of via Drake.

\CC @sammy-tri curious to get your feedback.

[sammy-tri]

If I were just answering for my own use cases (by which I mean any Anzu user I suppose): (1) not really necessary (2) copy the LeafSystems into anzu, get the types and client from optitrack-driver, (3) yes.

To support a broader user community (1) seems necessary but I'm not sure what it looks like (I assume you'd want these packages to be usable by people who've installed the drake binary releases?), (2) where do you package the LeafSystems?

I'm not sure how broad of a user community there is for drake+optitrack.

[jwnimmer-tri]

Ah, I should have clarified that. The optitrack-driver packages would only have the driver / client / messages. The leaf systems would be gone for good. (Users could copy the leaf system code from Drake to their project if they need it.) I think really nobody uses the sender system, and the receiver system is cake (a few lines of python) and anyway many users would probably would want more application-specific customized versions the receiver it anyway. In other words, my premise is that LcmSubscriberSystem is sufficient as a "receiver".

[sammy-tri]

my premise is that LcmSubscriberSystem is sufficient as a "receiver".

Works for me.

[jwnimmer-tri]

The optitrack.client wheel file has been officially release now, at: https://github.com/RobotLocomotion/optitrack-driver/releases/tag/v0.0.20230714

[RussTedrake]

I've got multiple groups asking me about using Optitrack with HardwareStation this week. I see that the driver lives on externally. But on first glance it seems that the optitrack sender/receiver systems are lost to the world? might you recommend a workaround?

[jwnimmer-tri]

Yes, the https://github.com/RobotLocomotion/optitrack-driver lives on outside of Drake and provides the program and lcmtypes. The latest release in that repository has a wheel file with everything, including the generated lcmtypes in all languages.

For Python:

Import the wheel and use its message classes to send and receive messages using Drake's LcmPublisherSystem and LcmSubscriberSystem. In many cases, that will be enough -- the systems that need to "speak to optitrack" can operate on the message type as an abstract input/output port. (The OptitrackLcmFrameSender and OptitrackReceiver were never bound in pydrake anyway, so that matches the prior status quo.) If it's still helpful to have systems in Python that convert to some number of RigidTransforms or from a FrameKinematicsVector, a user could write a simple Python LeafSystem to fit the specifics of what they require.

For C++:

Users who want to use the generated C++ lcmtypes should adjust their build system either to run lcm-gen themselves (against the *.lcm files in this repository), or else add the optitrack-driver wheel as an external workspace dependency (it's just a plain zip file, which the build system can unzip and add the header files to the include path), or else commit the generated message headers into their own source tree. That's enough to use LcmPublisherSystem and LcmSubscriberSystem. C++ users who want the exact logic of the OptitrackLcmFrameSender and OptitrackReceiver systems can copy that code from Drake into their own project.