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, 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