Trajectory Generator/lwr_fri component communication

Submitted by gajan on Mon, 2011-09-05 14:16

Orocos-users

Hi Guys,

We are users of the lwr_fri (2.x) and the trajectory_generators
Ref: http://people.mech.kuleuven.be/~rsmits/Public_Git/trajectory_generators.git

Seeing from the implementation, I think the intended usage is that, we
run the trajectory_generator component at a certain frequency (let's
say 20ms) and open the FRI at a certain rate (say 20 ms). With this
setup, when a packet arrives from the KRC to the remote PC socket, the
FRI component reads the cmdPos from the trajectory_generator
outputport and sends the command to the KRC. The trajectory generator
continues updating its outputport at a constant frequency.

Is this the correct way ? IMHO, the trajectory_generator should be a
peer of FRI and have a method getCmdPos. The KRC packet arriving at
the socket (Event) should drive the full process, calling getCmdPos of
the peer and sending it back to KRC.

We, actually experienced some problems with the current method. We
observed a microsecond order variance and mean on the error between
the desired and actual FRI sampling times. That is. we are being
requested by the KRC/FRI on average, every 20.001 milliseconds instead
of every 20.000 milliseconds. This would not be of any importance for
short runs of the robot. But in a 400 seconds movement, we have a
total shift of 20 ms. This causes that, at some point, one of the
positions of the trajectory that we are calculating (@ 20.000 ms by
the trajectory_generator) is overlooked, causing the requested
velocity to be double the intended one. And this spike in the velocity
causes the robot to hit the speed limit.

We solved it by modifying the lwr_fri by making it event driven with
the FRI packets arriving at the socket.

Sorry if it is a bit confusing. If you want we can send some plots and
additional explanations, log files etc.

Best Regards,
Gajan and Fran

Trajectory Generator/lwr_fri component communication

Submitted by Ruben Smits on Mon, 2011-09-05 17:48.

On Monday 05 September 2011 16:13:47 Gajamohan Mohanarajah wrote:
> Hi Guys,
>
> We are users of the lwr_fri (2.x) and the trajectory_generators
> Ref:
> http://people.mech.kuleuven.be/~rsmits/Public_Git/trajectory_generators.git
>
> Seeing from the implementation, I think the intended usage is that, we
> run the trajectory_generator component at a certain frequency (let's
> say 20ms) and open the FRI at a certain rate (say 20 ms).

The FRI component is already triggered by the socket, without any adaptations
to the code.

> With this
> setup, when a packet arrives from the KRC to the remote PC socket, the
> FRI component reads the cmdPos from the trajectory_generator
> outputport and sends the command to the KRC. The trajectory generator
> continues updating its outputport at a constant frequency.
>
> Is this the correct way ? IMHO, the trajectory_generator should be a
> peer of FRI and have a method getCmdPos. The KRC packet arriving at
> the socket (Event) should drive the full process, calling getCmdPos of
> the peer and sending it back to KRC.
>
> We, actually experienced some problems with the current method. We
> observed a microsecond order variance and mean on the error between
> the desired and actual FRI sampling times. That is. we are being
> requested by the KRC/FRI on average, every 20.001 milliseconds instead
> of every 20.000 milliseconds. This would not be of any importance for
> short runs of the robot.

How is your FRIcomponent being run? Is a periodic activity (it shouldn't!)? Is
it running on a realtime OS? (e.g. Xenomai)? Are you using the RTNet
extention? How are you measuring time, using the RTT::TimeService?

> But in a 400 seconds movement, we have a
> total shift of 20 ms. This causes that, at some point, one of the
> positions of the trajectory that we are calculating (@ 20.000 ms by
> the trajectory_generator) is overlooked, causing the requested
> velocity to be double the intended one. And this spike in the velocity
> causes the robot to hit the speed limit.
>
> We solved it by modifying the lwr_fri by making it event driven with
> the FRI packets arriving at the socket.

This should not be necessary, the current code already works like this. What
you should do is make the trajectory_generator event_driven, you could easily
do this by adding the measurement port as an event port, instead of a plain
port, and not execute it using a periodic activity.

> Sorry if it is a bit confusing. If you want we can send some plots and
> additional explanations, log files etc.
>
> Best Regards,
> Gajan and Fran

-- Ruben

Trajectory Generator/lwr_fri component communication

Submitted by gajan on Tue, 2011-09-06 06:00.

Hi Ruben,

On Mon, Sep 5, 2011 at 7:44 PM, Ruben Smits
<ruben [dot] smits [..] ...> wrote:
> On Monday 05 September 2011 16:13:47 Gajamohan Mohanarajah wrote:
>> Hi Guys,
>>
>> We are users of the lwr_fri (2.x) and the trajectory_generators
>> Ref:
>> http://people.mech.kuleuven.be/~rsmits/Public_Git/trajectory_generators.git
>>
>> Seeing from the implementation, I think the intended usage is that, we
>> run the trajectory_generator component at a certain frequency (let's
>> say 20ms) and open the FRI at a certain rate (say 20 ms).
>
> The FRI component is already triggered by the socket, without any adaptations
> to the code.
>
>> With this
>> setup, when a packet arrives from the KRC to the remote PC socket, the
>> FRI component reads the cmdPos from the trajectory_generator
>> outputport and sends the command to the KRC. The trajectory generator
>> continues updating its outputport at a constant frequency.
>>
>> Is this the correct way ? IMHO, the trajectory_generator should be a
>> peer of FRI and have a method getCmdPos. The KRC packet arriving at
>> the socket (Event) should drive the full process, calling getCmdPos of
>> the peer and sending it back to KRC.
>>
>> We, actually experienced some problems with the current method. We
>> observed a microsecond order variance and mean on the error between
>> the desired and actual FRI sampling times. That is. we are being
>> requested by the KRC/FRI on average, every 20.001 milliseconds instead
>> of every 20.000 milliseconds. This would not be of any importance for
>> short runs of the robot.
>
> How is your FRIcomponent being run? Is a periodic activity (it shouldn't!)? Is
> it running on a realtime OS? (e.g. Xenomai)? Are you using the RTNet
> extention? How are you measuring time, using the RTT::TimeService?

FRIcomponent is not running as a periodic activity. It is being driven
by the socket events.
I am not running orocos with with the gnu-linux option. No hard real time.
For measuring time I used os::TimeService.

>> But in a 400 seconds movement, we have a
>> total shift of 20 ms. This causes that, at some point, one of the
>> positions of the trajectory that we are calculating (@ 20.000 ms by
>> the trajectory_generator) is overlooked, causing the requested
>> velocity to be double the intended one. And this spike in the velocity
>> causes the robot to hit the speed limit.
>>
>> We solved it by modifying the lwr_fri by making it event driven with
>> the FRI packets arriving at the socket.
>
> This should not be necessary, the current code already works like this. What
> you should do is make the trajectory_generator event_driven, you could easily
> do this by adding the measurement port as an event port, instead of a plain
> port, and not execute it using a periodic activity.
I agree. Why didn't I think of it :)
I will modify the my measurement port and keep lwr_fri untouched.

Thanks Ruben !
Gajan

>> Sorry if it is a bit confusing. If you want we can send some plots and
>> additional explanations, log files etc.
>>
>> Best Regards,
>> Gajan and Fran
>
> -- Ruben
>

Trajectory Generator/lwr_fri component communication

Submitted by Ruben Smits on Mon, 2011-09-05 17:48.

On Monday 05 September 2011 19:44:17 Ruben Smits wrote:
> On Monday 05 September 2011 16:13:47 Gajamohan Mohanarajah wrote:
> > Hi Guys,
> >
> > We are users of the lwr_fri (2.x) and the trajectory_generators
> > Ref:
> > http://people.mech.kuleuven.be/~rsmits/Public_Git/trajectory_generators.
> > git

BTW, that code is not longer maintained, it's better to switch to our new
motion_control stack (devel branch ATM) located at
git.mech.kuleuven.be/robotics/motion_control.git

[...]

-- Ruben

Trajectory Generator/lwr_fri component communication

Submitted by Ruben Smits on Wed, 2011-09-07 10:20.

On Wednesday 07 September 2011 11:27:31 luca [dot] gherardi [..] ... wrote:
> Hi Ruben,
>
> why I receive this error when I try to download the motion control stack? Is
> it ok?
>
>

> lucagheraMB:Downloads luca$ git clone
> http://git.mech.kuleuven.be/robotics/motion_control.git Cloning into
> motion_control...
> error: inflate: data stream error (incorrect header check)
> error: inflate: data stream error (incorrect header check)
> error: File b89726459c2082ba4895ac61c71af5228121cf42
> (http://git.mech.kuleuven.be/robotics/motion_control.git/objects/b8/9726459
> c2082ba4895ac61c71af5228121cf42) corrupt error: inflate: data stream error
> (incorrect header check)
>

I don't know exactly, it could be that some parts in the git history are
screwed up, but you should still end up with a full checkout, and a working
repository.

> Thanks,
>
> Luca

-- Ruben

Ruben Smits wrote:

On Monday 05 September 2011 19:44:17 Ruben Smits wrote:
> > On Monday 05 September 2011 16:13:47 Gajamohan Mohanarajah wrote:
> > > Hi Guys,
> > >
> > > We are users of the lwr_fri (2.x) and the trajectory_generators
> > > Ref:
> > > http://people.mech.kuleuven.be/~rsmits/Public_Git/trajectory_generat
> > > ors. git
>
> BTW, that code is not longer maintained, it's better to switch to our new
> motion_control stack (devel branch ATM) located at
> git.mech.kuleuven.be/robotics/motion_control.git
>
> [...]
>
> -- Ruben
>
>

Re: Trajectory Generator/lwr_fri component communication

Submitted by luca.gherardi on Wed, 2011-09-07 09:27.

Hi Ruben,

why I receive this error when I try to download the motion control stack? Is it ok?

lucagheraMB:Downloads luca$ git clone http://git.mech.kuleuven.be/robotics/motion_control.git
Cloning into motion_control...
error: inflate: data stream error (incorrect header check)
error: inflate: data stream error (incorrect header check)
error: File b89726459c2082ba4895ac61c71af5228121cf42 (http://git.mech.kuleuven.be/robotics/motion_control.git/objects/b8/9726459c2082ba4895ac61c71af5228121cf42) corrupt
error: inflate: data stream error (incorrect header check)

Thanks,

Luca

Ruben Smits wrote:

On Monday 05 September 2011 19:44:17 Ruben Smits wrote: > On Monday 05 September 2011 16:13:47 Gajamohan Mohanarajah wrote: > > Hi Guys, > > > > We are users of the lwr_fri (2.x) and the trajectory_generators > > Ref: > > http://people.mech.kuleuven.be/~rsmits/Public_Git/trajectory_generators. > > git

BTW, that code is not longer maintained, it's better to switch to our new motion_control stack (devel branch ATM) located at git.mech.kuleuven.be/robotics/motion_control.git

[...]

-- Ruben

Trajectory Generator/lwr_fri component communication

Submitted by Tinne De Laet on Wed, 2011-09-07 11:20.

On Wednesday 07 September 2011 11:27:31 luca [dot] gherardi [..] ... wrote:
> Hi Ruben,
>
> why I receive this error when I try to download the motion control stack?
> Is it ok?
>
>

> lucagheraMB:Downloads luca$ git clone
> http://git.mech.kuleuven.be/robotics/motion_control.git Cloning into
> motion_control...
> error: inflate: data stream error (incorrect header check)
> error: inflate: data stream error (incorrect header check)
> error: File b89726459c2082ba4895ac61c71af5228121cf42
> (http://git.mech.kuleuven.be/robotics/motion_control.git/objects/b8/972645
> 9c2082ba4895ac61c71af5228121cf42) corrupt error: inflate: data stream error
> (incorrect header check)
>

>
You can ignore this error.

Tinne

> Thanks,
>
> Luca
>
>

Ruben Smits wrote:

On Monday 05 September 2011 19:44:17 Ruben Smits wrote:
> > On Monday 05 September 2011 16:13:47 Gajamohan Mohanarajah wrote:
> > > Hi Guys,
> > >
> > > We are users of the lwr_fri (2.x) and the trajectory_generators
> > > Ref:
> > > http://people.mech.kuleuven.be/~rsmits/Public_Git/trajectory_generators
> > > . git
>
> BTW, that code is not longer maintained, it's better to switch to our new
> motion_control stack (devel branch ATM) located at
> git.mech.kuleuven.be/robotics/motion_control.git
>
> [...]
>
> -- Ruben
>
>

Trajectory Generator/lwr_fri component communication

Submitted by bruyninc on Mon, 2011-09-05 15:08.

On Mon, 5 Sep 2011, Gajamohan Mohanarajah wrote:

> We are users of the lwr_fri (2.x) and the trajectory_generators
> Ref: http://people.mech.kuleuven.be/~rsmits/Public_Git/trajectory_generators.git
>
> Seeing from the implementation, I think the intended usage is that, we
> run the trajectory_generator component at a certain frequency (let's
> say 20ms) and open the FRI at a certain rate (say 20 ms). With this
> setup, when a packet arrives from the KRC to the remote PC socket, the
> FRI component reads the cmdPos from the trajectory_generator
> outputport and sends the command to the KRC. The trajectory generator
> continues updating its outputport at a constant frequency.
>
> Is this the correct way ? IMHO, the trajectory_generator should be a
> peer of FRI and have a method getCmdPos.

This is a bit contradictory terminology: peers do not give "commands" to
each other, they exchange "information"! The current implementation is peer
to peer, in the sense that no-one of the components is the master. Using
command requests makes your architecture into a client-server one. There is
nothing fundamentally wrong with that, but also not with the peer-to-peer
architecture (which is data driven, instead of request driven). You always
have the choice between these two architectures (or yet other variations)
and it is rather impossible to way which one is "better" (in all
situations).

> The KRC packet arriving at
> the socket (Event) should drive the full process, calling getCmdPos of
> the peer and sending it back to KRC.
>
> We, actually experienced some problems with the current method. We
> observed a microsecond order variance and mean on the error between
> the desired and actual FRI sampling times. That is. we are being
> requested by the KRC/FRI on average, every 20.001 milliseconds instead
> of every 20.000 milliseconds. This would not be of any importance for
> short runs of the robot. But in a 400 seconds movement, we have a
> total shift of 20 ms. This causes that, at some point, one of the
> positions of the trajectory that we are calculating (@ 20.000 ms by
> the trajectory_generator) is overlooked, causing the requested
> velocity to be double the intended one. And this spike in the velocity
> causes the robot to hit the speed limit.

A real peer-to-peer architecture should be robust against this kind of tiny
differences in timing! In other, more practical, words: this kind of loss
of sample will not occur if the data flow between peers uses only the last
received data, and is not buffering. By definition of a well designed
controller, this should do the job; if you _do_ depend on not missing any
generated sample, your controller is, well,... not really a controller :-)

> We solved it by modifying the lwr_fri by making it event driven with
> the FRI packets arriving at the socket.

That could be a good solution. But maybe it is not so good in other use
cases, where the FRI should take into account more communications than only
the one coming from the trajectory generator; for example, the trajectory
can be adapted on the basis of sensing information. As you see: it's very
difficult to say what architecture is best. (In other words, system design
is still more of an art than of a science...)

> Sorry if it is a bit confusing. If you want we can send some plots and
> additional explanations, log files etc.
>
> Best Regards,
> Gajan and Fran

Best regards,

Herman Bruyninckx

Trajectory Generator/lwr_fri component communication

Submitted by gajan on Tue, 2011-09-06 05:52.

Hi Herman,

Thank you for your reply.

>
> This is a bit contradictory terminology: peers do not give "commands" to
> each other, they exchange "information"! The current implementation is peer
> to peer, in the sense that no-one of the components is the master. Using
> command requests makes your architecture into a client-server one. There is
> nothing fundamentally wrong with that, but also not with the peer-to-peer
> architecture (which is data driven, instead of request driven). You always
> have the choice between these two architectures (or yet other variations)
> and it is rather impossible to way which one is "better" (in all
> situations).
Sorry for the misuse in terminology. What I intended was a
client-server architecture.

>> The KRC packet arriving at
>> the socket (Event) should drive the full process, calling getCmdPos of
>> the peer and sending it back to KRC.
>>
>> We, actually experienced some problems with the current method. We
>> observed a microsecond order variance and mean on the error between
>> the desired and actual FRI sampling times. That is. we are being
>> requested by the KRC/FRI on average, every 20.001 milliseconds instead
>> of every 20.000 milliseconds. This would not be of any importance for
>> short runs of the robot. But in a 400 seconds movement, we have a
>> total shift of 20 ms. This causes that, at some point, one of the
>> positions of the trajectory that we are calculating (@ 20.000 ms by
>> the trajectory_generator) is overlooked, causing the requested
>> velocity to be double the intended one. And this spike in the velocity
>> causes the robot to hit the speed limit.
>
> A real peer-to-peer architecture should be robust against this kind of tiny
> differences in timing! In other, more practical, words: this kind of loss
> of sample will not occur if the data flow between peers uses only the last
> received data, and is not buffering. By definition of a well designed
> controller, this should do the job; if you _do_ depend on not missing any
> generated sample, your controller is, well,... not really a controller :-)
I agree ! It is the FRI :( that gives us no option but to do a fine
interpolation on position and
command it with out losing any packets.

Best Regards,
Gajan

>> We solved it by modifying the lwr_fri by making it event driven with
>> the FRI packets arriving at the socket.
>
> That could be a good solution. But maybe it is not so good in other use
> cases, where the FRI should take into account more communications than only
> the one coming from the trajectory generator; for example, the trajectory
> can be adapted on the basis of sensing information. As you see: it's very
> difficult to say what architecture is best. (In other words, system design
> is still more of an art than of a science...)
>
>> Sorry if it is a bit confusing. If you want we can send some plots and
>> additional explanations, log files etc.
>>
>> Best Regards,
>> Gajan and Fran
>
> Best regards,
>
> Herman Bruyninckx
>
>