Skip to content
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

Flaky behavior from the Runstop Button in the web interface #33

Open
hello-binit opened this issue Feb 28, 2024 · 5 comments
Open

Flaky behavior from the Runstop Button in the web interface #33

hello-binit opened this issue Feb 28, 2024 · 5 comments
Assignees

Comments

@hello-binit
Copy link
Collaborator

I'm seeing some flaky behavior from the runstop button in the interface. I'm using the latest (beta-teleop branch at the time of this writing). I've captured some GIFs and the steps to reproduce the issues I'm seeing below:

  1. Start the interface with ./launch_interface

  2. Physically hit the runstop button on the robot

  3. The button on the web interface will claim that runstop is disabled:
    before_restart

  4. Echo out /is_runstopped to verify Stretch Driver is reporting runstop is enabled: ros2 topic echo /is_runstopped

  5. Stop the interface with ./stop_interface. Don't take the robot out of runstop.

  6. Restart the interface with ./launch_interface again.

  7. The button on the web interface will correctly claim the runstop is enabled:
    after_restart

  8. Hit the runstop button in the web interface. Runstop will not disable on the robot.

  9. Hit the runstop button again in the web interface. Now runstop will enable. Hit the runstop button again in the web interface. Now runstop will disable. At this point, runstop and the button in the interface work as expected.

Besides the issues explained above, the UX of the buttons should be improved. The runstop button in the interface does a soft strobe to indicate runstop enabled, which is also used on the physical robot's battery indicator LED bar to indicate the robot is charging. This conflict creates confusion. Instead, the runstop button in the interface should have a steady 1hz on/off flash, similar to how the physical runstop button and the battery indicator LED lightbar indicates that runstop is enabled. Additionally, the runstop button in the interface is colored white, which is the same color as the background of the website. This creates confusion. We should use a different color (perhaps grey). Lastly, the battery indicator LED lightbar in the interface does not match the UX of the real battery indicator LED lightbar. The real one also strobes to indicate charging and flashes at 1hz to indicate runstop. Details here. The replicate in the web interface should follow the same UX.

@hello-vinitha
Copy link
Collaborator

@hello-binit there are updates to the run stop in the master branch that address issues with the run stop behavior.

Some users have also commented on the color (as you mentioned) of the run stop. Users suggested making the runstop red when activated. My concern for using red is it not accessible to users with red-green color blindness. I'm considering changing the color scheme for the battery guage (https://visualisingdata.com/2019/08/five-ways-to-design-for-red-green-colour-blindness/).

While there is value to mimicking the exact design of the run stop/battery gauge in the interface I'm not sure it's necessary. Both the run stop and battery gauge flashing is redundant on the interface since they're right next to each other. This makes sense on the robot since both the run stop and battery gauge might not be visible at the same time.

My plan for improving the run stop and battery gauge are as follows:

  • Make run stop red when enabled
  • Make run stop flash at a steady 1hz when enabled
  • Change color scheme of battery gauge to be color-blind friendly. This risk of this is that the colors won't match what's being displayed on the robot.

What are your thoughts?

@hello-binit
Copy link
Collaborator Author

Hi @hello-vinitha, what is the color scale for the battery gauge currently? On the robot, the color scale isn't actually red to green. It's more orange to yellow to green, like this:

image

I agree about not having both the runstop and the gauge flashing for runstop.

One additional change I'd add is having the battery gauge strobe similar to the real gauge to indicate when the robot is charging (reported on the /battery topic).

@hello-vinitha
Copy link
Collaborator

@hello-binit the color scale goes to red but it's unlikely the user will ever see the red because the robot will shut down when the voltage drops to that level. It's more of an issue having a red runstop button next to a green battery gauge.

Instead of the battery gauge strobing, I'm thinking of just having a charging icon appear next to the battery gauge.

@hello-binit
Copy link
Collaborator Author

Ah I understand now. Yes, let's change the color of the gauge to be more easily seen by those with red-green color blindness.

And yes, a charging icon sounds good!

@hello-vinitha
Copy link
Collaborator

@hello-binit the /battery topic doesn't show if the robot is charging. This is what I get when I echo the topic:

header:
  stamp:
    sec: 1709428341
    nanosec: 284042169
  frame_id: ''
voltage: 12.82322883605957
temperature: .nan
current: 5.691280841827393
charge: .nan
capacity: .nan
design_capacity: 18.0
percentage: .nan
power_supply_status: 1
power_supply_health: 0
power_supply_technology: 0
present: true
cell_voltage: []
cell_temperature: []
location: ''
serial_number: ''

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants