search

roboticslab-uc3m / yarp-devices

A place for YARP devices
https://robots.uc3m.es/yarp-devices/
9 stars 7 forks source link

Promote TextilesHand to a control board device #234

Closed PeterBowman closed 4 years ago

PeterBowman commented 4 years ago

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).

jgvictores commented 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:

  1. Both could implement IPositionControl as a layer above IPWMControl, we just need to store the parameters that relate them. This is typically (inexactly) modelled as a 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).
  2. We must make both firmwares work with the same protocol. The current 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:

jgvictores commented 4 years ago

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.

  1. LacqueyFetch

    • Input: Mostly Canbus (though I believe at some time we had a USB/Serial setup).
    • Output: 1 DoF PWM. It translates to a voltage, then to current/torque. The torque is messy to measure, because it is coupled with passive springs.
    • Firmware: In custom electronics with PIC
    • Protocol: Arbitrary.

  2. TextilesHand

    • Input: Mostly USB/Serial.
    • Output: 2 DoF PWM. Each control an individual Servo which translates into motor=joint position, which could be (inexactly) modelled as a y = mx+b linear relationship. The slope 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.
    • Firmware: In custom electronics with Arduino
    • Protocol: Hormone protocol by @David-Estevez

  3. Dextra

    • Input: Migrating from USB/Serial to Canbus.
    • Output: 5 motor positions (not sure if some PWM stuff before, most probably Yes), plus 1 DoF Pwm which translates to motor joint position (as in the Servo description in TextilesHand). The 5 motor positions move 14 joints via relationships that have been objects of study in our papers.
    • Firmware: In custom electronics with Teensy
    • Protocol: Synapse protocol by @Alvipe

IMHO, there is a pattern here such that we could end up with 2 primitive devices:

  1. A USB/Serial independent controlboard.
  2. A 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).

jgvictores commented 4 years ago
  1. 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

PeterBowman commented 4 years ago

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:

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.

PeterBowman commented 4 years ago

The future plans and ideas laid out here have been outlined at https://github.com/roboticslab-uc3m/yarp-devices/issues/236.

PeterBowman commented 4 years ago

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.

jgvictores commented 4 years ago

@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.