MINDSTORMS HUB-TO-HUB COMMUNICATION

INTRODUCTION

A while ago I started my Big Robot V2 project. In order for that project to succeed, I need to be able to sort out hub to hub communications. Back in the good old EV3 days, there was something called daisy-chaining allowing four hubs to be connected. Unfortunately this functionality isn't supported by the new Mindstorms hub. In order to do brick to brick communication, we need to rely on broadcasting messages. Thanks to TLG I got another Mindstorms hub in order to experiment and demonstrate hub-to-hub communications.

PICTURES
Pictures can be clicked to view hi-res versions. My Flickr album contains all the photos taken for this review.

DISCLAIMER
The CEE Team of TLG has provided these elements. It's not my goal to promote these elements. It's my goal to give you an honest opinion about them. Therefore, the opinion in this review is my own and is in no way linked to TLG.

PREREQUISITES

What do we need for hub-to-hub communication? Obviously, we need at least two hubs. And we need a programming environment. This is where things already start to get iffy. There are two applications which support the new Mindstorms hub. The Mindstorms app and the Spike Prime app. Before we can start using Communication blocks, we need to add extra blocks to the templates. 

The extra blocks are apparently considered "experimental". We can see the hub-to-hub communications block in the list of extensions.

After adding the communication blocks, we get three extra blocks to handle communications:

• A block for transmitting a signal
• A block for receiving a signal
• A block for the value being received

At this point you would think that you can add these blocks in the Spike environment as well. That would have made way too much sense, so you can't. LEGO Electronics work in mysterious ways. Hub to hub might not be part of the curriculum, but why not add these blocks to Spike anyway. That way enthusiastic students can do more than follow the curriculum. 

SETUP

I have created a setup with two hubs and each hub has two motors connected. When I turn the first motor on one hub the second motor will match it's position. The hub will also broadcast a signal which the second hub is listening too. When the second hub received the signal, both connected motors will match the position of the other motors.

VERSION 1

In order to establish hub-to-hub communication, I will create a sender and a receiver program. Let's start with the sender. This program consists of a simple loop that will run forever. When I turn the right wheel, the left wheel will go the same position. And the program will broadcast a message with the position (rotation) of the wheel. 

The receiver is listening to any messages being broadcast. When it receives a message, it will turn both wheels to the same position.

The video below demonstrates the setup.

https://youtu.be/7G47b9yZir4

The most noticeable thing is that both motors on the second block don't move in parallel. Movement is sequential, so the second motor doesn't start moving until movement of the first one is complete. 

Another observation is that the first motor on the second hub seems to be rotating more or less simultaneously with the motor on the first hub. I expected the motor on the second to start moving after the motor on the first hub had finished. Apparently, the broadcast is done in parallel and it doesn't need to wait for the motor block to finish its movement.

VERSION 2

Let's make some adjustments to the programs. First of all we will do the broadcast before rotating the second motor (even though this doesn't seem to matter). And we will change the receiver that we will move both motors using a single block.

Below is the video demonstrating the second setup.

https://youtu.be/qMBstHNCTDI

If there is a difference between the first and second setup regarding the start of the motors, it's not visible to me. The difference between the parallel and sequential movement is clearly visible in this setup. Both motors on the second will start moving simultaneously. For me, this is very important since I want to do a four wheel setup in my Robot project. In order to test the feasibility of my desired setup, I have created a simple prototype robot, which we will test next.

PROTOTYPE ROBOT

So we have concluded that in order to move motors simultaneously, we need to start them using the same block. This won't pose a problem for me, since I need to run all four wheels simulaneously anyway. With our preliminary testing out of the way, I'd like to see if my setup will work using an actual robot. The picture below shows the simple prototype I have created for this purpose.

It uses two hubs and 8 motors. 4 steering motors connected to one hub and 4 driving motors connected to the other hub. I figured it's best to separate the functions, because I need to use a single block for driving. Being able to let one brick focus on one function allows me to have better control over driving and steering.

At this point I wanted to connect the Spike hubs to the Mindstorms app, but this didn't work because I needed to update the firmware. The Spike and Mindstorms firmware aren't interchangeable. I had some issues connecting the Spike hubs to my laptops. This was caused by the fact that I had installed Pybricks firmware on both of them. If you visit the Pybvricks website you can easily "downgrade" to Spike firmware again and after that, I could install the 51515 firmware.

The video below demonstrates the steering mechanism. This does seem to work properly. At the end of the video you see the limitations of the "nearest path" principle. Some of the wheels turn the other way around. This can easily be solved in the software. For now, test succeeded!

https://youtu.be/NFOfaFmoE58

CONCLUSION

So what did I learn of this demonstration and can the Mindstorms software be used to program my big robot project? Right off the bat, I need to mention that the Mindstorms software is end of life and it won't be supported by TLG in a year or two. The Spike Prime software doesn't support hub-to-hub communication (at the moment), so that is of no use either. This leaves with a bit of a predicament. At this point I am not sure what to do, because it's unclear what the future of Spike and Mindstorms will bring. Obviously, I am disappointed that the Mindstorms software is terminated, but maybe TLG will move the communication blocks to the Spike software and it won't be an issue. But there is very little information available if this might happen.

In order to create more sophisticated robots and have more control over the motors it might be better to switch to Python using Pybricks anyway. So, in the near future I will do some tests with Pybricks with the same setup and choose the desired solution. Being a software engineer myself, it's to be expected that Pybricks will be my favorite, but it doesn't hurt to do a proof of concept. To be continued...

INTERESTING LINKS

When I was looking into my motor sync issues, I found two interesting sources:

Motor sync issues by Antons Mindstorms

Mindstorms Hub to Hub Robot Arm by Creator Academy Australia

 

Thanks you for reading this review. All pictures can be found here.