search

StarlingUAS / ProjectStarling

BRL Flight Arena Infrastructure 2.0
Other
16 stars 3 forks source link

Replace UI with new UI #82

Closed mhl787156 closed 2 years ago

mhl787156 commented 3 years ago

As mentioned in #73 I have created a new UI here https://github.com/mhl787156/starling_ui_dashly.

It is more extensible than the one provided currently (it's pure JS/CS/HTML) which means using it as a control panel and more extensive user interactions are hard to build in.

The replacement allows that, as well as removes the complexity of the Web bridge component as it is written to use rclpy natively. This will be a decent replacment for now until we get someone with React experience to build us a proper web based interactive UI (Arthur has shown interest in building a very basic web GCS)

mhl787156 commented 2 years ago

After use and development, I do not recommend dashly as a template for responsive web UI development. There is a unfortunate layer of complexity where dash cannot directly query ROS via rclpy. Instead the RCLPY node must poll and store state in its local memory, dash must then poll that local state. For quick applications, and 'input' only interactions this may be okay, but this is not suitable for 2 way interactions.

With #96, developing a full responsive (probaly REACT) based frontend would be ideal. Therefore I propose we move the existing (OLD) UI into an examples folder (along with the example python controller) to serve as an example of hooking up a web based UI.

arthurrichards77 commented 2 years ago

Proposal for the "input" side of the UI. Could we have a virtual gamepad? And could it have the same ROS interface as a real one would have? The joy package defines a ROS API for publishing gamepad info along with button and axis mappings. If we gave this to group project students as part of the stack, it would give them a familiar but flexible input capability to use as they chose. I think it'd also work nicely for a general Starling HMI, with new experiments able to subscribe and interpret buttons to suit their needs, but without writing any javascript. Plus if for any reason we wanted to add a physical gamepad, it'd drop right in.

Additional "nice to have": could we show on the same screen some static help text, set by a /drone/helptext parameter, so the launch file could help the user know the button mappings, and dynamic status text, either scrolling or just a line, set by publishing to a /drone/statustext topic.

Might be some overlap with #100 if we chose to relay a push of the red button to the global /estop topic, and then the physical estop could just be a gamepad plugged into the server with the joy node running. Indeed we could then have lots of them, which makes sense.