Mr Jos

After a few evenings modelling in Stud.Io, and a 50minute render from my old laptop, Now just the swingarm is left to design and then full instructions. 743 small chain links counted in the real complete model, and 86 small thread links. I think it will be over 30% of the piece count.

All my MOC's that are with advanced programs come with code on Rebrickable, if they could be useable for other people to try. - Like my Warehouse is to big, I do have a Studio file from v1 and some instructions (not XL version yet), but they are for my own to rebuild them if I need to later. So I didn't post it. - But my 6DoF arm and V1/2 Pin Sorter instructions are for sale with programs included, where the programming is actually the biggest part. I remade the robotic arm for my warehouse with my instructions and it only took me 1 evening to build it, programming took way over 300hours. - This V3 Pin Sorter I will start to model in Studio soon, and it's much better then the V1/2 as I learned better ways to code MicroPython now from self learning by reading https://www.w3schools.com/python/ (I am a mechanical industrial machine installer, not a programmer, so will it be written the best possible? No, but it works fine). On this sorter the scanning belt can run backwards for rescanning/rejecting instead of using a bin for "unknown", but it comes at a price of more parts used (loads of small chain). Do I charge money? Yes, but it's just a little in my opinion, I already heard of a handfull people who bought my 6DoF instruction that they only did it for the program, so they can adapt it to their own robotic arm. One of them even changed it completely to be used with Robot Inventor instead of 2x EV3. I helped him by Messenger for few hours to explain some of the code he needed to change just to get it working on an other sytem, and in the end he managed to. I have no problem in helping people out, the cost is just to be sure people understand what they get as they are interested in it, and not because it's free and have no idea what they are trying to recreate. The builds I make are always on the edge of what is possible with plastic bricks, I always try to find that edge (and max working speed), and many times I went over it and it seems impossible to do, but those do not get a post here. So yeah, it will be available in a few weeks I think. Maybe I will even make a manual version that has only the scanning belt with 1motor and 2sensors and manual pin feeding, just so more people can try and learn from it so they don't need loads of parts, but the code for scanning will remain the same.

Same thought here, I made many versions trying to get the pins from a large tank/hopper up. First models all had brickbuild/liftarm build steps going up/down, but the edge of the pins get stuck on every 0.01mm sticking out where 2 liftarms/bricks are connected to eachother, putting a big tension in the system, and then shoot all pins flying up in the air. The pro with the chains is that the pins don't get stuck as often anymore. There is 1 place where they sometimes do, and it's the slope 1x2 brick that is sideways at the 4->1 belt. It has a flat part where pins can push on, and when it grips on the small chain firmly it can go flying. But I didn't find a piece without any flat surface (it would be like a knife then). But it doesn't happen often, mostly it's the 1.25L (studded pins). They are the hardest to transport. I just tried one and it does go through the system perfectly, I might add some of them, but I think I can't add the most common (LBG / Red) as they are 3L and both have a normal pin at 3L aswell, allthough the 3L LBG is discontinued I think, I only have 5 of them. The pins with bushes do fit as said above, will try it when I fix my scanning belt. I already made the 3 belts bringing the pins up adjustable in speed. When no pin is detected for 5seconds it speeds up 20% every interval. I could lower this threshold to have more pins on the scanning belt. For this video I reduced the speed of the scanning belt to 400°/second because 3L pins that needed a rescan sometimes would fall of the edge and go in the wrong bin. If I place the sensor back 1stud, or make the conveyor longer by 1 stud I should be able to speed it back up to 800 or even 900°/second as that's the max speed of that motor. The amount of pins rejected on the belt (running backwards), I hope I will be able to reduce that, but the danger is that there will come a overlap in RBG and pins go to wrong bins. A lot of logic indeed. I just start at some point and test it. Sometimes I need to write some code just for calibration, like the background color of the sensors, but it's not needed in normal operation, just start small step by step. I do like to work with blocks and let it perform one task, sometimes I make several 'defenitions' and later on add them to 1 like here; This is a complete operation for the white sensor, and then another block for the black sensor. I do like to add the explanation text to know what happens at each part, or what a variable value means, like here the complete data set for a pin at the end of a pin detection. Thanks!

In addition to my highbay warehouse XL, I now have a new "Technic XL" build "finished" (it never really is finished). Link to the instructions on Rebrickable This time I wanted to create a pin sorter that can sort all kinds of lengths and colors (not shapes!). Objectives: Sorting the different colors; Black, Tan, LBG, DBG, Red, Blue. Sorting the different lengths: 1.25 (Blue/LBG), 1.5(Tan, DBG), 2(Black, Tan, LBG, Blue), 3(Black, Tan, DBG, LBG, Red, Blue) Pins should go in bulk in a hopper, and be transported to the scanning belt. Pins should arrive on the scanning belt 1 by 1, if there are to much arriving they should be brought back to the hopper. Having the options to throw back the pins on the scanning belt. If for some reason a pin is not recognized, I do not want it to continue to the sorting arm. If 2 pins do get to close to eachother on the scanning belt it can not be scanned good, as the sensors take it as 1 big pin. If some other kind of brick/thing gets on the belt and can not be sorted. The pins from "5." should go back to the feeding hopper so they can be scanned again later. Each kind of pin needs to be sorted into easy to come by bins (format). If pins come fast after each other and the swingarm needs to go far in between, hold them so they don't go flying midair. If there are many pins in the hopper or nearly empty the feeding system should adjust the speed. Solution: A double RBG (Red-Blue-Green) sensor setup. First one on a white background, second one on black background. This makes it possible to find the color of each pin more accurate. The same sensors measure the length of the pin, all the Data collected is then controlled by a list of possible results. The main problem with pin sorters is that the little tabs on the pins get stuck everywhere, even 0.1mm sticking out stacked-liftarms can launch them in the air. So I decided to go with a belt system to bring all the pins up. The first belt is a large 3wide small chain conveyor angled near 40°, this is to get them high enough already and this type of chain gives a lot of grip on pins. The second belt is a faster 3wide small chain conveyor lying flat to get the pins to the next upgoing belt, sliding plates did not work, pins get stuck on anything and that's not good with the high output of the first belt. The third belt is a double speed 4wide small track + small chain. This is to get all the pins in the correct direction on 1 single belt at the end. If there are to much pins to get on 1 single belt, or stacked on eachother they should return to the same hopper, that's why the small conveyor was needed to turn 180° and end up with the overflow right at the hopper. Pins that can not be scanned good are reversed on the scanning belt back to the first sensor up to 3 times. Meanwhile the feeding system can just continue as it does not get stuck. The scanning belt is open at the rearside, so pins from "5." are thrown back in the hopper. The swingarm has a long length and angled up so any kind of plastic bins can be put under, not just tiny ones. A big bearing makes that fast swing are possible and do not skip gears. The position of the scanned pins are constantly calculated to send the next pin only if it's possible to make the swing to the correct bin. If there is not enough time, the scanning belt will stop and the feeding aswell to prevent buildup before the sensors. in normal operation with still enough pins in the system the feeding conveyors run at nominal speed. If the first sensor does not detect pins for a longer time it speeds up the feeding by 20% every 5 seconds up to 300% speed, after detection it is slowed down again. Now the 1 video tells more then 1000 words; All is run with 4 motors and 3sensors (touch sensor could be left away and use run_until_stalled). So it should be possible with Robot Inventor I think, but I don't have yet such a set. The onscreen view during the program; New video with calibration included

Almost correct! It was the IR. Awesome, hope we can get to Utrecht in 2022, don't know if I should go there with some of my machines, if they are still assembled next year autumn. Do you run your layout with lego rechargeables in the EV3's? I have 5x EV3 with rechargeable running one of my machines, 6th brick now in a 2nd machine is without yet and using one of those 5 during programming now. But as I look to get some more EV3's I can only find retail versions 2nd handed (no battery). So wondered if you use an alternative power source for bricks that are stationary (not running around in a train). I had been thinking about making dummy battery boxes and hooking them up to a constant power source running from the 230V.

Nicely done! I like the compact looking model, hope I will be able to see some of your creations at some event if it's allowed again. Color sensors can be hard to deal with sometimes, I used 4 touch sensors for homing my 6DoF and 1 color, guess which one gives the most problems.

It's the housing with a gear, and in the inside you have put 3 smaller gears. It allows both wheels on 1 axle to turn at different speeds (to make turns, the wheel on the outside should rotate faster). And you say it is revving the motor but not moving. Try to follow from the motor to every next axle/gear what all turns and where the movement stops. You might need to put the car upside down to do this.

Nice idea to make such an arm! Merry X-mas to you too.

Another great looking model! Great to see ineractivity with people going around your MMM's.

Looking good! It does look like walking could be a bit faster when you tilt both feet at the same time. Now the 'standing on leg' tilts after the 'pushing leg' is finished, and to me it looks like they could be done at the same time. (or at shorter interval)

No idea if it can be solved with any of the hints people gave me earlyer this year, when this Intellisense stopped working in my Visual Studio Code (but it was for EV3). Have a read through what people suggested. Visual Studio Code - Suggestions stopped showing - LEGO Mindstorms and Robotics - Eurobricks Forums

Will be great to see your creations combined with mindstorms! You'll learn it step by step and push further everytime what the possibilities are. In my opinion there is so much possible with mindstorms, but it does take time. My builds are mechanically made in lets say 10% of total time, 5% is changing the design whilst programming, rest is thinking and searching how to program not just a 'start-stop' program, but a smart and functioning machine. Have fun with your new set!

Before; After, with your design partially; I had to remove the I-beam connecting both '15100'. This part was gripping in my guiderail, and the basket would get stuck and stop lowering. Before with old design: After with Carsten's 55615 pieces: It's not perfect yet, but already better, thanks for the tip! I always thought these 55615 had less gripping, boy was I wrong. Edit: After testing going up/down slowly I noticed bumping from the 55615 connector in the guiding. This was to a degree that positioning would not go well anymore, so I made a change to the straight connector instead of the L. Tested few minutes going up/down slowly and fast and both running very good. The 3L liftarms are just put on the pins to hide them. And extra note; This morning I've been remaking my forklift alternative from set 42128. Few hours later I have a warehouse rack/pallet destroyer.

Thanks, most of my EV3's are bought 2nd hand at less then half of retail price. The problem is that the whole telescopic fork platform is hanging on 1 liftarm, and it's a heavy platform with a motor, a sensor and many gears/guidings in it. The gears that extend the top platform are under tension so they don't slip, this compensates a little bit. But the top platform also bends because there are only bricks in the length direction, this curves the 8x16 plate. Then finally, there is to much play in the 4 pins that connect the whole platform to the vertical sliding arm. I have already tried to adjust it, but haven't found a way yet to make it like this. Extra progress made; everything has been running in full automatic mode for the first time ever for 10minutes without a crash. Still need a few small bug fixes (and few big ones that are not urgent). Will fix some and remake my forklift MOC from 42128 and then try to shoot a new movie. I'm happy that I'm getting this MOC ready for my first event that I will attend ever (in February).

Cleaned up the cables for all the conveyors, I used some of my spare 2m long ones and had them rolled up, measured the needed length and made new ones. Meanwhile made a video about how to make these cables, and a short video of the warehouse+robot now working together. Taking out works fine already, returning still has some programming issues.

And yet another update, it seems to be not working.. it does connect to both, but when it's running a program it starts working fine, but suddenly it stops receiving bluetooth commands and crashes the robot as only 4 of the 6 motors keep working. It's everytime around 1,5minute it kicks out. Hope I can find a way to fix this, the same program runs for 10minutes without a problem when only connected with 1 master. Only giving the command client.connect('each name of the masters') 2 times makes the program dying after a good minute, without even sending/receiving messages from the new master. EDIT: Got it working again (for now?), when it was going wrong I just put the warehouse master in connecting mode (waiting for 3slaves to connect, but I would only connect with 1), so no messages send. The 6DoF slave would connect to this one, and to the 6DoF master. The program on the 6DoF master would start normally, sending all 6motors commands. After a while the bluetooth commands would stop reaching the slave, so no more motor movement+no control loop feedback back to the 6DoF master = looked like crashing out, but not throwing any error codes. After connecting with all 3 slaves to the warehouse master, and running the master 6DoF would work perfect, and I could send commands with bluetooth for 10minutes without issues. Warehouse Master --> 6DoF Slave: Pickup standard height to dropoff zone 2. 6DoF Slave --> 6DoF Master: It will just see the new command and then sends this forward. 6DoF Master <--> 6DoF Slave: Master starts moving his 4motors and sends constant speeds+position for the 2 motors on the slave, this one returns feedback when in position. 6DoF Master --> 6DoF Slave --> Warehouse Master: When a 'checkpoint' has been reached a command is send through so the warehouse knows that the scissortable is free to start lowering before the 6DoF is completely finished. Also a signal 'ready' is send when the 6DoF can start a new task. I'm happy that it does seem to work, now need to change my HMI to integrate the 6DoF commands in the main warehouse program. Love using Pybricks!

And I can answer my own question, just made a quick test. Slave (5) does send commands to both masters (1) and (4) and they can be read. Now need to program a way to choose if the 6DoF will be used or not with the warehouse, so they both still can be used as individual machines, or linked together.

Very nice and refreshing idea! It would be awesome to see a bunch of these modules with different rides in a row connected.

Can a master EV3 connect with another master EV3? Current setup; Master conveyor brick (1) , slave conveyor brick (2), slave crane brick (3) Master 6DoF brick (4), slave 6DoF brick (5). Both master do all the 'thinking' for their part, and make that each machine can run on its own. But now I'ld like to send a command from (1) to (4) to say that a pallet is ready at the pickup zone. I did only manage to make a workaround for giving feedback from the 6DoF to the warehouse by adding a touch sensor to (1), that the 6DoF will go press when a movement is finished. But it's near impossible to add a sensor to (4) to see when a pallet is ready for pickup. Or can the slave (5) connect at the same time to both masters and keep communicating with both?

Got a new video made showing the working of the warehouse, near the end are a few shots from the EV3 screen showing the Interface to control the automatic modes/timings, see the names etc. Haven't managed to integrate the robotic arm yet, but tomorrow is my last day at work this year so will have more time to finish this project, and I do plan to bring it to event(s) next year.

Nice model, will be good to see a video of it working. For the minifigs you could try to use the 2x1 rubber pieces with crossaxles, like I did to make 'tensioned braces' in my XL fairride. Not on my computer right now so can only link to the page of the photo; https://flic.kr/p/2mh6ehV It allows for opening the braces by hand, and automatically closes again when released.

I had to close my eyes when you were cutting towards your own hands But I do understand why you made it. Like said before the one part cross, one part frictionless can't be used in many cases. Recently I made a scissorlift (long liftarms, so no axle holes). It's very wobbly because of the play in the pins. I have been thinking about changing them to normal friction pins as the power from the linear actuator should be enough to overcome it. After long use it might become the same as your modded pin.

Fun idea. For the loading dock I would add like a soft spring that holds the little ramp up, and being pushed down on the bed when the truck drives against the loading dock (@1:25 in the video). This would eliminate having to push the loading plate down with your hands. When the truck drives away the plate would go up again. It will be nice to see improvements in this topic from your trucks/forklifts.

For those who don't understand what this model is made after; Yesterday finished this real size build. Now got a long weekend to work further on the Lego size warehouse.

Amazing how you managed to fit in so many motors and still looks much the same from the outside, nice modifications. Great to see how it has enough power to lift the D11 and pull forward!