YARP ports to interface remotely with CAN traffic

[PeterBowman]

Split from #85:

Now that YARP interfaces are making their way through (#122), I'd consider this option once again: a client/server device pair to talk remotely with the CAN master via RPC. No custom shell will be needed (new apps, ipython with bindings), just use the yarp rpc utility.

To expand on my last comment, the CAN bus logic (master + nodes, i.e. CanBusControlboard + TechnosoftIpos, CuiAbsolute and so on) could live in a remote PC, quite the contrary as it is stated in our install guide: yarp-devices-install.md#Specific dependencies (check the hcanpci row). The only thing that requires to run closely tied to the robot CPU and consume its resources is the yarp::dev::ICanBus implementation (currently: CanBusHico). We'd need the remote_controlboard equivalent and the server pair, thus CanBusHico (or whatever) would act as the subdevice of the latter.

[PeterBowman]

Since the RPC server cannot run independently from the CAN bus device (e.g. CanBusPeak), and locally instantiated CanBusControlboard is probably the most efficient way, I'm planning on opening an optional RPC port within CanBusControlboard to allow remote SDO commands, mostly. A client device could be of use in the proposed CAN-monitor GUI app (#225).

[PeterBowman]

Several obsolete applications (examples, programs and tests) have been removed at 7ba52dc, with the sole exception of dumpCanBus. This app is easily replaced by the handy pcanview tool and cannot be used along with the launchCanBus app (we may use the IXXAT USB-2-CAN device for that), but it was decided that it should be kept for now (cc @jgvictores).

In this issue, I aim to make CanBusControlboard stream CAN messages through YARP ports. Once this is done, dumpCanBus will be retired.

[PeterBowman]

See LoggerInterfaces.h at icub-main.

[PeterBowman]

Several obsolete applications (examples, programs and tests) have been removed at 7ba52dc, with the sole exception of dumpCanBus. This app is easily replaced by the handy pcanview tool and cannot be used along with the launchCanBus app (we may use the IXXAT USB-2-CAN device for that), but it was decided that it should be kept for now (cc @jgvictores).

The dumpCanBus app has been reimplemented as a YARP port reader: a404e79. It connects to a remote "/robot/dump:o" port and prints all messages flowing through the corresponding CAN bus, conveniently parsed in a human-friendly format.

[PeterBowman]

The dumpCanBus app has been reimplemented as a YARP port reader: a404e79. It connects to a remote "/robot/dump:o" port and prints all messages flowing through the corresponding CAN bus, conveniently parsed in a human-friendly format.

I noticed messages are sometimes lost, e.g. in a repeated 100Ah (firmware version) request that involves a handshake of 8 packets, one message may not be transmitted via YARP dump port. In contrast, I tried to switch from udp (current) to tcp protocol and there is always a noticeable loss, even up to a half of the packets never arrive.

@jgvictores suggests: try QoS (quality of service)?

• https://www.yarp.it/yarp_cluster.html
• https://en.wikipedia.org/wiki/Packet_loss
• Is tcp+log.in carrier meant to be used only with RpcServer/RpcClient classes? robotology/yarp#304 (comment) (regarding packet loss)
• yarp::os::QosStyle
• https://www.yarp.it/yarpmanager.html (regarding QoS)
• yarp::os::NetworkBase::setConnectionQos
• https://www.yarp.it/carrier_config.html
• https://www.yarp.it/channelprioritization.html
• https:/robotology/yarp/blob/ef19d8e5445b5f56d341d3ec1a01c0c11edd78b5/src/carriers/portmonitor_carrier/examples/simple_qos/qos.lua
• https:/robotology/yarp/blob/8bc852eb80d463df96dff71a4be9dc2f7e01bae3/bindings/lua/examples/driver_qos.lua#L21-L30
• https:/robotology/yarp/blob/8bc852eb80d463df96dff71a4be9dc2f7e01bae3/example/portmonitor/qos_monitor/qos_monitor.lua

See also #160 (comment).

[PeterBowman]

Similarly to YARP_ROBOT_NAME=teo (#237 (comment)), I'm adding YARP_PORT_PREFIX=/teo to /etc/environment so that YARP's nameserver automagically prepends the /teo prefix to all ports opened aboard TEO.

See roboticslab-uc3m/teo-configuration-files@1454eaa and roboticslab-uc3m/teo-developer-manual@818e15b.

[PeterBowman]

Three YARP ports are opened per CAN bus device (e.g. CanBusPeak):

• /<prefix>/dump:o: output-only, dumps all incoming and outgoing (from the CAN master's perspective) CAN messages, much à la candump in the canutils apt package. The newly reworked dumpCanBus app connects remotely to this port. Format: cob-id (databyte1 databyte2 ...).

• /<prefix>/send:i: input-only, forwards incoming messages to available CAN nodes. Same bottle format expected as in dump port. If using the yarp write interface, you can pass hex values by prepending the 0x base to all numbers expressed in hexadecimal.

• /<prefix>/sdo:s: RPC confirmed service, only SDO transfers allowed. Format is <direction> <id> <index> <subindex> <type> [<value>], where:

  • <direction>: either sdo-u or sdo-d for SDO uploads and downloads, respectively
  • <id>: CAN node id
  • <index>: object dictionary index
  • <subindex>: object dictionary subindex
  • <type>: data type, one of i8, ui8, i16, ui16, i32, ui32, str (u: unsigned, i. integer, str: string)
  • <value>: only for SDO downloads (data sent to drive)

  Success/failure is reported to the user in the RPC reply message. For SDO uploads, the response message contains the decimal value (for any of the iX and uiX integer data types) and its string representation (integers are additionally expressed in hexadecimal base within this string).

The port prefix is configured in each bus .ini, e.g. pcan-leftArm.ini, via name option. Ports are disabled if said option is missing.

I might add a fourth port to stream bus state info such as bus load and errors, see #242 and #231.

[PeterBowman]

Idea: enable a --debug option to inhibit CAN node device instantiation, thus leaving CAN bus devices (e.g. CanBusPeak) running and streaming via CAN RX/TX threads to the wild through the new YARP ports as described in the previous comment, with no other CAN traffic involved. I don't think this is a pressing matter given that it is already achievable via /send:i port, with the major problem (?) being that nodes have been already started and stuff is flowing in both directions (active TPDOs and periodic SYNCs). Also, usual controlboard YARP ports will remain needlessly open unless specifically told not to do so via hacks...

[PeterBowman]

Ready at bf2bbd8.

[PeterBowman]

I might add a fourth port to stream bus state info such as bus load and errors, see #242.

New /load:o port added, see #231 (comment).

[PeterBowman]

@jgvictores suggests: try QoS (quality of service)?

Just noticed that yarpviz allows to tweak several related properties on-the-fly using the "Configure QoS..." context menu while clicking on a connection between ports: