Hello,
Asebaswitch is not the only user, _any_ user of aseba on the robot can
directly use the can layer, we can get ride of asebaswitch completly
on the
robot. Thus eliminating one context switch for each aseba packet
exchanged.
By the way, are you re-using
transport/can/can-net.*? Because these files already implement the Aseba
CAN protocol.
For now, no. Because can-net is really tailored to a microcontroller. The
socketcan layer simplify quite a lot the handling of can msg, thus it
has it's
own aseba-can implementation.
Therefore, it is essentially a matter of glue to add
support for CAN to asebaswitch using them, isn't it?
Well, ideally to any aseba protocol user, hence the dashel hack.
On my side I plan to use Ubuntu and ROS on the omap3 board, therefore I
will also add CAN support to asebaros, which would reduce delays and
context switches between the CAN bus and ROS.
What do you think?
Let's get ride of asebaswitch (at least for internal communication in the
robot) :)
For this use case I agree.
But there are also two other use cases: asebaros and the remote
connection to the robot using TCP.
We need a layer in-between Dasehl and all the aseba* tools.
So here is my consensual suggestion: we add support to Dashel to
register new stream types at runtime (this means somehow turning
Dashel::Hub into a proper factory with a registration mechanism so that
Hub::connect() can instantiate user-provided streams). This is
essentially re-factoring your patch, so that third party using Dashel
will not depend on Aseba.
What do you think?
Ok for me. Can you provide a patch for Dashel to register new streams?
I can then convert my code to use this new infrastructure. We
will have then to find a proper place to register this stream for
all the aseba tools. Philippe proposes to perform this in one of the
aseba*.a libraries's constructor, or maybe create an aseba-net
library for this purpose.
Thank you,
Florian
_______________________________________________
Aseba-dev mailing list
Aseba-dev@gna.org
https://mail.gna.org/listinfo/aseba-dev