-
Notifications
You must be signed in to change notification settings - Fork 35
Pause Functionality #28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @mrceki,
I'm still in the process of reviewing, but I have a quick question to help me understand it better. Please bear with me.
if (pause_simulation_) { | ||
// when paused, use the wall clock | ||
sim_time_ros = node_->get_clock()->now(); | ||
sim_period = control_period_; | ||
} | ||
else { | ||
// Get the simulation time and period | ||
auto sim_time = mj_data_->time; | ||
int sim_time_sec = static_cast<int>(sim_time); | ||
int sim_time_nanosec = static_cast<int>((sim_time - sim_time_sec)*1000000000); | ||
|
||
sim_time_ros = rclcpp::Time(sim_time_sec, sim_time_nanosec, RCL_ROS_TIME); | ||
sim_period = sim_time_ros - last_update_sim_time_ros_; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need to separate these two cases?
I think it might cause a problem, particularly when we resume the simulation, as time will jump (and also go backward).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I separated the cases to keep controller updates running even when simulation time is frozen. But I'm not completely sure if simulation time really stops when paused. I'll need to double-check that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This version does not lead to time jumping as I observed. But it is also unnecessary to separate it in two cases because it's working unlike what I remember about time freezing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sangteak601 I think I found out why I separated in two cases. If you pause the sim without pausing at startup, that's OK. But If we want to pause simulation in startup, controllers cannot be loaded. What is your suggestion on that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sangteak601 I think I found out why I separated in two cases. If you pause the sim without pausing at startup, that's OK. But If we want to pause simulation in startup, controllers cannot be loaded. What is your suggestion on that?
I have done testing and was able to reproduce the issue of controllers not being loaded. One potential solution is to move controller_manager_->update()
outside the if (sim_period >= control_period_)
condition, similar to how controller_manager_->write()
is currently positioned.
However, I am uncertain whether this change might introduce performance overhead, and I am also unsure why I initially placed controller_manager_->write()
outside the condition.
Hi!
As discussed in issue #25, this pull request adds pause functionality. You can toggle the pause state via the space bar.
Also, you can trigger pause at startup using the
'pause_simulation': True
parameter in the launch file.