[Rock-dev] make moving speed configurable in orogen-servo_dynamixel / dynamixel

Matthias Goldhoorn matthias.goldhoorn at dfki.de
Wed Dec 11 17:18:07 CET 2013


On 11.12.2013 15:13, Alexander Duda wrote:
> On 12/11/2013 02:25 PM, Jakob Schwendner wrote:
>>> Our policy is:
>>> * stop the component
>>> * reconfigure it via properties
>>> * restart the component
>>>
>>> In some special cases if there is no other way than changing properties
>> while
>>> the component is running the dynamic properties should be used.
>>> Can you please point out why this is the case here?
>> The use case would be to change the max speed value for the servo, 
>> without
>> having to restart. E.g. your source component only provides 
>> positions, but
>> not speeds, and you want to set the speed depending on e.g. some sort of
>> system state. Using an input port here wouldn't do justice to the 
>> nature of
>> the data, I think. As Matthias pointed out, this seems to be a safe 
>> thing to
>> do now, and is meant for exactly these cases.
> I have my doubt here.
> * basically, you want to combine two commands (speed and position) 
> with the help of dynamic properties which sounds kind of bad.
I thought we disussing a maximum_moving_speed configiration option?!

> * if you have a system state change you most-likely reconfigure your 
> hole network anyway.
Even then, why restart/stop this comonent?
> * dynamic properties make it incredible complex to test your components
Why? -> every configuration is hard to re-apply so long Syskit supports 
no real replay...
> * there is no logging if you change properties from vizkit
Logging of properties is afaik possible
> * we have no tooling allowing to reconfigure tasks dynamically 
> according to log files
It's not done even for normal property reconfigurations, you have to log 
them and manually apply. (same for connections and so on)). The 
Toolchain supports no "start and use this component as live" it in 
general supports only rebuilding data-streams manually.
>
> For me the hole dynamic property thing is a really bad idea and not 
> needed in 99% of the cases.
Don't agree, even for you cameras (like exposure) for example it's 
needed to reconfigure this without restarting...

>
> Alex
>
Matthias

P.S. maybe we should move this discussion if there is a need to to the 
next rock-meeting -> i stopping here now for the public one...

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



More information about the Rock-dev mailing list