You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The web app maintains an internal variable that tracks the stretch_driver mode based on the last mode change command the web app sent. This only works if external nodes don't change the mode.
To address this, the web app should instead subscribe to the /mode topic, to ensure it knows the actual mode the driver is on. It should then only change the mode when necessary (e.g., change to nav mode when commanding the base if the mode is anything but navigation, change to nav more when commanding the arm if the mode is anything but position or navigation.) The only possible negative change this could cause is some ROS communication issues (since it is another high-Hz subscriber over rosbirdge/roslibjs), but we can test for that.
Note that #78 has a temp fix for this, which is to change the internal mode variable to unknown every time the web app starts an autonomous action; thus, the webapp re-changes the mode back to navigation the first command it sends after an autonomous action. However, this is not the most sustainable fix, because the web app is still vulnerable to some other code (not an autonomous action is calls) changing the mode.
The text was updated successfully, but these errors were encountered:
The web app maintains an internal variable that tracks the
stretch_driver
mode based on the last mode change command the web app sent. This only works if external nodes don't change the mode.To address this, the web app should instead subscribe to the
/mode
topic, to ensure it knows the actual mode the driver is on. It should then only change the mode when necessary (e.g., change to nav mode when commanding the base if the mode is anything butnavigation
, change to nav more when commanding the arm if the mode is anything butposition
ornavigation
.) The only possible negative change this could cause is some ROS communication issues (since it is another high-Hz subscriber overrosbirdge
/roslibjs
), but we can test for that.Note that #78 has a temp fix for this, which is to change the internal mode variable to
unknown
every time the web app starts an autonomous action; thus, the webapp re-changes the mode back tonavigation
the first command it sends after an autonomous action. However, this is not the most sustainable fix, because the web app is still vulnerable to some other code (not an autonomous action is calls) changing the mode.The text was updated successfully, but these errors were encountered: