Hello,
Any proposition? For now, it works well with the patch in Dashel...
As there are other Dashel users than Aseba (sensefly, as far as I know),
I propose not to put this code into Dashel. I propose to put the
protocol-agnostic part into Dashel (so that we can use CAN0 along with a
Dashel Hub)
Hu ? dashel implement a simplified abstraction of a point-to-point
communication layer which is fundamentally incompatible with the broadcast,
message-based multimaster communication of a CAN bus.
There's no way you can cleanly have this into dashel without the "aseba
protocol" compatibility layer on top the can.
, but to put the rest inside its own library, that would be
linked and used by asebaswitch.
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.
For the first we can also use socketcan directly (no Dashel), but then
we would loose the ability to use asebaros with the Thymio for instance.
We can of course add the new feature along the current one, but then we
have a two-level abstraction. We can hide it from the user side, but it
would still be somehow a mess in the code because there would be two
synchronisation pathways.
For the remote connection we need to add socketcan support to the
switch. This is necessary for synchronisation between socketcan streams
and tcp/serial streams.
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?
All the best,
Stéphane
--
Dr Stéphane Magnenat
http://stephane.magnenat.net
_______________________________________________
Aseba-dev mailing list
Aseba-dev@gna.org
https://mail.gna.org/listinfo/aseba-dev
