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@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@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users




--
Piotr Trojanek