Lag in the shown images at the browser in several exercise templates: write over policy

[jmplaza]

With a slow browser the GUI.ShowImage requests from the Python exercise template (the producer), which are created inside the RADI, are not rendered on time at the web browser (the consumer).

The frames are produced at a fast pace, at the exercise template and the requests are sent one per control iteration. As they are not consumed on time by the browser, they are stored at the websocket buffer. They are rendered with some delay at the browser (the showed images do not match with the current Gazebo world state as seen in the Gazebo viewer subwindow). And eventually the websocket communication gets broken.

The solution is to change the GUI.Showimage implementation to a zero-memory buffer. The writing thread should put the images on that buffer regardless the previous frame got already sent to the browser or not. The sending thread will send a new frame to the browser once the browser confirms with an ACK that the last sent one has already been displayed. The sending thread will read from that buffer the next frame to be sent.

The result is that some frames will never be shown at all in the browser in case of a fast producer and a slow consumer. No problem, this write-over policy seems a good way to face it.

In the case of a fast consumer and a slow producer, the sending thread should only sent a frame if that frame was never sent (it is really new) and after the ACK from browser about the last frame has been received.

[jmplaza]

The same happens at Autoparking exercise when showing the laser readings, even if there is no GUI.showlasers method.

[jmplaza]

• Follow Line
• Autoparking
• Global Navigation
• Localized Vacuum Cleaner