[ros-users] motor control driver (CiA DSP 402 EPOS/ELMO)
mmorta at iri.upc.edu
mmorta at iri.upc.edu
Fri Dec 3 11:13:52 UTC 2010
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
>
More information about the ros-users
mailing list