-
Notifications
You must be signed in to change notification settings - Fork 18
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
Synchronisation problems between Gazebo and estimation threads #26
Comments
The |
@diegoferigo FYI |
#46 should fix this issue |
@DanielePucci The ImpedanceControl didn't have |
Mmmm it seems weird to me since I'm pretty sure that |
The synchronizer is a different thing as far as I understood. Despite processes are spawned by simulink, which controls gazebo stepping through the syncronizer you mentioned, they run by default using the system clock (i.e. the yarp default clock). In order to sync them with simulink, using |
I think this was solved in #56 . |
PR #56 removed the abstraction layer provided by the Right now the measurements provided by the GetMeasurement block are the raw signals, and it is user's responsibility to filter them properly with the DiscreteFilter introduced in #47. This does not mean that the |
You are right: I did not think that while we removed the estimator threads, there are several threads that are still running and need to be synchronized with the simulated network clock, such as the threads created in the client devices such as the At this point to be honest, I am not sure what this issue is about. The original problem statement was
I think this is the problem related to using any non-synchronized pub/sub or similar framework to communicate with the simulator, that can be solved only running properly synchronized simulations or co-simulations. Is this issue a duplicate of #164 ? : D |
I think this issue can be closed since the solution is to use the |
Description:
The Gazebo simulation and the estimation threads in charge of estimating joint position/velocities/etc are not synchronised even when using the appropriate block, and this introduces an undesired machine-dependence of the controllers performances.
@traversaro @francesco-romano
Further Information:
Darwin Danieles-MacBook-Pro.local 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36 PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64
master
cc53fb3c750899a0dddcae413a9484a6dfee24b4
/Users/DanielePucci/src/yarp
/Users/DanielePucci/src/icub-main
/Users/DanielePucci/src/install/share/yarp:/Users/DanielePucci/src/install/share/iCub:/Users/DanielePucci/src/codyco-superbuild/build/install/share/codyco:/Users/DanielePucci/src/install/share/ICUBcontrib
iCubGenova05
/Users/DanielePucci/src/install/bin/yarpserver
The text was updated successfully, but these errors were encountered: