[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