[Rock-dev] Proposal: NDLCom and Rock

[Sylvain Joyeux]

On 12/04/2013 02:10 PM, Martin Zenzes wrote:
> - Open more than one "file descriptor" to read and write encoded
> NDLCom Messages as serial data
>   - `/dev/ttyUSB0` - profane tty
>   - `$IP:port` -- TCP/UDP connections
>   - `/dev/can0` -- No CAN in Sherpa, but others use this already
>   - `/dev/ndlcom0` -- Custom kernel device from !GumBridge FPGA,
> providing parsed and decoded messages
Keep it simple, and have the class handle only one single I/O (i.e. be
one driver). You can always have a wrapper class on top that does the
I/O-to-deviceId mapping if it is really really needed. In the same
effect, on the oroGen side, there should be IMO only one task per bus
(i.e. I/O) as well.
> - Provide received Messages which are directed to the own receiverId
> as `ndlcom::Message` at the `readMessage()` function to a caller
> - Accept `ndlcom::Message` at the `writeMessage()` function to be sent
> to the correct hardware interface
> - Forward messages not directed at the own deviceId to the correct
> hardware interface
I don't understand these.
> - Handle broadcasts: resend the message on all other hardware interfaces
> - Mirror all received and transmitted `ndlcom::Message` as encoded raw
> NDLCom datastream via UDP. This would allow working with an unchanged
> iStruct Gui. This is transitory, for legacy support of the iStruct
> stack. Also easy access of all NDLCom-data without additional rock-code
IMO, you should just make a separate class that "listens" to everything
that goes through the iodrivers_base::Driver (you can add listeners...)
and mirror it to UDP instead of adding that as a core feature of the new
class.
> - Statistics (bandwidth per interface, known devices, broken+missed
> packets)

> The big question: Using `driver/iodrivers_base` makes things much
> simpler, but adds a dependency to the Rock CMake macros. As far as I
> am concerned this is ok.
If you are fine with getting the dependency on iodrivers_base, would not
make much sense to reject the one on base/cmake ...

> So, after *lotoftext*: This cpp-library is finally to be embedded in a
> Rock-Task, providing the appropriate Rock-Ports and executing the
> needed Hooks. Everything else, mapping certain NDLCom-Payload to
> certain Rock-Types or providing services based on NDLCom Messages, is
> done by other Rock-Tasks.
I would definitely not go for mirroring the MARS design. The Mars design
communicates "behind the scene" between a core component and the
"device" components, constraining the device components to be in the
same process than the core, and in general giving headaches.

Hopefully for us, there are indeed precedents for this kind of hardware:
the CAN bus integration as well as the Schilling DTS (the last one is
not in Rock proper).

The general design there is to split the handling of the protocol between:
 - a bus handling component, which represents a given bus and only does
the multiplexing/demultiplexing. It would create one port per deviceId
and only output, on this port, the raw data that is relevant for this
particular device. If your payload is only raw bytes, you could even use
iodrivers_base::RawPacket.
 - one component per device, which takes the raw bytes and parse it into
actual data (and, if needed, is able to properly reply/configure/... the
device)

Among other things, it makes the error handling a lot easier, as you
have one component per point of failure.

If you can, I would definitely go for RawPacket as the data type. If you
ever "wrap" an existing device's protocol in NDLCom, it would allow you
to reuse the existing device's rock component as-is.

-- 
Sylvain Joyeux (Dr.Ing.)
Senior Researcher

Space & Security Robotics
Underwater Robotics

!!! Achtung, neue Telefonnummer!!!

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-454136
Fax:   +49 (0)421 218-454150
E-Mail: robotik at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.:    DE 148646973
Steuernummer:  19/673/0060/3
-----------------------------------------------------------------------