Fix Buffering Issue

[gajan]

Add a fixed width buffer on the client and the server side.

Sync the header with the binary blob? (@Sathe: Not sure if we were planing this for this week. Please update)

[dhananjaysathe]

Not too sure will need to work this out with Dominique

[ghost]

Agree. Talk to Dominique and come up with a plan. This is your top priority. Groovy support can wait.

[dhananjaysathe]

Buffer now non polling and queued.
72820b1
empty buffer corner case fix:
53efcb8

Have a look .Any comments suggestions welcome , needs testing , with rosbag or Vlad

[gajan]

Do it with rosbag

G

On Tue, May 14, 2013 at 6:08 PM, Dhananjay Sathe
[email protected]:

Buffer now non polling and queued.
72820b172820b1
empty buffer corner case fix:
53efcb853efcb8

Have a look .Any comments suggestions welcome , needs testing , with
rosbag or Vlad

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-17886425
.

[dhananjaysathe]

Not really. I need robot :-D the wifi and robo are the bottle necks. Rodbag
not really useful

• Sent from my Android Mobile Device. Pardon the brevity.
  On May 14, 2013 6:41 PM, "Gajamohan Mohanarajah" [email protected]
  wrote:

Do it with rosbag

G

On Tue, May 14, 2013 at 6:08 PM, Dhananjay Sathe
[email protected]:

Buffer now non polling and queued.
72820b1<
72820b13665dff204bef4ed7f9112b950d9e3949>

empty buffer corner case fix:
53efcb8<
53efcb8a16e8edb6de3466388f71833b0a45f33f>

Have a look .Any comments suggestions welcome , needs testing , with
rosbag or Vlad

—
Reply to this email directly or view it on GitHub<
https://github.com/IDSCETHZurich/rce/issues/8#issuecomment-17886425>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-17888583
.

[gajan]

Since Vlad is busy having PCL on board this is not an option.

2 options:

1. using --rate option you can playback a rosbag in higher rates
   http://www.ros.org/wiki/rosbag/Commandline#play
2. We have extra boards, wireless dongles, and power supplies for the
   board. Try it with them.

G

On Tue, May 14, 2013 at 6:56 PM, Dhananjay Sathe
[email protected] wrote:

Not really. I need robot :-D the wifi and robo are the bottle necks.
Rodbag
not really useful

• Sent from my Android Mobile Device. Pardon the brevity.
  On May 14, 2013 6:41 PM, "Gajamohan Mohanarajah"
  [email protected]
  wrote:

Do it with rosbag

G

On Tue, May 14, 2013 at 6:08 PM, Dhananjay Sathe
[email protected]:

Buffer now non polling and queued.
72820b1<

72820b13665dff204bef4ed7f9112b950d9e3949>

empty buffer corner case fix:
53efcb8<

53efcb8a16e8edb6de3466388f71833b0a45f33f>

Have a look .Any comments suggestions welcome , needs testing , with
rosbag or Vlad

—
Reply to this email directly or view it on GitHub<
https://github.com/IDSCETHZurich/rce/issues/8#issuecomment-17886425>
.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/8#issuecomment-17888583
.

—
Reply to this email directly or view it on GitHub.

[mayanks43]

I think what we need to test is - bloating up of rce-ros client. I'll test it with rosbag.

[gajan]

Exactly! - G

On Wed, May 15, 2013 at 12:19 PM, Mayank Singh [email protected]:

I think what we need to test is - bloating up of rce-ros client. I'll test
it with rosbag.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-17930590
.

[dhananjaysathe]

Implementation fix 2e1c21a should have always been push producers , this is what we are doing , it is a producer spewing output not generating on request.

[mayanks43]

Depends on your code design. Pullproducer was fitting in the earlier design. Pushproducer suits your current design.

[dhananjaysathe]

Although a Push Provider does seem to fit the case for designing the buffer it does not shut down on its own , the responsibility of shutting of the transport is now with the buffer and we would have to manually shut transports and deal with the ugly behavior.
A pull producer is shut from the transport side implicitly by twisted (it deals with the rest of ugly the closing bits on it's own) the first run Flag ensures the behavior desired and shut , I do not know if it will work the next time, perhaps new connections required in which case it will be recreated. This a reason not to reuse buffers on reconnect , also I don't know how practical that is as the binary data (mostly used in these case is high frequency in the first place to require a buffering implementation ) is probably made redundant in that time taken to reconnect.

[dominiquehunziker]

Hey guys,

I pushed a different buffer implementation. Have a look; branch is 'buffer-alternate'. I was not able to test it yet as I don't have any useful nodes and data to test this at home.

Dominique

[dhananjaysathe]

Looks good, Seems it was a combination of a flag check and the problem with how these things were being called from different thread that did me in. Mayank has the nodes and rosbag to test it with , he will update us in a bit .

A few observations/queries suggestions for how we would implement this.

The idea of buffering was to be implemented for binary data alone . We could pass all messages through the queue and still (as currently done) and still get the desired result (perhaps this could be the reason they didn't work in all cases when i was using two channels ) using priorities.

We happen to queue all messages and prune this queue on a set interval which seems fair.
Now the implementation prunes message regardless of priority, Priority 0 included, is this what we want
Also the current implementation just differentiates on data messages, we intended to buffer only binary messages which can be dropped if required by a node , we may not want to drop or buffer these either , for instance robot parameters and control inputs would be a higher priority and could have a bad result. (we could drop rgb data (binary) but dropping a json data message about an input or pose or sensor could ruin the entire setup)

We could use 0 for rapyuta control messages (as currently done , not prune this ), 1 for json data messages (pruning optional as this depends on the experimental setup , we need to take a call on this ), 2 and higher for other kinds of data messages which are pruned and sent according to the priority )

Edit : if the messages that are not supposed to be prune are still found to be in the queue it probably means somethings is wrong with the connection , it would be better to explicitly inform the user about this or explicitly log this as a connection error and possibly take some steps rather than drop them or standard log them.

Welcome insights. Regards.

[mayanks43]

Hey guys,

I tested both master and buffer-alternate with rosbag. Here's what I did:

1. Ran rosbag throttled 10 times. The fps on robot side was sub-300 approx.
2. Connected the topic /depth/image_raw/compressedDepth to a container.
3. Measured fps that turned out to be sub-40 approx.
4. Checked out memory consumption which turned out to be fixed for both rce-ros and rce-environment.

The situation was the same for both master and buffer-alternate branches.

I can't figure out why rce-ros doesn't bloat up if it can't transmit all sub-300 frames in the master branch which has no buffer implementation.
Also, new buffer-alternate branch doesn't seem to make it receive sub-300 fps.
So, the tests are pretty inconclusive.

This way I don't think it's possible to properly test this with rosbag.

[ghost]

@dhananjaysathe As discussed pls talk to the autobahn folks about the issue and try to get some feedback.

[dhananjaysathe]

Will do