On 09.12.2013 10:21, Steffen Planthaber wrote: > Hi, > > That was quite fast... > > Actually I have a problem with the removal as the old Mars::Servo type. > It models directly the rock dynamixel driver The driver should be changed in the same way > , including an automatic > sweep mode, which is afaik not included into Mars::Joints. Not part of the joint standard, so should be removed too > > Also "not so nice" is the fact that i have to provide a vector of > commands to a instance with a single motor (servo). This was was the result of the discussion on rock-dev about an standardized format was. > > I see following options: > > 1) Re-Adding the Mars::Servo (evt. with different name (the driver it > models "Mars::Dynamixel")) I'm againt it, sinc'e the servo shoul be changed too > > 2) An additional package for deprecated orogen-mars-plugin types If you really need this and don't want to transition you packages i would be fine but i would like to recommend the transition to the new joint standart. The transistion already took too long, that's the reason why we get in trouble here. But i don't want to support depricated pacakges/types anymore, it tje servo "hangs behind" the dynamixel-servo should be ported too, but the package where i'm more or less responsible for i removed the deprivated functionallity. > > 3) A new package for mars plugins directly modelling existing drivers > "simulation/orogen/mars_driver_models" ??? what's this in different to 1) or 2) ?? we just decided to throw away base/interfaces ?! > > 4) Introduce the same structure for rock simulation drivers as for the > original ones (a single package for each Mars driver that directly > simulates a rock driver) Would make mars_core smaller but i see no point to adding it directly.
> > > I'd prefer option 4) they can have single (rock) packages, as they are > not needed in the standlone mars. They model rock specific drivers and > are unlikely to be used without using rock. mars_standalone is simulation/mars/app, or what do you mean with "standalone mars"? since it's a orogen component, and mars_core defines only orogen components. All orogen modules does exactly this, the modeling a interface to an underlying in depended library (in this case mars). Option 4) should be done for every task that needs non-base-types. Everything else could go in there from my point of view. > > > Best, Steffen Best, Matthias > > > Am 05.12.2013 15:47, schrieb Matthias Goldhoorn: >> Hi together >> >> Sinc'e the new Joints type is the only recommended i would like to >> remove the depreciated one's from mars. >> If someone still need them (for a demo or something else) please stick >> to the current mars_core rock component. >> I will push the changes tomorrow. >> >> Matthias >> > -- Dipl.-Inf. Matthias Goldhoorn Space and Underwater Robotic Universität Bremen FB 3 - Mathematik und Informatik AG Robotik Robert-Hooke-Straße 1 28359 Bremen, Germany Zentrale: +49 421 178 45-6611 Besuchsadresse der Nebengeschäftstelle: Robert-Hooke-Straße 5 28359 Bremen, Germany Tel.: +49 421 178 45-4193 Empfang: +49 421 178 45-6600 Fax: +49 421 178 45-4150 E-Mail: [email protected] Weitere Informationen: http://www.informatik.uni-bremen.de/robotik _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
