search

KTH-SML / svea

Starter ROS workspace for working with the [s]mall [ve]hicles for [a]utonomy platform
MIT License
10 stars 21 forks source link

Potential race condition when SVEAManager gets state from LocalizationInterface #32

Open rcywongaa opened 10 months ago

rcywongaa commented 10 months ago

In https://github.com/KTH-SML/svea/blob/main/src/svea_core/src/svea/svea_managers/svea_archetypes.py#L68

SVEAManager directly gets the current state from the LocalizationInterface.

However, as per https://github.com/KTH-SML/svea/blob/main/src/svea_core/src/svea/interfaces/localization.py#L90 state is updated in a separate thread.

This could lead to a race condition

kaarmu commented 10 months ago

You are correct and this is something we are aware of. However, I'm surprised if you actually encountered a problem. Usually, the manager's state is only used for reading, meaning that race conditions would only cause partial updates to the state. Generally this hasn't been a big problem. Perhaps you encountered something in simulation? I know that there can arise funny effects (that are hard to debug!) between the simulator and localization interface.

rcywongaa commented 10 months ago

I was implementing a safety controller that limits the controls when a collision is imminent. This collision prediction depends on both the current state and control inputs.

Since I wanted this to work in all cases (not just in teleop), I implemented this in SVEAManager. That's when I encountered the issue where I would detect the state jumping around which I suspect is due to incomplete update of the state by the localization.