Hanso

Eurobricks Citizen
  • Content count

    235
  • Joined

  • Last visited

About Hanso

  • Birthday 09/27/66

Contact Methods

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

Profile Information

  • Gender
    Male

Extra

  • Country
    Netherlands

Recent Profile Visitors

1056 profile views
  1. Since 2011, our large fully automated train layout will be displayed at Lego World 2017. In several subtopics, you could have read about the building of the delta crane, the train controlled by a Mindstorms EV3 and much more. A video of our layout in 2016 has been watched almost 30.000 times. For 2017, the train layout consists of 12 Mindstorms EV3 bricks and 1 Mindstorms NXT: 1x Train (EV3) 1x Delta Crane (EV3) 1x Wheel of Fortune (EV3) 1x Ticket Dispenser (EV3) 4x Delivery station (EV3) 1x Ticket reader (EV3) 1x Delta crane (EV3) 2x Container and Candy dispenser (EV3) 1x Air compressor (NXT) All the EV3 bricks are controlled by a Microsoft .NET application, written in C#. We are now in the phase of integrating the Lego builds and fine-tuning the software. Click on the picture below to surf to our Flickr page and you can watch a video on Youtube to see a full test run. The layout will be displayed at Lego World 2017 in Utrecht, the Netherlands from Wednesday 18 - Saturday 21 October 2017. Regards, Hans
  2. Thanks. Yes, and the cable for the color sensor need to go through it. So that means three cables, don't know if that is possible. Maybe I just need three cable carriers...
  3. I've added a cable carrier to make sure that the cable doesn't get stuck when the platform is moving up and down. As you can see on the picture, I use the Mindsensor flexicables and the connectors to extend the length of the cable. I really can recommend these cables, they are much easier to use than the original Mindstorms cables. In the video you can see how the cable carrier works: Enjoy, Hans
  4. Haha, that is a very nice compliment. When I look at my own buildings from the period I started to create my own stuff and compare it with today, I dare to say that my skills increased (and my wallet becomes more empty ;-). But that took time, so don't let it keep you from starting your project and you will see that it is also possible for you. Enjoy, Hans
  5. Aha, I understand now. Smart thinking ;-) Will give it a try in the next weekend, but still, I don't want to 'rely' on this. My direction of thinking is still using a touch sensor with a 'click' per column of shelves.
  6. Hi GroundskeeperWillie, First of all, thank you for thinking with me. But I still don't understand the suggestion. Why would "100 rotations left" result in more accuracy than "110 rotations left followed by 10 rotations right"? Hope you can explain it to me. Best, Hans
  7. I noticed the jerky motion too, but didn't think of a solution yet. I think that it is caused by (the combination of) 1) the weight of the stacker crane and 2) the fact that the motor is on top of the tower and the rotation is needed at the bottom. Or the reason is the cabling hanging around. Well, as you see I don't know yet but it needs to be solved. I don't understand your suggestion for improvement how this would help the gear slack? Yes, I considered that. Even better, that would be the ideal solution since it would be far more accurate (although the worm gears are quite accurate so far, much more than the gear rack). But there is not enough place for a touch sensor without changing the current structure too much. Nice idea, but would that be accurate enough. But if I'm right, the NXT sound sensor responds to decibels, so someone clapping his hands or a dog barking could give false measurements.
  8. New photos have been added to the Sioux.NET on Track Flickr page (click the photo below): On the photo, it seems that both sides of the stacker crane has shelves now. But it's not. The left half has been build just a little (not enough bricks ;-). The horizontal movement has now been added, a video of a test run where a container is delivered to the warehouse and then is stored on an upper shelf, can be viewed on Youtube: What needs to be changed, is how the stacker crane can determine the exact stopping position in front of a shelf (= horizontal movement). In the video, the stopping position was hard coded, i.e. the number of rotations from the end position at the right. But I noticed that the stacker crane stopped not always at the right position. So that's something that needs improvement. Another improvement that needs to be done, is how the cables 'hang around'. So, enough things to do ;-) Please let me know what you think of it. Enjoy, Hans
  9. Hi Aventador2004, Any ideas to share? For myself, I saw two other possibilities (both copied from the GBC's): 1) A mechanism like the axle sorter of Akiyuki (see timestamp starting at 0:20): 2) A mechanism like the rotating filter of BrickIT (see timestamp starting at 1:43): I am really curious about the other possibilities you had in mind. Regards, Hans
  10. Some additional background information about the first test run. Up/down movement The motor on top of the stacker robot is taking care of the up/down movement of the platform with rollers. The height of the 32M axle is exactly enough to reach the four levels of shelves. The bottom and top position are determined by touch sensors, the two positions in between are determined by the number of rotations. I do prefer a solution that uses a (touch) sensor to 'find' the correct position for all levels, but have not find a suitable and workable way to do this. Horizontal movement of the platform The horizontal movement of the platform is controlled by the motor that is connected to one of the up/down sliders, see left photo below. A color sensor is used to 'find' the middle position (the motor next to it is for the rollers of the platform). When the platform moves to an outer position (remember that it can reach to both sides), the end position is determined by the rotation sensor. If the motor power goes to zero, it is interpreted as 'end position' reached and the motor stops. Don't forget to put a small waiting time between 'motor on' and the sensor read; because of the program execution speed, the motor speed is still zero when the sensor value is read which results in the platform not being moved at all and more important, it is then considered that the end position is already reached. There is no way (yet) to determine if the platform is correctly connected to the shelf. Platform rollers The rollers are driven by the motor on top of the platform. It is just switched on/off for a certain time, there is no guarantee that the container was successfully picked up from or delivered to the shelf. I am thinking of adding a (ultrasonic) sensor to determine if the container has successfully left the platform / reached the platform. What holds me back, is the reliability of the ultrasonic sensor in detecting the container. But I guess I''ll just have to try to find out. Another hesitation comes from the number of available ports. I will need (at least) another port for the sensor that will be responsible for the horizontal movement of the stacker robot. If you add the two touch sensors for the top/bottom position of the platform and the color sensor for the horizontal positioning of the platform, all four sensor ports are already taken. If I can find a way to determine the four levels with one sensor, I will have a free position for the container detection sensor. So, although the first test run is already quite nice, there is still some work to do ;-) Ideas are of course always welcome. /Hans
  11. Most of the bricks were finally delivered to finish building of the shelves. I wrote a first test program to test the stacker robot. Although the robot cannot move horizontally, the other movements work as expected. Photos can be found on Flickr (click here or on the picture below). And a video on Youtube:
  12. New photos of the work in progress have been added to the Flickr Page. Enjoy, Hans
  13. Thanks. And please don't hold back your thoughts. Always interested in a discussion about other possibilities. Regards, Hans
  14. The configuration and calibration off the Pixycam camera is one of the most important parts in the reliability of the automatic candy sorter. For example, take a look at the image that the Pixycam reads: The camera should read a red candy (color 2, in my case). Since this is the largest object, it will result in a positive reading. However, if the red candy would not be in place (yet), the camera would probably read the reflection as a blue reading (color 4), i.e. it would result in a false reading of a blue candy. The blue color is the reflection on the roof tile bricks. I found out that the (reddish) brown color gives the least reflection, so I ordered some more reddish brown bricks. Another way to minimize the reflection, is the small roof (in gray, but will also be replaced by reddish brown bricks). On the other hand, it should not be to dark inside, so I've kept some openings to get enough light for the reading. Last but not least: when I get a reading from the Pixycam camera, I multiply the height and the width of the reading. The object should be 'large' enough (I have now set the threshold to a minimum of 1000, that seems to work fine) to distinguish the candy from background noise. As you can see on the picture above, the candy is aligned to the center of the conveyor belt. This makes sure that the camera gets the 'largest' surface to scan (which again is needed to meet the threshold of 1000). The combination of the threshold, the alignment of the candy to the center of the conveyor, the brown roof tile bricks and the roof, result in almost 100% positive readings and 0% false readings. The video below shows the first test run: I have now ordered the missing bricks / correct color bricks. I will do a second test run when they have arrived and keep you posted. Enjoy, Hans
  15. Ha ha. You can rotate a bit more when you watch my latest video: