[Rock-dev] Proposal: NDLCom and Rock

Martin Zenzes martin.zenzes at dfki.de
Wed Dec 4 16:29:01 CET 2013


On 12/04/2013 03:39 PM, Jakob Schwendner wrote:
>> == ndlcom::Communication ==
>>
>> Therefore, I would propose the cpp-library "ndlcom::Communication" to
>> have the following properties:
> 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?
Yes, it is a routing layer -- Messages from the tty (for example) with 
the own receiverId (or Broadcasts) are made available at the 
readPacket() function. The layer has a list at which Interface each 
device was last seen, and uses this to decide where to sent Messages 
from the tty and the writePacket() function.

No it does not exist.

It would be part of the same cpp-library -- the layer on top of the 
single interfaces, which handles opening and closing (calling the 
appropriate functions of iodrivers_base) and administration of "routing 
table".

> Png of ascii art... hmm... doesn't this kind of defeat the purpose?
Yes, that is right. Sadly, I didn't spent that much time with 
Thunderbird till now, and wasn't able to achieve actual plain-text 
messages... Google says its possible, but...This is another story...
>> There are some complex features in this library...
> Is this a statement or an accusation? :)
Both. I didn't got everything due to missing example-usages of 
iodrivers_base::IOListener and iodrivers_base::Bus in rock.dfki -- seems 
like it's there but not used anywhere. So I don't really get what they 
are intended for.
>
>> ...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.
Yes, this is true all the time -- there are different devices on a bus 
(actually a kind of LVDS daisy-chain, where each device forwards 
messages from one UART to the other, interleaving it's own messages if 
required). So there are messages from different senders to different 
receivers of different types on one tty.
> 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,
Hm, like the proposed ndlcom::Communication, with added filtering of the 
Messages to provide different "scopes"(?) like in the "watch" interface 
of the iodrivers_base-CAN Task?
>   and multiple Plugin-Tasks, that
> have access to the core task, and provide the specific interface types (e.g.
> base::Joints).
...and then Rock-Tasks (Plugins) subscribe for all Messages of a certain 
device, or a certain device+certain type via the "watch"-like interface 
of the previous Rock-Task?

Thanks for the feedback!
     Martin

-- 
   M.Sc. Martin Zenzes
   Space Robotics

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

   Phone: +49 (0) 421 178 45 - 6658
   Fax:   +49 (0) 421 178 45 - 4150
   E-Mail: martin.zenzes 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
  -----------------------------------------------------------------------



More information about the Rock-dev mailing list