[ros-users] motor control driver (CiA DSP 402 EPOS/ELMO)

[Piotr Trojanek]

Stéphane,

I have included Marti into discussion, as he can be interested in it and I
think we have
to definitely share our future efforts.

To sum up: it seems, that currently we have at least 3 different libraries
for MAXON
motion controllers:

1. Stéphane's, which is written in C and talks with MAXON using CPC-CAN USB
interface
from PORT GmbH and its proprietary API [1] (source code attached to the
ros.org mailing
list thread),

2. C++ API from Marti [2], which talks with EPOS over internal USB (FTDI)
interface,

3. C++ rewrite of original (?) libepos [3] code by me, which talks with EPOS
over both USB
and RS232 links.

All of them seems to have a pretty nice documentation. I think we share an
opinion,
that C++ is the way to go. We all use our libraries under Linux as the MAXON
and
ELMO seems to provides Windows folks with their own proprietary API.

I think, that the most important drawback of our libraries at the moment is
that they:

a) Do not support different/all interfaces to the hardware (RS232/USB/CAN,
CAN over RS232/USB).

I think, that this should be solved with an abstract class concept with the
common methods,
i.e. open/close together with write/receive a message. This class should be
have concrete
implementation for different interfaces and then can be used as a member of
policy for
common class, which implements the logic of the controller.

b) Have different API names for the same things.

As far as we consider EPOS - I think we should follow the MAXON manual and
Win32 API convention.
If we consider DS402, we should follow names from that specification. As the
CiA DS 402 is not freely
available I propose to use the ELMO document.

c) Have different dependencies.

I think, that the implementation should not depend on our robotics
frameworks. People, who
want to use it should be able to compile it without installing any uncommon
software. In particular
there should be different dependencies for the hardware interfaces classes
(i.e. libftdi). For the
common logic I think there should be not more dependency than a Boost.

d) The DS-402 can be implemented only after dealing with above issues.

I also do not like the code of CanFestival. It is not too clean, not too
documented, do not have any
release. I do not expect that any distro provide a package for this library.

What do you think?

[1]
http://www.port.de/pages/products/can/canopen/hardware/usb_cani.php?lang=en
[2] http://wikiri.upc.es/index.php/Epos2_controller_driver
[3] http://www.lsw.uni-heidelberg.de/users/mhauser/libEPOS/

2010/12/2 Stéphane Magnenat <stephane.magnenat at mavt.ethz.ch>

> Hi Piotr,
>
>
> > Have you consider to base your work on the CanFestival [1] project?
>
> Yes, and after reading its sources I decided not to use it.
>
>
>  I am currently working on pretty much the same job that you have probably
>> already done. At this moment I am communicating with my EPOS2 devices
>> with USB and RS232 [3]. I have gathered code from various sources [2]
>> (together
>> with mentioned patches), cleaned it up a bit and put it into a C++ class.
>>
>
> Thank you for sharing this! :-)
>
>
>  The CAN chip inside my embedded pc-board is the SJA1000 supported with
>> the standard Linux sja1000_isa kernel module. Now I was going to implement
>> the CANopen master with help of CanFestival. This project seems to be a
>> kind
>> of overhead, but what is is nice, that it supports different OSes. I
>> think that this is
>> the way to go in the spirit of the open-source community.
>>
>
> My feeling after reading CanFestival's source code was that it was designed
> to implement OpenCAN devices inside microcontrollers, not to provide an
> easy-to-use client-side implementation.
>
>
>  I can see, that your repository contains just a very initial stage of
>> the project.
>>
>
> Yes, the existing C libraries are much more developed (see attachment), but
> we thought that we had to re-architecture the whole stuff. In particular, we
> wanted to:
> - be vendor agnostic and so to implement CiA DSP 402 in a superclass and
> the EPOS/ELMO-specific stuff in subclasses. Unfortunately, to detect the
> vendor automatically, one needs to read STRING objects from OpenCAN, which
> is a bit more work to implement than integers, because it does not fit in a
> single CAN packet anymore;
> - have clean separation between CAN adapter (to access the bus), OpenCAN
> protocol, and motor-controller device;
> - use exceptions to ease the reading of the code.
>
>
>  Do you think you can share more of your work? I would be happy to merge
>> the my code [3] with your CanOpen layer.
>>
>
> Yes, I have attached it to this email. The current version is LGPL, but we
> might change the license for the refactored library. We might switch to BSD
> to ease compatibility with ROS.
>
> It would be great to collaborate; how do you see it?
>
> Kind regards,
>
> Stéphane
>
> --
> Dr Stéphane Magnenat
> http://stephane.magnenat.net
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>


-- 
Piotr Trojanek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101203/d54c943b/attachment-0003.html>