Summary
bb_servo_feetech and bb_servo_robotis each define the same four fully-qualified error modules in the BB.Error.* namespace (owned by bb core):
BB.Error.Invalid.Bridge.InvalidParamIdBB.Error.Invalid.Bridge.ReadOnlyBB.Error.Invalid.Bridge.TorqueMustBeDisabledBB.Error.Invalid.Bridge.UnknownParam
The definitions are byte-identical apart from the copyright year and a couple of words in the doc strings (Feetech/Dynamixel, firmware version/model number, firmware version).
Why it matters
A mixed-hardware robot driving both a Feetech bus and a Dynamixel bus — a perfectly plausible build — pulls both deps into one application. The BEAM loads whichever module compiles last, emits a "redefining module" warning, and silently discards the other definition. Any pattern match or is_struct/2 check against the discarded module's doc-string wording is now load-order dependent. The two modules happen to be behaviourally equivalent today, so this is latent rather than actively broken — but it's a collision in a namespace neither package owns.
Broader context
These two drivers are structural twins: identical file trees, ~750-line controllers sharing logic with drift, plus duplicated bridge.ex (207 vs 216 lines) and param_metadata.ex (164 vs 229 lines). The bus-servo pattern is now proven across feetech, robotis, and the bridge/param-metadata scaffolding in each — past the three-implementations threshold.
Options
- Move the shared
BB.Error.Invalid.Bridge.* modules into bb core. Smallest fix for the collision itself; both drivers depend on bb already. Resolves the namespace ownership cleanly without committing to a larger extraction.
- Extract a
bb_servo_bus library holding the shared bridge behaviour, param-metadata scaffolding, and error modules, with feetech/robotis as thin hardware-specific layers. Addresses the structural duplication too, but is a bigger commitment.
Recommend (1) now to kill the collision, and treat (2) as a separate decision once the shared surface is better understood.
Summary
bb_servo_feetechandbb_servo_robotiseach define the same four fully-qualified error modules in theBB.Error.*namespace (owned bybbcore):BB.Error.Invalid.Bridge.InvalidParamIdBB.Error.Invalid.Bridge.ReadOnlyBB.Error.Invalid.Bridge.TorqueMustBeDisabledBB.Error.Invalid.Bridge.UnknownParamThe definitions are byte-identical apart from the copyright year and a couple of words in the doc strings (
Feetech/Dynamixel,firmware version/model number, firmware version).Why it matters
A mixed-hardware robot driving both a Feetech bus and a Dynamixel bus — a perfectly plausible build — pulls both deps into one application. The BEAM loads whichever module compiles last, emits a "redefining module" warning, and silently discards the other definition. Any pattern match or
is_struct/2check against the discarded module's doc-string wording is now load-order dependent. The two modules happen to be behaviourally equivalent today, so this is latent rather than actively broken — but it's a collision in a namespace neither package owns.Broader context
These two drivers are structural twins: identical file trees, ~750-line controllers sharing logic with drift, plus duplicated
bridge.ex(207 vs 216 lines) andparam_metadata.ex(164 vs 229 lines). The bus-servo pattern is now proven across feetech, robotis, and the bridge/param-metadata scaffolding in each — past the three-implementations threshold.Options
BB.Error.Invalid.Bridge.*modules intobbcore. Smallest fix for the collision itself; both drivers depend onbbalready. Resolves the namespace ownership cleanly without committing to a larger extraction.bb_servo_buslibrary holding the shared bridge behaviour, param-metadata scaffolding, and error modules, with feetech/robotis as thin hardware-specific layers. Addresses the structural duplication too, but is a bigger commitment.Recommend (1) now to kill the collision, and treat (2) as a separate decision once the shared surface is better understood.