>
> Now, I'm not using timers in these programs, so I cannot say what
> is the
> influence of the 1ms wait in timer_manager.h. I have not looked at the
> code in details, but it look like this wait could be advantageously
> replaced by the following code:
>
> int remaining_time = std::max((int)((sleep_end.toSec() -
> current.toSec())*1000),0);
> timers_cond_.timed_wait(lock,
> boost::posix_time::milliseconds(std::min(50,remaining_time)));
>
> Is there any reason to verify that the time is not going backward
> at 1kHz?
>
>
>
> This is unfortunately not possible because of the ROS clock used in
> simulation. If simulated time is going faster than normal time you
> end up missing timer events. Building up a predictive model of how
> fast time is actually moving is possible, but not high priority.
>
> Josh
>
Thanks for the feedback.
I somehow feel sorry to loose at least 15% of the CPU time per node on
my embedded system for something that is only an issue for simulation
systems.
What would make the most sense: separating the simulation functionality
from the (pseudo) real-time system, or add a global parameter that
define which type of system we are running? I would think the second
possibility is better and easier to implement.
I for one will definitely apply the above change to all my on-board
system. The gain is too dramatic to ignore.
Now, a bonus question I'm going to investigate now: is there the same
kind of high frequency threads in the rospy implementation?
--
Dr. Cedric Pradalier
http://www.asl.ethz.ch/people/cedricp
(text/plain)