Hanso

Eurobricks Citizen
  • Content count

    291
  • Joined

  • Last visited

1 Follower

About Hanso

  • Birthday 09/27/1966

Spam Prevention

  • What is favorite LEGO theme? (we need this info to prevent spam)
    Mindstorms

Contact Methods

  • Website URL
    http://siouxnetontrack.wordpress.com

Profile Information

  • Gender
    Male

Extra

  • Country
    Netherlands

Recent Profile Visitors

1557 profile views
  1. Thanks @iLego. For the ones that are interested in the simple test program: 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
  2. 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: it's a bug, two ports should have been implemented. So there will not be a workaround. 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
  3. @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: Hope this helps. Best regards, Hans
  4. 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. 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.
  5. I don't the exact release date. We are now in the process of creating the building instructions. We are aiming at 'somewhere in December 2018'.
  6. 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.
  7. Have tried some more ... This is the problem code: 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: 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.
  8. 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
  9. 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
  10. This robot was controlled by 4 EV3 bricks in daisy chain modus, so there was no special inter-brick communication. It was programmed with the standard EV3 programming environment, and because of the daisy chain modus, it could be handled as one large brick with 16 motors.
  11. Would love to do that, but I don't have the time. Too many projects in parallel. Really busy at work now, working on the extension set of the soccer robot and of course, finish the warehouse .... maybe another time. In the meantime, you can find some background and code at our blog: siouxnetontrack.wordpress.com. -- Hans
  12. I got a PM from xp10r3r with the questions. It was ok for him to post the questions here as well, to share the answers with the community. The questions I received: My answers: My first warehouse post goes back to 15 July 2017. So somewhere around that date, I started building. I have not been working continuously on the warehouse. I estimate that I have worked on it ~ 100 hours until finishing. Maybe a bit less, maybe a bit more. But this is a good estimate. The only thing I still need to do, is finish programming it. That will be done in the next few weeks, since we are integrating the whole stuff now. We use a decentralized software architecture. Meaning that each seperate system (eg. the crane, the warehouse, the train) should handle intelligent commands. For example, the warehouse crane receives a command from the PC application 'store container to location (1, 3, 4)', then the crane will autonomously execute this command. So it needs to pick up the container, move to the correct position and store it into the correct side of the warehouse. All the seperate systems are programmed in the standard EV3 programming language. The PC application is written in C#. You can read more at our blog siouxnetontrack.wordpress.com. I always use LDD (Lego Digital Designer). It has it flaws, but it is easy to learn and it is good enough for what I need. With respect t the books and sources: I used to be a software engineer in the past. With that background, learning the EV3 programming language is rather easy since you know that you need loops, if-then's, etc. Once I found out that it was possible to connect a NXT brick to a PC, it was even more fun. The combination of PC and EV3 made it possible to build more complex systems, and that resulted later in Sioux.NET on Track: making a large system with a PC and lots of EV3's. Learning from eachother makes the learning curve more steep, so the fact that you're now looking at the Forum is also a good source :-). Hope this helps. Best regards, Hans
  13. A little warming up ... (another Tech United robot, made by my son with some little help).