Jim

[EV3] Mindstorms Daisy Chaining

Recommended Posts

While I was working on my Robot project, I stumbled accross a problem with daisy chaining the bricks. For those of you who are unfamiliar with daisy chaining; it basically is linking several bricks together, with a maximum of four. In the EV3-G software you can select daisy chain mode, which allows you to control motors linked to another brick.

For my project this boils down to having two bricks, controlling a total of 8 motors, so 4 per bricks. One brick is master and the other is slave. It is important to turn on the slave(s) before the master. So, the last brick in the chain needs to be turned on first. My setup is working, but I have encountered a problem. When I use motor blocks to control the slave motors, the blocks don't end their operation. When I let the four motors on the master run for one second, the blocks end their operation after one second. When I do the same for the slave motors, they run for one second, then they stop, but the blocks keep running. Funny thing is that actually one of the four blocks (in parallel) stops running and the other three don't end properly.

I have Googled the issue and found someone who basically had the same issue. However, I have yet to find a solution. Any help is appreciated.

Share this post


Link to post
Share on other sites

@Hanso any thoughts? You have dealt with Daisy Chaining in EV3-G before :classic:

Share this post


Link to post
Share on other sites

I have asked there, but I didn't get a response :tongue:

I will try again, but I am sure Hanso will shed a light at some point.

Share this post


Link to post
Share on other sites

Jim

Sorry for no better answer, but with two EV3 bricks I have no problem using all 8 motors as I intend to do.
However I came to a lot of problems when using more than two ... for example my large LEGO Mindstorms Milka Chocolate factory (using 6xEV3) I had to split up in 3 x 2xEV3 ... but that worked without any problems!

3x 2xEV3 --> LEGO Mindstorms Milka Chocolate factory --> https://www.youtube.com/watch?v=VoU3Cmg-5eo&t=20s
2xEV3 --> Mr. Mixer Cocktail Robot --> https://www.youtube.com/watch?v=7mpUl5yWWWM&t=5s
 

cheers
Mike

Share this post


Link to post
Share on other sites

I didn't have my bricks at home until today. Will give it a try. First I will need to see if I can reproduce the error.

Keep you posted.

Regards, Hans

Edited by Hanso

Share this post


Link to post
Share on other sites

I have made a simple setup:

  • Two bricks in daisy chain
  • Second brick (slave) with two motors
  • Run the two motors in parallel, both for one rotation
  • One of the threads gets stuck in the motor brick

Have tried to find a workaround, but until now: no solution :-(

Will keep trying to find one, but will need to do that some other time.

Best, Hans

Edited by Hanso

Share this post


Link to post
Share on other sites

Hi Hans,

Thanks for helping me out. Good to read that you were able to reproduce the problemen.

I was wondering; how did you deal with this issue in the program for your own robot?

 

Share this post


Link to post
Share on other sites
19 hours ago, Hanso said:

I have made a simple setup:

  • Two bricks in daisy chain
  • Second brick (slave) with two motors
  • Run the two motors in parallel, both for one rotation
  • One of the threads gets stuck in the motor brick

Have tried to find a workaround, but until now: no solution :-(

This almost sounds like a bug. Isn't there something like "Lego EV3 customer service" to help out in such cases ?

Share this post


Link to post
Share on other sites

@iLego The first level of customer service won't be able to help you, but for technical Mindstorms questions they can connect you with one of their experts. Not sure if they do it in every case - the one time this happened to me the second-level person didn't sound like regular customer support, more like an engineer. 

Share this post


Link to post
Share on other sites

Have tried some more ...

This is the problem code:

43943279260_11d69511f7_z.jpg

It gets stuck in one of the threads, mostly the first thread. Meaning that Motor 2A stops after 1 rotation (which is correct), but the block never finishes (@iLego which is indeed a bug).

@Jim in the large soccer robot, we only used 'motor on' and 'motor off'. That's why it worked (obviously ;-).

So I tried the following workaround:

44847384275_7c707e21ee_c.jpg

One of the disavantages of this workaround, is that the accuracy is far less. The motor stops AFTER one rotation, not AT one rotation. Looking at the motor positions, they typically stop at 1.1 or 1.06 rotation. If you  increase the speed to 75, the overshoot gets more. That's logical, since the motor will be stopped when the sensor reads 'greater equal to 1 rotation' and then you'll notice that it takes some time (i.e. the motor still rotates) before it actually stops.

If you don't need this accuracy of the motor rotation or degrees, then you could use this workaround. But now it comes ... it works most of the times, but not always. Now and then (during testing, I measered an average of 25% of the times) motor A, motor B or motor A+B don't rotate at all. Although the Stop block should wait until it has read 'greater equal to 1 rotation', it finishes and goes to the next block stopping the motor. So this workaround is even worse: nobody wants to rely on a program that sometimes does works, and sometimes doesn't :-(.

I don't know if I found a new bug in the Lego software or that it is the same in a different way. But end of the story is: still no working workaround ....

 

BTW: I also don't believe that Lego Support could help. I have tried that in the past, they send you some links and that's it. Lego is still a brick-selling company, software is not their cup of tea.

 

 

Edited by Hanso

Share this post


Link to post
Share on other sites

Thanks for the elaborate response. I appreciate you taking the time.

I just love these "it works...sometimes" solutions :laugh:

My original plan was to program the robot using RobotC, but that doesn't support Daisy Chaining at all. My backup plan was EV3-G, which results in erratic behavior, and workarounds for workarounds.

I don't need surgical precision, but I do need some control/precision, since I want to create a PI(D) controller for my compass sensor. There are some alternatives:

  • Use leJos, which does support DS if I am not mistaken.
  • Sending BT images. You can connect up to 7 units to a single master unit. This will give me lots of flexibility, but it might be too slow. Do you think sending BT messsages will be fast enough?
  • Using WiFi and connect to a piece of software on a computer. Not sure if this is fast enough and I prefer the robot to be autonomous, so no external computer/software.

 

Share this post


Link to post
Share on other sites

The large soccer robot was programmed completely in EV3-G. As you can see, it works fine with four daisy chained bricks and a total of 11 large motors and 1 medium motor.

The PID-controller was good enough, don't forget that it was written by my son, 17 years old at that time (with a little help from me). I think that the PID-controller could be optimised so that the robot wouldn't drive to the ball in a zigzag line. If you just control your motors with on and off, it should work fine. Always.

 

 

Edited by Hanso

Share this post


Link to post
Share on other sites
On 11/7/2018 at 11:33 PM, Hanso said:

The large soccer robot was programmed completely in EV3-G. As you can see, it works fine with four daisy chained bricks and a total of 11 large motors and 1 medium motor.

The PID-controller was good enough, don't forget that it was written by my son, 17 years old at that time (with a little help from me). I think that the PID-controller could be optimised so that the robot wouldn't drive to the ball in a zigzag line. If you just control your motors with on and off, it should work fine. Always.

That is a great suggestions. I will give it a go shortly.

By the way; I love your pure LEGO solution for the holonomic wheels. Very nice.

Share this post


Link to post
Share on other sites
On 11/9/2018 at 9:14 PM, Jim said:

That is a great suggestions. I will give it a go shortly.

By the way; I love your pure LEGO solution for the holonomic wheels. Very nice.

Thanks Jim.

Share this post


Link to post
Share on other sites

Currently, I am working on a daisy chain program where I input the power, instead of a fixed number of rotations. Since four motors are powered by a single brick, I am working on a block so I can use multiple blocks. Each block has an input for Power and the Layer (which daisy chain brick, 1 or 2). However, when I switch to port for the layer, two ports become visible. One for the Layer and one for the Port. Yet, there is only one input, for the Port. How can I input the layer with a variable? (see the upper right green block)

32068513658_9d096dc982_b.jpg

Share this post


Link to post
Share on other sites

I have never seen this.

In variable block, you can select "tab of numbers". Unfortunately, port is not a number but a letter.

Try [1;1] for Layer 1 and port A.

Share this post


Link to post
Share on other sites

This is strange, haven't seen this either. At first, I didn't understand the problem. But indeed, if you edit the motor block, you can change two inputs: the layer (1 .. 4) and the motor (A .. D). If you change either the layer or the motor to be an input connection, you get only one input channel. See the picture below.

32115939608_0e95fb2bf0_c.jpg

I don't have two bricks at home, so cannot test and help. But my suggestion would be to try different numbers and hope that the input is the combination of the two. For example, input 5 = layer 2, motor A so you can make a formula.

 

Edited by Hanso

Share this post


Link to post
Share on other sites

@JimI have found the solution. I have tested it with three bricks in daisy chain.

If you feed the following number to the port, it will result in:

101: Layer 1, motor A
102: Layer 1, motor B
103: Layer 1, motor C
104: Layer 1, motor D

201: Layer 2, motor A
202: Layer 2, motor B
203: Layer 2, motor C
204: Layer 2, motor D

301: Layer 3, motor A
302: Layer 3, motor B
303: Layer 3, motor C
304: Layer 3, motor D

I don't have a fourth brick, but is logical to assume that:

401: Layer 4, motor A
402: Layer 4, motor B
403: Layer 4, motor C
404: Layer 4, motor D

 

So you can use the block you created in the following manner:

31148040437_a92652bfc4_c.jpg

 

Hope this helps.

Best regards, Hans

Edited by Hanso

Share this post


Link to post
Share on other sites

You are a genius! What made you think of this solution?

Share this post


Link to post
Share on other sites
5 hours ago, Jim said:

You are a genius! What made you think of this solution?

Thanks, but that's too much honour for me.

I used to be a programmer (and still do as a hobby). And so I thought, if I would be the programmer of the motor block, how would I solve this problem?

I saw two possibilities:

  1. it's a bug, two ports should have been implemented. So there will not be a workaround.
  2. it's not a bug, then the two parts needed to be combined to one. Then I need to find the number that combines the two.

 

There was only one way to find out: try! I made a loop and waited until the motors connected to the second brick started running. Same for the third brick. And since the numbers differ 100 per layer, I predict (not tested!!) that brick four will be 401, 402, 403 and 404.

Regards, Hans

Share this post


Link to post
Share on other sites
15 hours ago, Hanso said:

@JimI have found the solution. I have tested it with three bricks in daisy chain.

This is indeed amazing.

Your problem solving skills are inspirational :thumbup:

Share this post


Link to post
Share on other sites
2 hours ago, iLego said:

This is indeed amazing.

Your problem solving skills are inspirational 

Thanks @iLego.

For the ones that are interested in the simple test program:

32226768118_398507ec91_o.png

The constant number in the beginning, I used to jump to a higher number once I found a series of numbers that activated the motors on brick 2. So I started testing with the const set to zero. As expected, feeding 1 .. 4 to the MotorSpeed block resulted in the motors on the first brick to run. What I didn't expected in the first place, was that the same motors were activated at numbers 101 .. 104. Then I had to wait some time (almost given up hope), and suddenly the motors on brick 2 came alive. Eureka!

I looked at the current number, it was somewhere around 210 at that time (don't forget that the program was still running). I stopped the program, set the const to 200 and started the program again. Then it was a matter of trial and error to find the exact numbers for brick 2 and 3.

I lost some time due to another daisy chain problem: if you have more than two bricks chained, the sensors/motors of brick 3 are not always recognized. So, you can't access them at all. The best workaround is switching the master brick off and on again. Then, in most cases, the master 'sees' the sensors/motors of brick 3. Sometimes, it also helps to remove a sensor or motor cable from the third brick, and insert the cable again. As you can see, some words are underlined. It has everything to do that I didn't found a workaround that ensures that the motors and sensors of the third brick are recognized. I assume that I would have the same problem with a fourth brick, but I cannot test that. What I do know, is that this problem doesn't occur on the second brick. So it probably is a bug in the slave part of the firmware.

In our large train layout, we therefore use the daisy chain modus only with two connected bricks. That's a workaround (ahum) that always does the job.

-- Hans

Edited by Hanso

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.