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

[Piotr Trojanek]

Stéphane and Marti,

I am glad to hear, that we all agree!

I understand, that nobody of us is interested in changing an already working
solution,
because this is not the point of our research. I have not yet integrated the
EPOS with
my team's framework, so I have almost nothing to loose. I can easily switch
to any code
- I simply do not want to develop it from scratch, but I prefer to give my
time to the benefit
of the open-source community.

As the Marti's code is the most defendant on a stuff we do not want to
depend on and
at the same time he has no profit in redesigning an API, etc. my proposal is
as follows:

1. I will try to add my USB transport to the C code of Stéphane following of
an "adapter class"
concept already present in the library. The SocketCAN also needs to be
developed from scratch
and I am interested in doing this anyway.

I think, that adding those two transports to the C library is not wasting
time, because they can
be as easily translated to C++ as already existing CPC and RS232 ones.

2. At the same time Stéphane can freely continue an effort of translating
the C library to C++,
which was intended anyway. I am happy to contribute to this!

Stéphane, can you put the C code on the Github? I would develop USB and
SocketCAN transports
within my own branch, so if I discover some issues, it will be easier to
merge them into original code.

My Github profile is https://github.com/ptroja.

On Fri, Dec 3, 2010 at 12:13, <mmorta at iri.upc.edu> wrote:

> Hello,
> I am in the ros users lists too, so its not necessary to add me in copy :)
>
> I agree with both of you.
>
> My library has the dependences on communications (FTDI,RS232) and
> utilities (time,threads,events) libraries made in our institute, the only
> external library they need is the ftdiD2XX.
>
> At the moment I don't have so much time for this, but I would be glad to
> help you as much as I can. I've never worked with git, I'll have a look
> there and create a user.
>
> kind regards,
>
> Martí
>
>
> > Hi Piotr, Marti and the list!
> >
> >> 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.
> >
> > Yes, I fully agree, that was the goal of the abstract "Adapter class" in
> > [1]. It should be in its own class, maybe in the "Can" namespace in a
> > can.h file.
> >
> >> 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.
> >
> > I also agree, I was following ELMO's document for naming members in
> > struct MotorDriver in [2].
> >
> >> 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.
> >
> > I agree again, the idea on our side was to make a library with minimal
> > forced dependencies (ideally only Linux, maybe boost). The cmake should
> > check for additional dependencies and should enable the compilation of
> > the various hardware-dependent codes when the related libraries are
> > present.
> >
> >> 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?
> >
> > I think that we agree enough on the way to follow so that we can work
> > together. I can give you (and other interested people) write access to
> > our cia-dsp-402 repository and we can start writing together the basic
> > bricks (hardware access modules, OpenCAN interfaces, etc.) and then move
> > to the DS-402 specification. What is your github username?
> >
> > All the best,
> >
> > Stéphane
> >
> > [1]
> >
> https://github.com/ethz-asl/libcia-dsp-402/blob/master/cia-dsp-402/canopen.h
> > [2]
> >
> https://github.com/ethz-asl/libcia-dsp-402/blob/master/cia-dsp-402/cia-dsp-402.h
> >
> > --
> > 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
> >
>
> _______________________________________________
> 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/6f66c2f4/attachment-0003.html>