[Rock-dev] Proposal: NDLCom and Rock

[Jakob Schwendner]

Hi Martin,

> The general Rock-approach seems to implement as much as possible in 
> independent librarys, only providing the necessary glue-code in an 
> orogen- Task specification. Right?
Right.

> == ndlcom::Communication ==
> 
> Therefore, I would propose the cpp-library "ndlcom::Communication" to 
> have the following properties:
> 
> - 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
> - 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
> - 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
> - Statistics (bandwidth per interface, known devices, broken+missed
> packets)
I think this is the piece I don't understand. Would this
ndlcom::Communications be some sort of routing layer? Where would this run?
Does it already exist? 

> 
> See also the attached ASCII art...
Png of ascii art... hmm... doesn't this kind of defeat the purpose?

> === iodrivers_base ===
> 
> 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.
Sounds good.

> There are some complex features in this library...
Is this a statement or an accusation? :)

> == Rock Task ==
> 
> 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.
Actually, this is interesting how to do this in Rock. In principle I would
have said, that you have multiple tasks, one for a ServoMotor, one for a
SensorGrid a.s.o., and all derive from a base task, that does the basic
NDLCom setup. The problem only is, that as far as I understand you could
have multiple different devices on the same bus. 
We did have a situation like this before, but I am not sure what the current
best way of handling this would be. One method I could think of would be to
use the same mechanism that we have used in the Mars integration. There is a
core task, that does the communications, and multiple Plugin-Tasks, that
have access to the core task, and provide the specific interface types (e.g.
base::Joints). 

What's the opinion of the others on this one?

Cheers,

Jakob