Closed PeterBowman closed 4 years ago
Rationale: For both TextilesHand
and DextraSerial
devices, the PC only sees a virtual UART (just trying to be formal here, if I'm correct Serial refers to RS-232 which is actually UART at 24 V and in turn here there are some 5 V or 3.3 V logic values going on) connected via a USB cable, to a microcontroller (Arduino and Teensy, respectively).
Debatable proposal: Merge TextilesHand
and DextraSerial
into a single PWMControlboard
into that implements IPWMControl.
Caveats related to the debatable proposal:
y = mx+b
linear relationship, so we need to store the slope m
and the b
y-intercept offset (near 1.5 ms, but varies per-servo).TextilesHandSerial
uses a Hormone protocol by @David-Estevez, whereas DextraSerial
follows a Synapse protocol by @Alvipe (when did we get so bio-inspired? :smile:).@PeterBowman What is your opinion on this handshake? :handshake:
Okay, we kind of got confused. Just to sum up, cause there are certain ideas here that could be cool. There are 3 hands: LacqueyFetch
, TextilesHand
, Dextra
. There are 2 physical layers which can describe as the input, which to keep it simple, we can describe as: USB/Serial
and Canbus
. The output of each hand may also vary. I'll describe first the primitive output, and later on if there are (or may be) layers above.
LacqueyFetch
Canbus
(though I believe at some time we had a USB/Serial
setup).TextilesHand
USB/Serial
. m
and the b
y-intercept offset (near 1.5 ms, but varies per-servo) relates to the pwm-position relation, and would be the same even if we had a Canbus
input.Dextra
USB/Serial
to Canbus
.TextilesHand
). The 5 motor positions move 14 joints via relationships that have been objects of study in our papers.IMHO, there is a pattern here such that we could end up with 2 primitive devices:
USB/Serial
independent controlboard.Canbus
(kind-a-sub)device that is meant to be used within CanbusControlboard
.Especially in the case of Dextra
, as we have commented, the devices that implements the motor-to-joint relationships would be separate (and could load the USB/Serial
device directly, or connect to the motor positions exposed by the CanbusControlboard
device).
- A USB/Serial independent controlboard.
Note that this exists, might be possible to reuse for Fetch and Textiles (though Dextra is more complex, so it might be out of its scope): http://www.yarp.it/SerialServoBoard_8h_source.html
Note that this exists, might be possible to reuse for Fetch and Textiles (though Dextra is more complex, so it might be out of its scope): http://www.yarp.it/SerialServoBoard_8h_source.html
I think you meant DextraSerial and Textiles (LacqueyFetch is a CAN-based device).
The SerialServoBoard is quite close to the apocanlypse-branch implementation of DextraSerialControlboard. However, it hardcodes several "home-based (cheap) Robotics" boards listed here. And, by the way, has no network wrapper.
I don't think a generic solution could be derived in the current state of this upstream YARP device: first, controlled axes must match those defined in the custom electronics, while there is no entry for Teensy boards (ref); second, the DextraSerialControlboard is very Teensy-specific in that the command protocol is well defined (and obviously hardcoded and therefore not compatible with other boards).
To sum up, the four devices of the apocanlypse and their current state are:
DextraCanControlboard: position-controlled CAN device, inherits from DextraRawControlboardLib
DextraSerialControlboard: position-controlled serial device, uses DextraRawControlboardLib via class composition
LacqueyFetch: PWM-controlled CAN device, implementation ready at https://github.com/roboticslab-uc3m/yarp-devices/issues/211
TextilesHand: position-controlled serial device, will be repurposed as a control board on its own in the scope of the present issue
We see that comms (serial/CAN) and control strategy (PWM/position) interleave across all four devices. Besides, Dextra stuff adds a protocol abstraction layer, Synapse, to translate position commands to either CAN or serial bus messages. I'm not sure whether creating another abstraction layer, which might or might not replace the current ones, is worth the trouble. We lack a proper bigger picture of the problem that will emerge once TextilesHand is cleaned and migrated.
The future plans and ideas laid out here have been outlined at https://github.com/roboticslab-uc3m/yarp-devices/issues/236.
Ready at https://github.com/roboticslab-uc3m/yarp-devices/commit/970b762123a9418d73ffe103e275f621f30d7931. This device implements the IPositionDirect
interface to send motor commands to the low-level firmware, and wraps a serial YARP device that abstracts comms. Therefore, you'll need to compile YARP with ACE and the serialport device (will also work on Windows). Note that it has been stripped from several (unused) interfaces, most notably the IPositionControl
one. I believe you don't interpolate trajectories, hence it was gone. Anyway, it can be easily tweaked in order to forward IPositionControl::positionMove
calls to IPositionDirect::setPositions
.
Not tested, cc @jgvictores @David-Estevez.
@PeterBowman Thanks a lot, this is great! We can test it in the future. The physical device is currently in a drawer and not being used too much, but this is a great opportunity for some revival.
The TextilesHand device is a raw device designed so that CanBusControlboard can wrap it and pass CAN handles. However, serial comms are involved instead of CAN in this case, making it an overkill: a CAN application must be launched in order to use a USB-only device.
A similar precedent brings the solution: DextraSerialControlboard has been coded from scratch to store a handle to a serial device and expose regular (non-raw) motor control board methods. Therefore, TextilesHand should be directly wrapped by controlboardwrapper2 on demand (via YARP dynamic module mechanisms); let's unlink it from CanBusControlboard. Keep in mind that a dedicate port will exist for this device, whereas current usage assumes that arm joints and gripper joints coexist (https://github.com/roboticslab-uc3m/yarp-devices/issues/211#issuecomment-532196134).