you're reading...
Connecting robots, How-to's, leJOS Features

EV3 to EV3: Running text. Sometimes things don’t work!



When I first started planning this series I wanted some easy to describe simple examples of using multiple EV3s together to demonstrate the various leJOS APIs. One of the first examples I came up with was that of a running text display. I wanted to place the EV3s next to each other and have a message scroll over the displays like the signs you often see in shops etc. I decided to actually use a bitmap rather then simple text (as even the largest font we have is not really big enough), so the code is very simple. Once all of the EV3s are connected, just grab a reference to the EV3 screen and then display the bitmap on each screen with a suitable offset. Ignoring all of the setup code (you can see that in the previous articles), this is the main loop:


            for(int i = lcd[0].getWidth()*lcd.length;  i > 0; i--)
                int offset = 0;
                for(GraphicsLCD g : lcd)
                    g.drawImage(img, i - offset, 4, 0);
                    offset += lcd[0].getWidth();

When I first wrote it I considered adding a delay into the loops to slow things down so that it would look better, but for the first run I didn’t bother. When I ran the code I got a bit of a shock. It was very, very slow. See the first part of the following clip:

So what exactly was going wrong? To cut a long story short the first problem I hit was basically down to the round trip time of the Bluetooth PAN. Remember those performance tests. You can see that over Bluetooth the operations that require a send/ack operation are pretty slow. This is because the typical EV3 to EV3 round trip time over a Bluetooth connection is around 50mS. Now the mechanism I used to perform the remote method calls in my first test is basically synchronous (that is each call will have a reply), with a 50mS round trip time this means that the maximum rate I can scroll the display at is 20 pixels per second (assuming one pixel per scroll). In practice the actual speed will be slower still as each iteration requires multiple calls. Hmm this is not looking good. I tried various things, like scrolling the display in small jumps (multiple pixel steps), this helped make things faster but was not as smooth. The video clip uses this technique with a step size of 5 pixels (so the original test was 5 times slower than the first one in the video!). But really nothing helped very much.

My second attempt was to try using asynchronous method calls. With this technique unless the method calls returns a result the sending program does not have to wait it simple sends the data and moves on. As it happens leJOS has a second set of remote APIs that use this technique (Lawrie wanted to talk to the EV3 from Android which does not have RMI support), switching to this is pretty easy (I simply used the RemoteRequestEV3 class instead of the RemoteEV3 class). You can see the results in the second part of the video clip. Much faster but now the displays are not so well synchronized. So why is this? In this case we are now pushing a lot of data over the Bluetooth connection, driving it at the maximum in fact. The problem with this is that any little glitch in the data transmission will accumulate (since there are no pauses for things to get back in sync), Bluetooth is a wireless based system and it uses a very busy part of the radio spectrum, so guess what, there are lots of those little glitches which adds a “jitter” to the way that data is delivered. When the connection to one EV3 has more glitches than another things quickly get out of sync. We could get things back into sync by making a call from time to time that returns a result, but that just gets us back into the slow but in sync case.

So this simple demo is turning out to be rather more tricky than I had first anticipated. But really I shouldn’t have been surprised. Trying to perform tightly synchronized operations over a remote link is tricky. We have a network that delivers a limited bandwidth, with a reasonably large round trip time and some amount of jitter. But these are the sorts of problems that we will have to deal with when using mobile robots. Just look at what the Curiosity team have to cope with, they have a round trip time that is often over 14 minutes! In addition the fixed nature of the API means that we do not have much scope to do things in different ways. For instance in the asynchronous case reducing the amount of data being transmitted over the network would probably have helped. One way to do this would have been to avoid sending the image data again and again with each request. But with the existing API there is no easy way to do that. For the curious, I actually tried this modifying the leJOS code, it certainly helped make things faster but it wasn’t as fast or as smooth as I wanted.

So what to do, I could have just ignored this idea and simply presented the other demos, but I thought that this failure might provide some interesting insight into this sort of thing. It also gave me the opportunity to present an alternative way to make this work, one that actually uses my preferred way of using distributed systems. See the next article for the details.





No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

About leJOS News

leJOS News keeps you up-to-date with leJOS. It features latest news, explains cool features, shows advanced techniques and highlights amazing projects. Be sure to subscribe to leJOS News and never miss an article again. Best of all, subscription is free!
Follow leJOS News on WordPress.com
%d bloggers like this: