genom3

On Tuesday 19 Sep 2017, at 14:41, Arnaud Degroote wrote:

- add a way to configure and use in some way the simulated time (for
example, use ros::Time for ROS template)

Regarding this and genom3-ros, genom3-ros:6943ade has the
following comment:

`` use posix timer_create()/SIGALRM and a clock thread instead of
ros::timer to pace period tasks. First, ros::timer seems to have a
huge jitter (~1ms after quick tests), and second ros::timer are run
within a ros callback queue, which was making it almost impossible
to both wait for an exec task response and still run the timer
...''

So it looks like using ros::time to schedule tasks was not so good in
the end, and I'm thus a bit reluctant to go back to this.

Yet, I understand the problem of scaling down the time or
synchronizing to some external clock. Do you have a rough architecture
of how it works with ros::time for your use case?

On 20/sept. - 12:25, Anthony Mallet wrote:

Issue #132 has been updated by Anthony Mallet.

On Tuesday 19 Sep 2017, at 14:41, Arnaud Degroote wrote:

- add a way to configure and use in some way the simulated time (for
example, use ros::Time for ROS template)

Regarding this and genom3-ros, genom3-ros:6943ade has the
following comment:

`` use posix timer_create()/SIGALRM and a clock thread instead of
ros::timer to pace period tasks. First, ros::timer seems to have a
huge jitter (~1ms after quick tests), and second ros::timer are run
within a ros callback queue, which was making it almost impossible
to both wait for an exec task response and still run the timer
...''

So it looks like using ros::time to schedule tasks was not so good in
the end, and I'm thus a bit reluctant to go back to this.

Yet, I understand the problem of scaling down the time or
synchronizing to some external clock. Do you have a rough architecture
of how it works with ros::time for your use case?

Well, for now, I just use ros::Time in codels and keep the system clock
in the periodic handler. For practical use, for now, it just run a bit
too fast. But the codels are definitively not anymore
"middleware-independant". And it will just break if I go faster than
real-time.

After, it is definitively not a critical problem for the current
demonstration, but it would be a nice improvement.

----------------------------------------
Feature #132: Time handling in genom
https://git.openrobots.org/issues/132#change-190

• Author: Arnaud Degroote
• Status: New
• Priority: Normal
• Assignee:
• Category:
• Target version:
  ----------------------------------------
  Currently, the Pocolibs and ROS uses internally system time. It is good enough for robotic deployment, but not for prototyping / testing, where one can use simulator and "simulated time".

It would be nice to:
- add a way to configure and use in some way the simulated time (for example, use ros::Time for ROS template)
- expose an API "middleware agnostic" way to retrieve time in genom codels

On Wednesday 20 Sep 2017, at 13:40, Arnaud Degroote wrote:

Well, for now, I just use ros::Time in codels and keep the system clock
in the periodic handler.

Adding something like a function "self->gettimeofday(struct timeval
*)" or a data member "struct timeval self->now;" is definitely OK.

For practical use, for now, it just run a bit
too fast. But the codels are definitively not anymore
"middleware-independant". And it will just break if I go faster than
real-time.

Do you need to just accelerate/slow down the tasks (kind of "open
loop") or to synchronize to an external clock?

If genom3-ros is switched back to using a "ros::timer" instead of a
posix timer to schedule the tasks (and to feed self->gettimeofday() or
whatever), would this be enough?

Then, that could be a runtime option of the component
(e.g. ./component --simulation-time)

On 20/sept. - 14:20, Anthony Mallet wrote:

Issue #132 has been updated by Anthony Mallet.

On Wednesday 20 Sep 2017, at 13:40, Arnaud Degroote wrote:

Well, for now, I just use ros::Time in codels and keep the system clock
in the periodic handler.

Adding something like a function "self->gettimeofday(struct timeval
*)" or a data member "struct timeval self->now;" is definitely OK.

For practical use, for now, it just run a bit
too fast. But the codels are definitively not anymore
"middleware-independant". And it will just break if I go faster than
real-time.

Do you need to just accelerate/slow down the tasks (kind of "open
loop") or to synchronize to an external clock?

The idea is more to synchronise with an external clock

If genom3-ros is switched back to using a "ros::timer" instead of a
posix timer to schedule the tasks (and to feed self->gettimeofday() or
whatever), would this be enough?

It is probably good enough.

Then, that could be a runtime option of the component
(e.g. ./component --simulation-time)

For the record, ros::Time reads the parameter use_sim_time to decide if
it reads system clock or /clock topic.

----------------------------------------
Feature #132: Time handling in genom
https://git.openrobots.org/issues/132#change-193

• Author: Arnaud Degroote
• Status: New
• Priority: Normal
• Assignee:
• Category:
• Target version:
  ----------------------------------------
  Currently, the Pocolibs and ROS uses internally system time. It is good enough for robotic deployment, but not for prototyping / testing, where one can use simulator and "simulated time".

It would be nice to:
- add a way to configure and use in some way the simulated time (for example, use ros::Time for ROS template)
- expose an API "middleware agnostic" way to retrieve time in genom codels