[Rock-dev] TrajectoryFollower writing stop commands for no trajectory

[Christian Rauch]

Am 21.03.2014 11:57, schrieb Matthias Goldhoorn:
> On 21.03.2014 10:56, Christian Rauch wrote:
>> Hi,
>>
>> the TrajectoryFollower::Task is currently writing stop motion commands
>> (0,0) if:
>> - there is no pose
>> - there is no trajectory set
>> - it reached the end of the trajectory
>>
>> I would like to have the task only sending motion commands when it
>> actually follows a trajectory. In all of the cases above the
>> TrajectoryFollower has nothing to follow and should therefore not
>> generate any commands.
>>
>> The reason is that the TrajectoryFollower blocks other tasks from
>> writing motion commands to the driver, even if it does not has
>> anything to do.
> Did i understand right, that you have multiple input connections to one
> task.
> this is in general a bad idea, this is supported by orogen, but we do
> not recommend this kind of usage for rock-setups.
> I would recommend to re-think of your component design. Writing a zero
> command if the component is not sure is for me a good design, to keep
> the control-loop alive.
At run time the network may change. Example: An action is stopped, not 
writing trajectories any more (respectively writing an empty trajectory) 
and another action writing raw motion command is started.

The point is, that we are using the corridor servoing where its 
functionality (map building, planning) is not separated and we do not 
want to stop the task as we would lose the map then. The planner then 
sends empty trajectories, even when it is not planning. Therefore the 
trajectory follower is always active, even without following a trajectory.

I only see two solutions for this: 1) separating the map building from 
the planning in the corridor servoing or 2) prevent the generation of 
motion commands in the trajectory follower, when not following trajectories.

 From my point of view, a component should not generate commands when it 
is actually not controlling anything.

Kind regards,
Christian

>
> If you need something like this introduce switching-components or keep
> only one active component for your motion input.
>
> Best,
> Matthias
>
>
>>
>> Opinions?
>>
>> Regards,
>> Christian
>>
>>
>>
>>
>> _______________________________________________
>> Rock-dev mailing list
>> Rock-dev at dfki.de
>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>
>

-- 
  Christian Rauch
  Space Robotics

  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-6619
  Empfang: +49 421 178 45-6600
  Fax:     +49 421 178 45-4150
  E-Mail:  Christian.Rauch at dfki.de

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4988 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.dfki.de/pipermail/rock-dev/attachments/20140321/6776c8a9/attachment.bin