Hanso
-
Posts
411 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Everything posted by Hanso
-
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... -
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
-
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
-
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.
-
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
-
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.
-
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
-
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
-
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
-
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:
-
New photos of the work in progress have been added to the Flickr Page. Enjoy, Hans
-
Thanks. And please don't hold back your thoughts. Always interested in a discussion about other possibilities. Regards, Hans
-
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
-
Ha ha. You can rotate a bit more when you watch my latest video:
-
Thanks MangaNOID. With respect to your question: no, the idea that I have is that the bowl will be filled by hand, but from that point everything goes automatic. After the color has been determined, the candy will be placed in a container and then conveyed to the warehouse where it will be stacked. The warehouse delivers the candy on request to the pickup station, where the train will be loaded. The warehouse + candy sorter will not be part of the layout 2017.
-
More photos of the work-in-progress just uploaded to Flickr (click on photo to go there) and a video to Youtube. Enjoy, Hans
-
The feeder should ensure that 1) there will be never two candies released at the same time and 2) that there will be a (kind of) constant pace in the feed. I have tested different configurations of the bowl. On the video, you can see that most important change is the rotation direction (now anti-clockwise). The last configuration (number 7, also on the picture above) gives the best results until now. Enjoy watching and drop me a note if you like it. Best, Hans
-
For the large candy container warehouse that I am building (click here to read more details), I need three more builds: A candy feeding mechanism. I need a mechanism that feeds one candy at a time to a conveyor belt. Color detection. The color of the candy needs to be determined. Systems that puts the candy into a container. The container can then be conveyed to the warehouse where it can be stored sorted by color. The color as determined in step 2, needs to be passed to the warehouse brick so it can store the container on the right level. Color detection (step 2) I started with step 2. To realize the candy sorter, I needed to know if a Pixycam (see www.charmedlabs.com/default/pixy-lego/) can distinguish the colors of the candy. The colors are not bright (like the Lego bricks), so I wasn't sure if it was possible. I created a quick setup to test the color detection: Next, I placed the four different candies (Fruit-tella) on the conveyor belt and programmed the camera for the four colors. This is the image of the camera, from left to right: (1) raw video, (2) cooked video (= mix of raw video + color detection) and (3) detection only video. Finally, I made a simple test EV3 program. With the addition that the detected block should be more than 20 pixels in width, it detects the candies in the correct color. Candy feeding mechanism Ok, so I have a conveyor belt with a candy on it. But how do I get the candy, one by one, on the conveyor belt. This is where the feeder comes in. I searched the internet for 'real life' solutions. I found out that a rotary feeder or bowl feeder would do best. I tried to make a vibratory bowl feeder (out of 16 circle gear rack elements 24121), but that didn't work. However, rotating the bowl seemed to work so I made a prototype based on rotation and gravity. The bowl is placed at an angle of +/- 20 degrees and then it just rotates in a steady pace. The result was good: it never happened that two candies were fed to the conveyor at the same time. The next step is to make a more solid version and add the color detection unit to it. I'll keep you posted. Enjoy, Hans
-
Thanks, ColletArrow. Have now ordered some bricks, will take some time to get them delivered (Lego shop takes normally 2 - 3 weeks when you order spare elements). Meanwhile, I will be working on motorizing the stuff. Hans
-
Thanks, Aventador2004, for the kind compliment. Two more photo's for your pleasure (click to enlarge): Enjoy, Hans
-
With the bricks I have, I have build a part of the warehouse. One of the things I wanted to know: is the stacker crane high enough to reach all four levels? Well, I found out that the crane was just one brick height too low (or the shelves too high ;-) to make it work. I solved this, by changing the lead screw nut (hope that is the right word). The original designed version was (at least) two bricks in height: When I could reduce the height of this lead screw to one brick, the height of the 32 axle would be exactly enough to get the platform to all four levels. An extra difficulty was too make sure that one gear should be static, the other three should be able to rotate in order to align with the worm gears. And I managed, this is the result: It was rather a puzzle (and I didn't know upfront if there would be a solution). Solving such a puzzle is always very satisfying ;-) Enjoy, Hans
-
Video and photos of the toothed rack rail for the horizontal movement has been uploaded to our Flickr page. And an LDD impression of the warehouse-to-be (the final version will have these shelves on both sides of the rail):
-
For the horizontal movement, I have designed a rail with the toothed bars (3743) sideways. When I use the gears 32198, it exactly fits: Later, I made an updated version that uses two gears 32198. By this means, the gears grab the toothed bars as a claw:
-
Added some pictures to our Flickr page (click on the picture for teletransporting).
-
Thanks GroundskeeperWillie for the nice compliment. Needless to say that I enjoy building this, but these kind of replies are always very stimulating. Meanwhile, I have added two LDD sketches of the platform with the rollers.