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 _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
