vasuagrawal / buggygui Goto Github PK

The current plotting library (Plot.ly) uses SVG based rendering to draw the graphs. Unfortunately, that's really slow, i.e. even 1 fps is pushing it. However, the features that plot.ly provides are really nice, such as allowing you to save images from the current plot, zooming, pausing, etc. A suitable alternative needs to be canvas-based and hopefully have many of these features. Once the plotting library is tied in, it can be used for scatter plots, speedos, etc.

Also, make sure the timestamps are displayed as proper times, rather than just in NS.

Encoder messages need to be displayed, probably in one of two ways.

1. Scrolling scatter plot showing velocity / acceleration.
2. Speedometer showing velocity / acceleration.

The steering angle needs to be displayed, possibly in the same format as the encoder messages (plot or speedometer-type thing).

The JS currently loads synchronously. This is fine for testing, but for production the scripts should all load in parallel (probably in head rather than in body). Doing this may break a number of scripts.

It seems like sometimes, if refreshing too often, the MDL CDN stops responding. It may be prudent to point the MDL file to the local version rather than the one on the CDN.

In order to truly support multiple buggys (robots), the different visualizers need to be able to differentiate between the messages coming from different robots. This will probably require rewrites in a number of places along the pipeline, and would probably benefit from a channel based approach.

The ability to rework the dashboard for multiple configurations would be very nice. This can be implemented in a few ways:

1. Client side, allowing the client to move cards around without refreshing the page
2. Client side, letting the client choose from a number of fixed layouts that get redrawn immediately
3. Server side, where different HTML pages are served

Other combinations are possible as well.

Updates to the imu visualizer:

• Moving the camera view with the mouse, rather than having a fixed camera view.
• Switching the IMU visualizer to use quaternions rather than roll / pitch / yaw
• Use a real model for the robot rather than just a box