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
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
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
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
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?
>
>
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
>
> > 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
Hi Ruben,
why I receive this error when I try to download the motion control stack? Is it ok?
Thanks,
Luca
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
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?
>
>
>
You can ignore this error.
Tinne
> Thanks,
>
> Luca
>
>
> > 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
>
>