yes RT and non-RT work execute in separated threads but what about shared
data ? as far as i know there is some locking involved ?
Transmitting trajectories in real time is problematic, but i don't think it
is really necessary. Generation of trajectories doesn't have strong time
constraints, so there is no point of executing it in real-time.
Communication between RT and non-RT threads is complex problem, but OROCOS
solves most problems. it use lock-free buffers for communication between
components. Currently in ROS joint_trajectory_action is whole non-RT and
JointSplineTrajectoryControlle is partialy RT. In my solution all non-RT
work are moved into joint_trajectory_action. This make clear border between
RT and non-RT part.
Pozdrawiam
Konrad Banachowicz
2010/9/17 Stuart Glaser <sglaser [..] ...>
> Hi Konrad,
>
> There are no issues with breaking realtime constraints because the
> unsafe code is called from a non-realtime thread.
>
> You're correct that the JointSplineTrajectoryController code performs
> several operation which are not realtime safe. These operations are
> performed not in the realtime loop but rather in the ROS subscriber
> callback, which is called from a non-realtime thread.
>
> Your proposed solution is therefore quite similar to what already
> exists: the non-realtime portion of the
> JointSplineTrajectoryController reorders the joints and composes
> trajectories, and then sends it to the realtime portion which just
> performs interpolation.
>
> There are a few faults with this system, and I'm interested in
> discussing solutions which address them:
> 1. Trajectories cannot be sent from within realtime--they only come
> from outside of realtime.
> 2. The current design has a great deal of complexity, particularly in
> taking care when transferring the trajectory to realtime, composing
> trajectories, and responding with a result to the action.
>
> There's probably more.
>
> That said, this interface allows us to comfortably separate the motion
> planning pipeline from the realtime loop. Once implemented, you can
> run much of the code that was developed to move the PR2 on your own
> robot.
>
> Lastly, you may want to consider examining the
> JointTrajectoryActionController which combines the
> joint_trajectory_action and the JointSplineTrajectoryController.
>
> -Stu
>
> On Fri, Sep 17, 2010 at 3:12 AM, Konrad Banachowicz <konradb3 [..] ...>
> wrote:
> > Hi,
> > I'm working on integration of orocos RT-controller with ROS manipulation
> > pipeline.
> > I already done joint_state_publisher and oro_action_server. Next on my
> list
> > are joint_trajectory_action and JointSplineTrajectoryController.
> > I have some concerns about real-time behaviours of those, and way of
> > implementation in orocos.
> >
> > joint_trajectory_action :
> > It receive goal containing trajectory (variable size, unbounded size),
> then
> > check constraints and send to JointSplineTrajectoryController.
> >
> > JointSplineTrajectoryController:
> > It loop generating interpolated position for joint regulator.
> > When it receive new trajectory it reorder joints in received trajectory
> > (memory allocation, iterating on unknown size array) and try to compose
> > current trajectory with newly received (memory allocation, iterating on
> > unknown size array).
> > It have to by done between two sequential interpolations (in my system
> 1ms).
> >
> > My solution :
> > Data transmited between joint_trajectory_action and
> > JointSplineTrajectoryController contains only single point (constant
> size).
> >
> > joint_trajectory_action do joint reordering and compose trajectories and
> is
> > feeding JointSplineTrajectoryController with trajectory points.
> >
> > JointSplineTrajectoryController interpolate between two points (have one
> > point buffer)
> >
> > This solution should work with trajectories when time between points is
> >>
> > 1ms.
> >
> > What do you think about doing this this way ?
> > What is alternative solutions ?
> > What do you think about re-usability of this solution in yours systems ?
> >
> > Pozdrawiam
> > Konrad Banachowicz
> >
> > _______________________________________________
> > ros-users mailing list
> > ros-users [..] ...
> > https://code.ros.org/mailman/listinfo/ros-users
> >
> >
>
>
>
> --
> Stuart Glaser
> sglaser -at- willowgarage -dot- com
> www.willowgarage.com
> _______________________________________________
> ros-users mailing list
> ros-users [..] ...
> https://code.ros.org/mailman/listinfo/ros-users
>
[ros-users] Control system design question.
On Fri, 17 Sep 2010, Konrad Banachowicz wrote:
> yes RT and non-RT work execute in separated threads but what about shared data ? as
> far as i know there is some locking involved ?
>
> Transmitting trajectories in real time is problematic, but i don't think it is really
> necessary. Generation of trajectories doesn't have strong time constraints, so there
> is no point of executing it in real-time.
That depends on the time frame spanned by your trajectory: in many
sensor-based applications, trajectory generation can be as dynamic as once
every 1/30th of a second (e.g., visual servoing), where a trajectory must
be generated for a motion controller that runs at 250Hz or so.
> Communication between RT and non-RT threads is complex problem, but OROCOS solves
> most problems. it use lock-free buffers for communication between components.
> Currently in ROS joint_trajectory_action is whole non-RT and
> JointSplineTrajectoryControlle is partialy RT. In my solution all non-RT work are
> moved into joint_trajectory_action. This make clear border between RT and non-RT
> part.
>
> Pozdrawiam
> Konrad Banachowicz
>
>
> 2010/9/17 Stuart Glaser <sglaser [..] ...>
> Hi Konrad,
>
> There are no issues with breaking realtime constraints because the
> unsafe code is called from a non-realtime thread.
>
> You're correct that the JointSplineTrajectoryController code performs
> several operation which are not realtime safe. These operations are
> performed not in the realtime loop but rather in the ROS subscriber
> callback, which is called from a non-realtime thread.
>
> Your proposed solution is therefore quite similar to what already
> exists: the non-realtime portion of the
> JointSplineTrajectoryController reorders the joints and composes
> trajectories, and then sends it to the realtime portion which just
> performs interpolation.
>
> There are a few faults with this system, and I'm interested in
> discussing solutions which address them:
> 1. Trajectories cannot be sent from within realtime--they only come
> from outside of realtime.
> 2. The current design has a great deal of complexity, particularly in
> taking care when transferring the trajectory to realtime, composing
> trajectories, and responding with a result to the action.
>
> There's probably more.
>
> That said, this interface allows us to comfortably separate the motion
> planning pipeline from the realtime loop. Once implemented, you can
> run much of the code that was developed to move the PR2 on your own
> robot.
>
> Lastly, you may want to consider examining the
> JointTrajectoryActionController which combines the
> joint_trajectory_action and the JointSplineTrajectoryController.
>
> -Stu
>
> On Fri, Sep 17, 2010 at 3:12 AM, Konrad Banachowicz <konradb3 [..] ...> wrote:
> > Hi,
> > I'm working on integration of orocos RT-controller with ROS manipulation
> > pipeline.
> > I already done joint_state_publisher and oro_action_server. Next on my list
> > are joint_trajectory_action and JointSplineTrajectoryController.
> > I have some concerns about real-time behaviours of those, and way of
> > implementation in orocos.
> >
> > joint_trajectory_action :
> > It receive goal containing trajectory (variable size, unbounded size), then
> > check constraints and send to JointSplineTrajectoryController.
> >
> > JointSplineTrajectoryController:
> > It loop generating interpolated position for joint regulator.
> > When it receive new trajectory it reorder joints in received trajectory
> > (memory allocation, iterating on unknown size array) and try to compose
> > current trajectory with newly received (memory allocation, iterating on
> > unknown size array).
> > It have to by done between two sequential interpolations (in my system 1ms).
> >
> > My solution :
> > Data transmited between joint_trajectory_action and
> > JointSplineTrajectoryController contains only single point (constant size).
> >
> > joint_trajectory_action do joint reordering and compose trajectories and is
> > feeding JointSplineTrajectoryController with trajectory points.
> >
> > JointSplineTrajectoryController interpolate between two points (have one
> > point buffer)
> >
> > This solution should work with trajectories when time between points is >>
> > 1ms.
> >
> > What do you think about doing this this way ?
> > What is alternative solutions ?
> > What do you think about re-usability of this solution in yours systems ?
> >
> > Pozdrawiam
> > Konrad Banachowicz
> >
> > _______________________________________________
> > ros-users mailing list
> > ros-users [..] ...
> > https://code.ros.org/mailman/listinfo/ros-users
> >
> >
>
>
>
> --
> Stuart Glaser
> sglaser -at- willowgarage -dot- com
> www.willowgarage.com
> _______________________________________________
> ros-users mailing list
> ros-users [..] ...
> https://code.ros.org/mailman/listinfo/ros-users
>
>
>
>
--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
[ros-users] Control system design question.
On Fri, 17 Sep 2010, Stuart Glaser wrote:
> There are no issues with breaking realtime constraints because the
> unsafe code is called from a non-realtime thread.
>
> You're correct that the JointSplineTrajectoryController code performs
> several operation which are not realtime safe. These operations are
> performed not in the realtime loop but rather in the ROS subscriber
> callback, which is called from a non-realtime thread.
>
> Your proposed solution is therefore quite similar to what already
> exists: the non-realtime portion of the
> JointSplineTrajectoryController reorders the joints and composes
> trajectories, and then sends it to the realtime portion which just
> performs interpolation.
>
> There are a few faults with this system, and I'm interested in
> discussing solutions which address them:
> 1. Trajectories cannot be sent from within realtime--they only come
> from outside of realtime.
Our research involves mostly (on-line, "soft" realtime sensor-based) use
cases that _need_ realtime generation of trajectories. That means that (i)
they can only be short (which is not a problem in the mentioned use cases),
and (ii) they can only be very simple in the geometric, dynamic,...
constraints that they satisfy. So, the discussion of 'realtime' vs
'trajectories' is not a simple one, but depends on many, many contextual
factors; one should not generalize, but state the context as explicit as
possible.
> 2. The current design has a great deal of complexity, particularly in
> taking care when transferring the trajectory to realtime, composing
> trajectories, and responding with a result to the action.
>
> There's probably more.
Probably :-) This is consistent with my remarks above: there are _a lot_ of
different types of trajectories, and (among many others) the realtime
properties of each type can be very different.
> That said, this interface allows us to comfortably separate the motion
> planning pipeline from the realtime loop. Once implemented, you can
> run much of the code that was developed to move the PR2 on your own
> robot.
I don't think so: ROS node code is extremely difficult to reuse in a
non-ROS software framework.
Herman
> Lastly, you may want to consider examining the
> JointTrajectoryActionController which combines the
> joint_trajectory_action and the JointSplineTrajectoryController.
>
> -Stu
>
> On Fri, Sep 17, 2010 at 3:12 AM, Konrad Banachowicz <konradb3 [..] ...> wrote:
>> Hi,
>> I'm working on integration of orocos RT-controller with ROS manipulation
>> pipeline.
>> I already done joint_state_publisher and oro_action_server. Next on my list
>> are joint_trajectory_action and JointSplineTrajectoryController.
>> I have some concerns about real-time behaviours of those, and way of
>> implementation in orocos.
>>
>> joint_trajectory_action :
>> It receive goal containing trajectory (variable size, unbounded size), then
>> check constraints and send to JointSplineTrajectoryController.
>>
>> JointSplineTrajectoryController:
>> It loop generating interpolated position for joint regulator.
>> When it receive new trajectory it reorder joints in received trajectory
>> (memory allocation, iterating on unknown size array) and try to compose
>> current trajectory with newly received (memory allocation, iterating on
>> unknown size array).
>> It have to by done between two sequential interpolations (in my system 1ms).
>>
>> My solution :
>> Data transmited between joint_trajectory_action and
>> JointSplineTrajectoryController contains only single point (constant size).
>>
>> joint_trajectory_action do joint reordering and compose trajectories and is
>> feeding JointSplineTrajectoryController with trajectory points.
>>
>> JointSplineTrajectoryController interpolate between two points (have one
>> point buffer)
>>
>> This solution should work with trajectories when time between points is >>
>> 1ms.
>>
>> What do you think about doing this this way ?
>> What is alternative solutions ?
>> What do you think about re-usability of this solution in yours systems ?
>>
>> Pozdrawiam
>> Konrad Banachowicz
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users [..] ...
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>
>
>
[ros-users] Control system design question.
Hi,
On Fri, Sep 17, 2010 at 12:53 PM, Konrad Banachowicz <konradb3 [..] ...> wrote:
> yes RT and non-RT work execute in separated threads but what about shared
> data ? as far as i know there is some locking involved ?
The buffer used in the JointSplineTrajectoryController is called a
RealtimeBox. It currently uses a mutex (locked for a guaranteed
maximum number of instructions on a system that supports priority
inheritance), though it can certainly switch to a lock-free buffer.
> Communication between RT and non-RT threads is complex problem, but OROCOS
> solves most problems. it use lock-free buffers for communication between
> components. Currently in ROS joint_trajectory_action is whole non-RT and
> JointSplineTrajectoryControlle is partialy RT. In my solution all non-RT
> work are moved into joint_trajectory_action. This make clear border between
> RT and non-RT part.
Sounds like you've moved the non-realtime parts of the
JointSplineTrajectoryController into your version of the
joint_trajectory_action. That sounds like a reasonable solution.
-Stu
>
> Pozdrawiam
> Konrad Banachowicz
>
>
> 2010/9/17 Stuart Glaser <sglaser [..] ...>
>>
>> Hi Konrad,
>>
>> There are no issues with breaking realtime constraints because the
>> unsafe code is called from a non-realtime thread.
>>
>> You're correct that the JointSplineTrajectoryController code performs
>> several operation which are not realtime safe. These operations are
>> performed not in the realtime loop but rather in the ROS subscriber
>> callback, which is called from a non-realtime thread.
>>
>> Your proposed solution is therefore quite similar to what already
>> exists: the non-realtime portion of the
>> JointSplineTrajectoryController reorders the joints and composes
>> trajectories, and then sends it to the realtime portion which just
>> performs interpolation.
>>
>> There are a few faults with this system, and I'm interested in
>> discussing solutions which address them:
>> 1. Trajectories cannot be sent from within realtime--they only come
>> from outside of realtime.
>> 2. The current design has a great deal of complexity, particularly in
>> taking care when transferring the trajectory to realtime, composing
>> trajectories, and responding with a result to the action.
>>
>> There's probably more.
>>
>> That said, this interface allows us to comfortably separate the motion
>> planning pipeline from the realtime loop. Once implemented, you can
>> run much of the code that was developed to move the PR2 on your own
>> robot.
>>
>> Lastly, you may want to consider examining the
>> JointTrajectoryActionController which combines the
>> joint_trajectory_action and the JointSplineTrajectoryController.
>>
>> -Stu
>>
>> On Fri, Sep 17, 2010 at 3:12 AM, Konrad Banachowicz <konradb3 [..] ...>
>> wrote:
>> > Hi,
>> > I'm working on integration of orocos RT-controller with ROS manipulation
>> > pipeline.
>> > I already done joint_state_publisher and oro_action_server. Next on my
>> > list
>> > are joint_trajectory_action and JointSplineTrajectoryController.
>> > I have some concerns about real-time behaviours of those, and way of
>> > implementation in orocos.
>> >
>> > joint_trajectory_action :
>> > It receive goal containing trajectory (variable size, unbounded size),
>> > then
>> > check constraints and send to JointSplineTrajectoryController.
>> >
>> > JointSplineTrajectoryController:
>> > It loop generating interpolated position for joint regulator.
>> > When it receive new trajectory it reorder joints in received trajectory
>> > (memory allocation, iterating on unknown size array) and try to compose
>> > current trajectory with newly received (memory allocation, iterating on
>> > unknown size array).
>> > It have to by done between two sequential interpolations (in my system
>> > 1ms).
>> >
>> > My solution :
>> > Data transmited between joint_trajectory_action and
>> > JointSplineTrajectoryController contains only single point (constant
>> > size).
>> >
>> > joint_trajectory_action do joint reordering and compose trajectories and
>> > is
>> > feeding JointSplineTrajectoryController with trajectory points.
>> >
>> > JointSplineTrajectoryController interpolate between two points (have one
>> > point buffer)
>> >
>> > This solution should work with trajectories when time between points is
>> > >>
>> > 1ms.
>> >
>> > What do you think about doing this this way ?
>> > What is alternative solutions ?
>> > What do you think about re-usability of this solution in yours systems ?
>> >
>> > Pozdrawiam
>> > Konrad Banachowicz
>> >
>> > _______________________________________________
>> > ros-users mailing list
>> > ros-users [..] ...
>> > https://code.ros.org/mailman/listinfo/ros-users
>> >
>> >
>>
>>
>>
>> --
>> Stuart Glaser
>> sglaser -at- willowgarage -dot- com
>> www.willowgarage.com
>> _______________________________________________
>> ros-users mailing list
>> ros-users [..] ...
>> https://code.ros.org/mailman/listinfo/ros-users
>
>
> _______________________________________________
> ros-users mailing list
> ros-users [..] ...
> https://code.ros.org/mailman/listinfo/ros-users
>
>
[ros-users] Control system design question.
On Fri, 17 Sep 2010, Stuart Glaser wrote:
> Hi,
>
> On Fri, Sep 17, 2010 at 12:53 PM, Konrad Banachowicz <konradb3 [..] ...> wrote:
>> yes RT and non-RT work execute in separated threads but what about shared
>> data ? as far as i know there is some locking involved ?
>
> The buffer used in the JointSplineTrajectoryController is called a
> RealtimeBox.
That's an unfortunate naming...: "realtime" is not an absolute property of
an object, or a buffer, or an algorithm, but of the system configuration in
which it is being used.
> It currently uses a mutex (locked for a guaranteed
> maximum number of instructions on a system that supports priority
> inheritance), though it can certainly switch to a lock-free buffer.
>
>> Communication between RT and non-RT threads is complex problem, but OROCOS
>> solves most problems. it use lock-free buffers for communication between
>> components.
It _can_ use them, but need not. They should be used with care, that is,
only when you are _very_ sure that one component must really be _THE_ hard
realtime component. Because the implementation is trading-off latency for
that single component with overall throughput.
> Currently in ROS joint_trajectory_action is whole non-RT and
>> JointSplineTrajectoryControlle is partialy RT. In my solution all non-RT
>> work are moved into joint_trajectory_action. This make clear border between
>> RT and non-RT part.
>
> Sounds like you've moved the non-realtime parts of the
> JointSplineTrajectoryController into your version of the
> joint_trajectory_action. That sounds like a reasonable solution.
It is reasonable indeed!
Herman
[ros-users] Control system design question.
I have an other concern, what will happen if processing of trajectory take
more time than remaining to first point of new trajectory.
Pozdrawiam
Konrad Banachowicz
2010/9/17 Stuart Glaser <sglaser [..] ...>
> Hi,
>
> On Fri, Sep 17, 2010 at 12:53 PM, Konrad Banachowicz <konradb3 [..] ...>
> wrote:
> > yes RT and non-RT work execute in separated threads but what about shared
> > data ? as far as i know there is some locking involved ?
>
> The buffer used in the JointSplineTrajectoryController is called a
> RealtimeBox. It currently uses a mutex (locked for a guaranteed
> maximum number of instructions on a system that supports priority
> inheritance), though it can certainly switch to a lock-free buffer.
>
> > Communication between RT and non-RT threads is complex problem, but
> OROCOS
> > solves most problems. it use lock-free buffers for communication between
> > components. Currently in ROS joint_trajectory_action is whole non-RT and
> > JointSplineTrajectoryControlle is partialy RT. In my solution all non-RT
> > work are moved into joint_trajectory_action. This make clear border
> between
> > RT and non-RT part.
>
> Sounds like you've moved the non-realtime parts of the
> JointSplineTrajectoryController into your version of the
> joint_trajectory_action. That sounds like a reasonable solution.
>
> -Stu
>
> >
> > Pozdrawiam
> > Konrad Banachowicz
> >
> >
> > 2010/9/17 Stuart Glaser <sglaser [..] ...>
> >>
> >> Hi Konrad,
> >>
> >> There are no issues with breaking realtime constraints because the
> >> unsafe code is called from a non-realtime thread.
> >>
> >> You're correct that the JointSplineTrajectoryController code performs
> >> several operation which are not realtime safe. These operations are
> >> performed not in the realtime loop but rather in the ROS subscriber
> >> callback, which is called from a non-realtime thread.
> >>
> >> Your proposed solution is therefore quite similar to what already
> >> exists: the non-realtime portion of the
> >> JointSplineTrajectoryController reorders the joints and composes
> >> trajectories, and then sends it to the realtime portion which just
> >> performs interpolation.
> >>
> >> There are a few faults with this system, and I'm interested in
> >> discussing solutions which address them:
> >> 1. Trajectories cannot be sent from within realtime--they only come
> >> from outside of realtime.
> >> 2. The current design has a great deal of complexity, particularly in
> >> taking care when transferring the trajectory to realtime, composing
> >> trajectories, and responding with a result to the action.
> >>
> >> There's probably more.
> >>
> >> That said, this interface allows us to comfortably separate the motion
> >> planning pipeline from the realtime loop. Once implemented, you can
> >> run much of the code that was developed to move the PR2 on your own
> >> robot.
> >>
> >> Lastly, you may want to consider examining the
> >> JointTrajectoryActionController which combines the
> >> joint_trajectory_action and the JointSplineTrajectoryController.
> >>
> >> -Stu
> >>
> >> On Fri, Sep 17, 2010 at 3:12 AM, Konrad Banachowicz <konradb3 [..] ...
> >
> >> wrote:
> >> > Hi,
> >> > I'm working on integration of orocos RT-controller with ROS
> manipulation
> >> > pipeline.
> >> > I already done joint_state_publisher and oro_action_server. Next on my
> >> > list
> >> > are joint_trajectory_action and JointSplineTrajectoryController.
> >> > I have some concerns about real-time behaviours of those, and way of
> >> > implementation in orocos.
> >> >
> >> > joint_trajectory_action :
> >> > It receive goal containing trajectory (variable size, unbounded size),
> >> > then
> >> > check constraints and send to JointSplineTrajectoryController.
> >> >
> >> > JointSplineTrajectoryController:
> >> > It loop generating interpolated position for joint regulator.
> >> > When it receive new trajectory it reorder joints in received
> trajectory
> >> > (memory allocation, iterating on unknown size array) and try to
> compose
> >> > current trajectory with newly received (memory allocation, iterating
> on
> >> > unknown size array).
> >> > It have to by done between two sequential interpolations (in my system
> >> > 1ms).
> >> >
> >> > My solution :
> >> > Data transmited between joint_trajectory_action and
> >> > JointSplineTrajectoryController contains only single point (constant
> >> > size).
> >> >
> >> > joint_trajectory_action do joint reordering and compose trajectories
> and
> >> > is
> >> > feeding JointSplineTrajectoryController with trajectory points.
> >> >
> >> > JointSplineTrajectoryController interpolate between two points (have
> one
> >> > point buffer)
> >> >
> >> > This solution should work with trajectories when time between points
> is
> >> > >>
> >> > 1ms.
> >> >
> >> > What do you think about doing this this way ?
> >> > What is alternative solutions ?
> >> > What do you think about re-usability of this solution in yours systems
> ?
> >> >
> >> > Pozdrawiam
> >> > Konrad Banachowicz
> >> >
> >> > _______________________________________________
> >> > ros-users mailing list
> >> > ros-users [..] ...
> >> > https://code.ros.org/mailman/listinfo/ros-users
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Stuart Glaser
> >> sglaser -at- willowgarage -dot- com
> >> www.willowgarage.com
> >> _______________________________________________
> >> ros-users mailing list
> >> ros-users [..] ...
> >> https://code.ros.org/mailman/listinfo/ros-users
> >
> >
> > _______________________________________________
> > ros-users mailing list
> > ros-users [..] ...
> > https://code.ros.org/mailman/listinfo/ros-users
> >
> >
>
>
>
> --
> Stuart Glaser
> sglaser -at- willowgarage -dot- com
> www.willowgarage.com
> _______________________________________________
> ros-users mailing list
> ros-users [..] ...
> https://code.ros.org/mailman/listinfo/ros-users
>
[ros-users] Control system design question.
If the robot reaches the end of the trajectories, it will hold at the
final point. If you want to feed trajectories continuously, then you
must feed them quickly enough or make the pieces long enough so that
the robot never runs out of trajectory.
-Stu
On Fri, Sep 17, 2010 at 2:52 PM, Konrad Banachowicz <konradb3 [..] ...> wrote:
> I have an other concern, what will happen if processing of trajectory take
> more time than remaining to first point of new trajectory.
>
> Pozdrawiam
> Konrad Banachowicz
>
>
> 2010/9/17 Stuart Glaser <sglaser [..] ...>
>>
>> Hi,
>>
>> On Fri, Sep 17, 2010 at 12:53 PM, Konrad Banachowicz <konradb3 [..] ...>
>> wrote:
>> > yes RT and non-RT work execute in separated threads but what about
>> > shared
>> > data ? as far as i know there is some locking involved ?
>>
>> The buffer used in the JointSplineTrajectoryController is called a
>> RealtimeBox. It currently uses a mutex (locked for a guaranteed
>> maximum number of instructions on a system that supports priority
>> inheritance), though it can certainly switch to a lock-free buffer.
>>
>> > Communication between RT and non-RT threads is complex problem, but
>> > OROCOS
>> > solves most problems. it use lock-free buffers for communication between
>> > components. Currently in ROS joint_trajectory_action is whole non-RT and
>> > JointSplineTrajectoryControlle is partialy RT. In my solution all non-RT
>> > work are moved into joint_trajectory_action. This make clear border
>> > between
>> > RT and non-RT part.
>>
>> Sounds like you've moved the non-realtime parts of the
>> JointSplineTrajectoryController into your version of the
>> joint_trajectory_action. That sounds like a reasonable solution.
>>
>> -Stu
>>
>> >
>> > Pozdrawiam
>> > Konrad Banachowicz
>> >
>> >
>> > 2010/9/17 Stuart Glaser <sglaser [..] ...>
>> >>
>> >> Hi Konrad,
>> >>
>> >> There are no issues with breaking realtime constraints because the
>> >> unsafe code is called from a non-realtime thread.
>> >>
>> >> You're correct that the JointSplineTrajectoryController code performs
>> >> several operation which are not realtime safe. These operations are
>> >> performed not in the realtime loop but rather in the ROS subscriber
>> >> callback, which is called from a non-realtime thread.
>> >>
>> >> Your proposed solution is therefore quite similar to what already
>> >> exists: the non-realtime portion of the
>> >> JointSplineTrajectoryController reorders the joints and composes
>> >> trajectories, and then sends it to the realtime portion which just
>> >> performs interpolation.
>> >>
>> >> There are a few faults with this system, and I'm interested in
>> >> discussing solutions which address them:
>> >> 1. Trajectories cannot be sent from within realtime--they only come
>> >> from outside of realtime.
>> >> 2. The current design has a great deal of complexity, particularly in
>> >> taking care when transferring the trajectory to realtime, composing
>> >> trajectories, and responding with a result to the action.
>> >>
>> >> There's probably more.
>> >>
>> >> That said, this interface allows us to comfortably separate the motion
>> >> planning pipeline from the realtime loop. Once implemented, you can
>> >> run much of the code that was developed to move the PR2 on your own
>> >> robot.
>> >>
>> >> Lastly, you may want to consider examining the
>> >> JointTrajectoryActionController which combines the
>> >> joint_trajectory_action and the JointSplineTrajectoryController.
>> >>
>> >> -Stu
>> >>
>> >> On Fri, Sep 17, 2010 at 3:12 AM, Konrad Banachowicz
>> >> <konradb3 [..] ...>
>> >> wrote:
>> >> > Hi,
>> >> > I'm working on integration of orocos RT-controller with ROS
>> >> > manipulation
>> >> > pipeline.
>> >> > I already done joint_state_publisher and oro_action_server. Next on
>> >> > my
>> >> > list
>> >> > are joint_trajectory_action and JointSplineTrajectoryController.
>> >> > I have some concerns about real-time behaviours of those, and way of
>> >> > implementation in orocos.
>> >> >
>> >> > joint_trajectory_action :
>> >> > It receive goal containing trajectory (variable size, unbounded
>> >> > size),
>> >> > then
>> >> > check constraints and send to JointSplineTrajectoryController.
>> >> >
>> >> > JointSplineTrajectoryController:
>> >> > It loop generating interpolated position for joint regulator.
>> >> > When it receive new trajectory it reorder joints in received
>> >> > trajectory
>> >> > (memory allocation, iterating on unknown size array) and try to
>> >> > compose
>> >> > current trajectory with newly received (memory allocation, iterating
>> >> > on
>> >> > unknown size array).
>> >> > It have to by done between two sequential interpolations (in my
>> >> > system
>> >> > 1ms).
>> >> >
>> >> > My solution :
>> >> > Data transmited between joint_trajectory_action and
>> >> > JointSplineTrajectoryController contains only single point (constant
>> >> > size).
>> >> >
>> >> > joint_trajectory_action do joint reordering and compose trajectories
>> >> > and
>> >> > is
>> >> > feeding JointSplineTrajectoryController with trajectory points.
>> >> >
>> >> > JointSplineTrajectoryController interpolate between two points (have
>> >> > one
>> >> > point buffer)
>> >> >
>> >> > This solution should work with trajectories when time between points
>> >> > is
>> >> > >>
>> >> > 1ms.
>> >> >
>> >> > What do you think about doing this this way ?
>> >> > What is alternative solutions ?
>> >> > What do you think about re-usability of this solution in yours
>> >> > systems ?
>> >> >
>> >> > Pozdrawiam
>> >> > Konrad Banachowicz
>> >> >
>> >> > _______________________________________________
>> >> > ros-users mailing list
>> >> > ros-users [..] ...
>> >> > https://code.ros.org/mailman/listinfo/ros-users
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Stuart Glaser
>> >> sglaser -at- willowgarage -dot- com
>> >> www.willowgarage.com
>> >> _______________________________________________
>> >> ros-users mailing list
>> >> ros-users [..] ...
>> >> https://code.ros.org/mailman/listinfo/ros-users
>> >
>> >
>> > _______________________________________________
>> > ros-users mailing list
>> > ros-users [..] ...
>> > https://code.ros.org/mailman/listinfo/ros-users
>> >
>> >
>>
>>
>>
>> --
>> Stuart Glaser
>> sglaser -at- willowgarage -dot- com
>> www.willowgarage.com
>> _______________________________________________
>> ros-users mailing list
>> ros-users [..] ...
>> https://code.ros.org/mailman/listinfo/ros-users
>
>
> _______________________________________________
> ros-users mailing list
> ros-users [..] ...
> https://code.ros.org/mailman/listinfo/ros-users
>
>
[ros-users] Control system design question.
I think about an other situation. When new trajectory is received starting
point of trajectory is calculated basing on current time. What happen when
while processing new trajectory old trajectory pass the firs point(of time)
of new trajectory ?
Pozdrawiam
Konrad Banachowicz
2010/9/18 Stuart Glaser <sglaser [..] ...>
> If the robot reaches the end of the trajectories, it will hold at the
> final point. If you want to feed trajectories continuously, then you
> must feed them quickly enough or make the pieces long enough so that
> the robot never runs out of trajectory.
>
> -Stu
>
> On Fri, Sep 17, 2010 at 2:52 PM, Konrad Banachowicz <konradb3 [..] ...>
> wrote:
> > I have an other concern, what will happen if processing of trajectory
> take
> > more time than remaining to first point of new trajectory.
> >
> > Pozdrawiam
> > Konrad Banachowicz
> >
> >
> > 2010/9/17 Stuart Glaser <sglaser [..] ...>
> >>
> >> Hi,
> >>
> >> On Fri, Sep 17, 2010 at 12:53 PM, Konrad Banachowicz <
> konradb3 [..] ...>
> >> wrote:
> >> > yes RT and non-RT work execute in separated threads but what about
> >> > shared
> >> > data ? as far as i know there is some locking involved ?
> >>
> >> The buffer used in the JointSplineTrajectoryController is called a
> >> RealtimeBox. It currently uses a mutex (locked for a guaranteed
> >> maximum number of instructions on a system that supports priority
> >> inheritance), though it can certainly switch to a lock-free buffer.
> >>
> >> > Communication between RT and non-RT threads is complex problem, but
> >> > OROCOS
> >> > solves most problems. it use lock-free buffers for communication
> between
> >> > components. Currently in ROS joint_trajectory_action is whole non-RT
> and
> >> > JointSplineTrajectoryControlle is partialy RT. In my solution all
> non-RT
> >> > work are moved into joint_trajectory_action. This make clear border
> >> > between
> >> > RT and non-RT part.
> >>
> >> Sounds like you've moved the non-realtime parts of the
> >> JointSplineTrajectoryController into your version of the
> >> joint_trajectory_action. That sounds like a reasonable solution.
> >>
> >> -Stu
> >>
> >> >
> >> > Pozdrawiam
> >> > Konrad Banachowicz
> >> >
> >> >
> >> > 2010/9/17 Stuart Glaser <sglaser [..] ...>
> >> >>
> >> >> Hi Konrad,
> >> >>
> >> >> There are no issues with breaking realtime constraints because the
> >> >> unsafe code is called from a non-realtime thread.
> >> >>
> >> >> You're correct that the JointSplineTrajectoryController code performs
> >> >> several operation which are not realtime safe. These operations are
> >> >> performed not in the realtime loop but rather in the ROS subscriber
> >> >> callback, which is called from a non-realtime thread.
> >> >>
> >> >> Your proposed solution is therefore quite similar to what already
> >> >> exists: the non-realtime portion of the
> >> >> JointSplineTrajectoryController reorders the joints and composes
> >> >> trajectories, and then sends it to the realtime portion which just
> >> >> performs interpolation.
> >> >>
> >> >> There are a few faults with this system, and I'm interested in
> >> >> discussing solutions which address them:
> >> >> 1. Trajectories cannot be sent from within realtime--they only come
> >> >> from outside of realtime.
> >> >> 2. The current design has a great deal of complexity, particularly in
> >> >> taking care when transferring the trajectory to realtime, composing
> >> >> trajectories, and responding with a result to the action.
> >> >>
> >> >> There's probably more.
> >> >>
> >> >> That said, this interface allows us to comfortably separate the
> motion
> >> >> planning pipeline from the realtime loop. Once implemented, you can
> >> >> run much of the code that was developed to move the PR2 on your own
> >> >> robot.
> >> >>
> >> >> Lastly, you may want to consider examining the
> >> >> JointTrajectoryActionController which combines the
> >> >> joint_trajectory_action and the JointSplineTrajectoryController.
> >> >>
> >> >> -Stu
> >> >>
> >> >> On Fri, Sep 17, 2010 at 3:12 AM, Konrad Banachowicz
> >> >> <konradb3 [..] ...>
> >> >> wrote:
> >> >> > Hi,
> >> >> > I'm working on integration of orocos RT-controller with ROS
> >> >> > manipulation
> >> >> > pipeline.
> >> >> > I already done joint_state_publisher and oro_action_server. Next on
> >> >> > my
> >> >> > list
> >> >> > are joint_trajectory_action and JointSplineTrajectoryController.
> >> >> > I have some concerns about real-time behaviours of those, and way
> of
> >> >> > implementation in orocos.
> >> >> >
> >> >> > joint_trajectory_action :
> >> >> > It receive goal containing trajectory (variable size, unbounded
> >> >> > size),
> >> >> > then
> >> >> > check constraints and send to JointSplineTrajectoryController.
> >> >> >
> >> >> > JointSplineTrajectoryController:
> >> >> > It loop generating interpolated position for joint regulator.
> >> >> > When it receive new trajectory it reorder joints in received
> >> >> > trajectory
> >> >> > (memory allocation, iterating on unknown size array) and try to
> >> >> > compose
> >> >> > current trajectory with newly received (memory allocation,
> iterating
> >> >> > on
> >> >> > unknown size array).
> >> >> > It have to by done between two sequential interpolations (in my
> >> >> > system
> >> >> > 1ms).
> >> >> >
> >> >> > My solution :
> >> >> > Data transmited between joint_trajectory_action and
> >> >> > JointSplineTrajectoryController contains only single point
> (constant
> >> >> > size).
> >> >> >
> >> >> > joint_trajectory_action do joint reordering and compose
> trajectories
> >> >> > and
> >> >> > is
> >> >> > feeding JointSplineTrajectoryController with trajectory points.
> >> >> >
> >> >> > JointSplineTrajectoryController interpolate between two points
> (have
> >> >> > one
> >> >> > point buffer)
> >> >> >
> >> >> > This solution should work with trajectories when time between
> points
> >> >> > is
> >> >> > >>
> >> >> > 1ms.
> >> >> >
> >> >> > What do you think about doing this this way ?
> >> >> > What is alternative solutions ?
> >> >> > What do you think about re-usability of this solution in yours
> >> >> > systems ?
> >> >> >
> >> >> > Pozdrawiam
> >> >> > Konrad Banachowicz
> >> >> >
> >> >> > _______________________________________________
> >> >> > ros-users mailing list
> >> >> > ros-users [..] ...
> >> >> > https://code.ros.org/mailman/listinfo/ros-users
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Stuart Glaser
> >> >> sglaser -at- willowgarage -dot- com
> >> >> www.willowgarage.com
> >> >> _______________________________________________
> >> >> ros-users mailing list
> >> >> ros-users [..] ...
> >> >> https://code.ros.org/mailman/listinfo/ros-users
> >> >
> >> >
> >> > _______________________________________________
> >> > ros-users mailing list
> >> > ros-users [..] ...
> >> > https://code.ros.org/mailman/listinfo/ros-users
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Stuart Glaser
> >> sglaser -at- willowgarage -dot- com
> >> www.willowgarage.com
> >> _______________________________________________
> >> ros-users mailing list
> >> ros-users [..] ...
> >> https://code.ros.org/mailman/listinfo/ros-users
> >
> >
> > _______________________________________________
> > ros-users mailing list
> > ros-users [..] ...
> > https://code.ros.org/mailman/listinfo/ros-users
> >
> >
>
>
>
> --
> Stuart Glaser
> sglaser -at- willowgarage -dot- com
> www.willowgarage.com
> _______________________________________________
> ros-users mailing list
> ros-users [..] ...
> https://code.ros.org/mailman/listinfo/ros-users
>