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

_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users



--
Piotr Trojanek