Hanso
-
Posts
411 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Everything posted by Hanso
-
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'. -
[EV3] Mindstorms Daisy Chaining
Hanso replied to Jim's topic in LEGO Technic, Mindstorms, Model Team and Scale Modeling
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. -
[EV3] Mindstorms Daisy Chaining
Hanso replied to Jim's topic in LEGO Technic, Mindstorms, Model Team and Scale Modeling
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. -
[EV3] Mindstorms Daisy Chaining
Hanso replied to Jim's topic in LEGO Technic, Mindstorms, Model Team and Scale Modeling
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 -
[EV3] Mindstorms Daisy Chaining
Hanso replied to Jim's topic in LEGO Technic, Mindstorms, Model Team and Scale Modeling
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 -
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.
-
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
-
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
-
A little warming up ... (another Tech United robot, made by my son with some little help).
-
If you buy the set, the building instructions will be part of it. The base is similar to the holonomic robot, i.e. it has three omni wheels. The extension set therefore contains also an additional EV3 L motor. The M motor is used for grabbing and shooting the ball. Yes, of course the omni wheels are part of the extension set. And as I said in my original post, I am working on a version with the Pixycam. As far as I know, I don't see any reason why this wouldn't work.
-
The company I work for (Sioux) is one of the main sponsors of Tech United, the leading World Champion in robot soccer. So for me, it was obvious that we are going to release a Lego Mindstorms version of their robot. It will be available on the market as an extension set to the Home Edition version (art. 31313). The expected release date is december 2018 and it will be exclusively available at the Toypro (web)shop. The price of the extension set will be approx. 100 euro. Please note that you need the Home Edition to build this model. The soccer robot looks like this in real: And this is the version I made: This version is controlled by the infrared sensor plus the corresponding remote control. I'm working on a version with the Pixycam, that will be able to go to the ball autonomously. The omni wheels are the only parts that are not Lego. Please let me know what you think of it. Regards, Hans
-
Ah, ok. Indeed, just post the questions at this forum and I will try to answer them.
-
For me, that is perfectly fine (even better). But I understand from xp10r3r that (s)he is not able to post. Although (s)he can use the forum, so don't know what (s)he exactly means.
-
Please move the following topics to Mindstorms: Thanks in advance. Best, Hans
-
Ah, great. Will do. Thanks for the quick reply. Best, Hans
-
Super news that there is now a dedicated Mindstorms forum. Until now, I have posted my articles in the LEGO Technic and Model Team forum. How can I change this to the new forum? Best regards, Hans
-
Hi xp10r3r, Thank you for the compliment. You can ask questions at this board or if you leave your email address, I wil contact you. Kind regards, Hans
-
When the containers-with-candies leave the automatic sorter (see article here), the containers need to be stored at the candy warehouse. In the photo below, you see in the bottom-right the location where the automatic candy sorter will be connected to. From this point, called the supply belt, the warehouse takes over to store the containers. When a candy is requested by the visitor, the warehouse will retrieve a container in the requested color from the storage boxes and deliver it to this location, called the delivery belt. This is the location where the delta crane (see article here) will be connected to and where the warehouse hands over the responsibility. A short video with the working supply belt and delivery belt, can be watched on Youtube: Enjoy, Hans
-
Thanks, jotta93. Always nice to get these compliments.
-
I've been very busy the last weeks and didn't have the time to write you my updates on building the container warehouse. Fortunately I did have the time to work on it. I needed to redesign some parts: The part that takes care of the platform horizontal movement. Instead of a worm gear that slides along the long axle, I use the 11955 gear (Technic gear 8 tooth no friction). The platform rollers. The previous version was not strong enough, and that resulted in a bad connection to the gears of the storage box. And that resulted in the container being not moved correctly to the storage box. The problems seem to be solved, needs some duration testing. In the video below you see one of the first test runs. In the video, you see only half of the complete warehouse. The complete warehouse will consist of two stacker cranes. Both stacker cranes can access the middle storage boxes (at the left in the video) and one of the outside storages. What has been finished building, has been put together and that looks like this: Enjoy, Hans
-
Thanks ColletArrow. My colleague is rebuilding the part to separate the candies from the containers. I have seen the first version, and it is looking great. Sorry, no pictures yet. Thanks bombcar. It wasn't too difficult to find a way to push all the bars simultaneously, but I had to think twice to find a way to push it in a supple cuve. Suddenly, I had this Euroka moment. And then it was build in a couple of hours (first a proto, then the final build).
-
The Delivery Station unloads the train, separates the candies from the containers and delivers the candies to the visitors. The 2017 consisted of four parts: Push mechanism: pushes the containers-with-candies from the train Roller mechanism: rolles the containers-with-candies to the lifts Lift mechanism: lifts the containers to separate the candies from the containers Locker mechanism: candies are stored in lockers, to be opened with the ticket reader The order of the candies needed to be kept, so every visitor received the candy in the color he requested. You can watch the 2017 here (starts at timestamp 2m39s): For 2018, we keep the Push mechanism and the lockers. The part that will take care of separating the candies from the containers, is completely redesigned. The push mechanism however, was rather slow and - as you can see in the video - it needed quite some space due to the slider. So, that needed a redesign as well. You can see the new version here (click on the photo to go to our Flickr page): And of course a video: Enjoy, Hans
-
Uploaded a new video to demonstrate the work in progress. In the video, two containers are stored in the warehouse. Not only to see if it works, but also to measure the time needed. The loading platform is at the right of the warehouse. The first container is stored at the nearest position to the loading platform (= bottom, right). The second container is stored at the most far position from the loading platform (= top, left). Storing the two containers is less than 75 seconds which is perfectly acceptable. Still waiting for more bricks to arrive to continue building ...
-
Improved version of the motorized Wheel of Fortune. In the previous version, the motor power was transferred through the axle of the wheel. The wheel is rather heavy, so the torque on the axle was also rather high. In this version, the motor power is transferred to the wheel using the yellow gear rack elements (6151167). Click on the picture below to view the pictures on Flickr: And of course a video: Enjoy watching, Hans
-
As promised more detail of the improvements. Horizontal movement of the stacker crane In the previous version of the stacker crane, the motor that was responsible for the movement, was build on top of the crane. Resulting in a very long axle going through the left tower to the bottom of the crane. In the current version, the motor is build-in into the left tower. This results in a almost direct coupling to the corresponding gears, and that results in a smooth movement. See the photo below. Horizontal stop locations for the stacker crane The stacker crane needs to stop exactly in front of a container storage. If not, the gears will not connect which results in the container not stored or retrieved correctly. Because of the distance, counting the number of rotations will probably not be accurate enough. In the previous version, the gear racks for the horizontal movement were placed in the middle. In the current version, I moved them to the two sides. I didn't have to move the gears in the stacker crane, so this was a relatively easy change. Having now room 'in the middle', just like the motor that was build-in into the tower, I now build-in a touch sensor into the tower. An axle with a Technic Ball Joint (32474) at the end, makes sure that the axle glides smoothly along the flat tiles. A stop is made by two slopes (85984), the axle with ball joint lowers and the touch sensor goes to 'released' state. Horizontal platform movement In the previous version, the motor responsible for the horizontal movement of the platform, was attached to the slider of the right tower. In principle, this worked fine. However, it has two disavantages: 1) The weight of the sliders and 2) The motor needed a cable carrier. Because the platform also has a motor build-in for the platform rollers and a color sensor for the positioning, the platform would need three cable carriers in total. It might be possible to use one cable carrier for two cables, but definitely not for three. I moved the motor that is responsible for the horizontal movement of the platform, to the top of the stacker crane. A long axle in combination with a worm gear, is used to transfer the rotation to the platform. The worm gear can slide smoothly along the long axle, in the picture below you see how the motor rotation is transferred to the platform, keeping the vertical movement in tact.