[Rock-dev] mars_core removing of Depreciated Tasks: MarsServo and MarsJoint

[Matthias Goldhoorn]

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:  matthias.goldhoorn at informatik.uni-bremen.de

  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik