Mr Jos

I'm looking for ideas to make 3 buttons for the operation of the warehouse. Here a photo of the current setup of the 3 switches, just color coded with some random bricks. Green = Remove a pallet from the pick&place floor and return it to the high bay crane. Red = Emergency stop, should stop all current movements of all bricks as fast as possible. Blue = Reset emergency stop (or reset after a error has been detected) I need some design on how to make them as a nice 3 button operation panel with these 3 colors for the pushbuttons. I'm good with Technic designs+how it should work, not with aesthetics.

The problem with springs is the limited range they have, the BMW does offer a longer + stronger force already, but still only 3studs length, and this limits the angle. If you want to let it go forward 90° like mine can, then the placement + force from these springs is difficult to use. For my end-effector, I didn't test yet, as I need to have my complete logistics center ready for an event next month, and need to change a few parameters to get it running reliable for 10hours a day. I'm wondering how the XL 6DoF will be performing and how gears/axles will be looking like after a weekend.

I don't know the programming for the Robot Inventor/Spike Prime, but EV3 had a .reset_angle() to reset a motor on a desired place (when calibrating like my 6DoF). All I found when searching "reset" quickly is for the hub gyro sensor in Spike; hub.motion_sensor.reset_yaw_angle() Perhaps give the motor.reset_angle(0) a try. About the rest, looks fun reading it, but I don't understand anything. But must be great to test/work out how it all works for you and others who then can create fun things with these hubs.

There now is a new end-effector for my T-Bot, the gripper is able to take 1,25Long pins up to 3Long pins. The system sorts them by length and color. Thinking about how I can integrate it in my big setup.

Have been rebuilding my other MOC's, Pin sorter and T-Bot. Here I modified my T-Bot with a pin gripper, so it can be used as a pick&place to transport pins rapidly to a destination. I am missing 1x EV3 brick + 2x EV3 battery to make it all work together, but it's getting hard to find these components, hoping to find some more deals to expand this setup more.

I learned a lot by doing this and my other projects. If I look back at my earlyer projects I think often, oh that could have been better/easyer if I knew this already. It's real fun to push the boundaries of what these toy controllers can do. The robot does an automatic calibration everytime the program is started, it uses the sensors to do this on its own, no need to put it manual in the correct position for startup, it will do so by itselve. It will need to do this only once, and then can run for long times aslong as the program is not stopped. It can remain idle/perform tasks for long times as I made all geartrains very sturdy so there is no gearskipping, but when the program stops the motor encoder will just be 0° at next startup, wherever it stopped, as they are incremental encoders, not absolute encoders. Thanks @ all for the feedback, hope I can inspire some people into more technic machinery as they are fun to watch and work on.

First try to make a telescopic fork was at 30/05/2020. First try to make a high bay crane was at 27/6/2020. (+racks + roller conveyor + chain conveyor) End of 2020 I started designing my Robotic 6 axis arm. The programming took forever as I wanted to let it perform linear movements without hard coding every single motor position. I managed to finish this code during 15nights of quarantaine in a hotel in Thailand (when going for 3months there to work) and I took this Lego robot in my travel bag with me. The XL versions of the crane and racks I started at 4/9/2021. The XL robotic arm I started making on 22/01/2022, adapting the programming took just 2hours. All together I think around 15% building/inventing and adapting the bricks to machines. 80% coding and constantly adding more functionality to the HMI, testing. 5% watching it all run, making videos. Hours are countless, I think It took me over 300hours to get the robotic arm to move like it does now. Reading how the real machines work, watching youtube videos that explain kinematics, how to draw a diagram to see and calculate all joints/angles. The complete design of the project was easy, as I install/service these machines (high bay cranes/roller and chain conveyors/robots/elevators/hydraulic presses/sorting machines) in real life as mechanical service technician. So I do know how they look like exactly and how they are driven. But the programming is something I learned myselve from reading a lot and the great website from @Pybricks The first automatic machine I made, is being used as a demonstration model at the moment by the company that makes these kind of machines. I really enjoy making these machines as I try to find and balance on the edge of the possible with Lego. Trying to make everything work on the fastest possible speed/accuracy, and look as much as possible like the real thing. That's why I sell my instructions pretty cheap for all the hours invested in it, just so others can try to make it, and understand what I did. But there will never be instructions for these XL versions as they all need custom made EV3 cables. I only make a Stud.io 3D model (and instructions) for myselve to rebuild them later if wanted.

I have completely finished my logistics center, and have been able to make a video to explain how it all works. A demonstration of my logistic warehouse working. Video starts with a 8x speed "Automatic storage mode". Then the working of all the components is explained. Components; - Dual sided high bay racks. 6 levels high, 5 racks long. - High bay crane with dual side operated telescopic fork. - Input/output chain conveyors. - 2 corner transfer to transfer from chain to roller conveyors. - 3 roller conveyors to connect in- and output. - Scissorlift for lifting pallets up to be taken away/put down. - 6 Degrees of Freedom (6DOF) robotic arm. Linear movements with inverse kinematics control, and full XYZ/Roll/Pitch/Yaw control. - Human-Machine Interface (HMI) to control the complete warehouse, selecting modes, times, add new pallets and write their names down. - Warehouse Management System (WMS), it saves the current location of every pallet whenever it is moved to a new location, online and in an offline file, so it can be loaded at restarts. - Manual operated pneumatic forklift (made from set 42128 Heavy Duty Tow Truck) to destroy the warehouse, as that's what forklifts do. - 5x Lego EV3 Mindstorms bricks to control the 17 motors and 12 sensors. The roller conveyor brick runs as 'main' Master. Left side of 6DoF 'sub' Master. Other 3 bricks act as slaves and do what the masters tell them. Right side 6DoF is connected with both masters. - Programmed with MicroPython (Pybricks). - All 5 bricks are permanently connected to chargers to be able to run at events for long periods. The timestamp what happens at each point in the video is in the spoiler; I'm planning to take this setup to (some) events this year, hoping to inspire some other people to make unusual things with LEGO. Edit: Adding all video's that are posted as comments here to group them together for new readers;

To create stability I had added some ugly bricks on the baseplates, I wanted to eliminate them and have a smaller footprint. I created this block; When it's connected to the baseplate, they get only lifted of the table by a very little bit. And it looks way better, more like a concrete base having some steel beams sticking up. Also been thinking about adding a 7th movement, as there is no space for mechanical axis through the wrist anymore, I came up with this pneumatic hand. I will need some more pneumatic tubes to be able to connect it all the way to the bricks (there I want to place the pump+valve). Will receive 10meter end of next week, I'm using Stihl hose. For now will continue with the programming to use the fork at the warehouse scissor table.

7: 10 5: 6 3: 4 1: 3 6: 2 4: 1

I have been able to finish the mechanical design of the XL version of my 6DoF. 1st test with counterweight being pulled upwards with chains: This had only 2 gears under each turntable of joint #2, and worked from 60° forwards max. I modified the counterweight to go backwards (and up) when the 2nd axle bends forwards. It also is loaded by 2 hard long springs to give extra pressure for going back up together with the 2 bricks weight pulling it up. Even when I disconnect this counterweight the 2nd axle works good. No gear skipping going up from 90° forward! I did add more gears on the turntables (total 4 on each now) as this happened with only 2 each: Now they don't bend anymore. Cabling routed so they allow bending at all joints they pass + going to the bricks that move: Full 90° forwards is no problem for this arm (still need to test max weight in this + less far positions): And the last part, the new homing + small demo moving linear and short roll/pitch/yaw testdemo!: I only had to modify the gearing variables + homing angle values and it works like this already. Need to do some finetuning to get it working even better and then let it work with the automatic warehouse.

Same, the gearing I have makes it no problem for the motor, but the bending of the 4axles with 12T gears makes it skip. I already added a working system that allows it to go backwards 15° and forward around 60° without problems, but going the last part to 85° makes it now unable to go up without gearskipping. I'm even afraid having 4gears around instead of 2 will remain having this problem. Now I do use a counterbalance system using the 2 EV3 bricks as weight to pull it back up, will have to see how I can improve it for more lowering to atleast 80° Not able to post pictures from phone, will do later.

Started with this project again, trying to make it more long range. Reinforced axis 2, axis 4 and axis 5 axles, also slowed them + axis 3 down for more torque. Apart from axis 2 all work fine. I will need to have 8gears holding that joint in place as the weight is to much to handle, and it rips apart when it comes from full down. Would prefer to be able to solve it with some counterbalance system. Will play around with some setups.

I tried many feeding systems, chain belt was the only reliable option. Pins have such a varying length (1,25 to 3 long) that it's not easy to get only 1 pin in front of the sensor. 2 small pins would also fill a 'loader' that uses a pusher, as it needs to be big enough to have a 3 long inside. And wherever many pins are together, all the hooks and edge do catch up in eachother and get stuck literally everywhere. if you stack 2 liftarms on eachother, just have a feel, there will be a small ridge. The 1.25L pins are the easiest to get stuck on places like this, and block a whole mechanism. As they move along with the chain it was the only option to transport them.

Well, the sensor identifies by using RGB values. For each, Red Green and Blue, a value from 0 to 100 is given. The problem is that each pin is a mix of that, like tan has a lot of red, LBG has a lot of blue, DBG is near black (all 0's). And the pins are not big! This is one of the major issues, as the sensor's point of view is larger than a pin, it keeps seeing a part around the scanned pin. Also the chain I only have it in black, and it's always in the viewing range, it is available only in black and reddish brown, and now gold in the BMW bike, so not many choices. The thing is that for our view a tan, LBG and blue pin do look different, but for the RBG they are pretty close, and certainly when taking 100 samples, there will be some pins with anomalies, that will overlap with another color. My large sorter was able to detect these anomalies because the chance that both sensor get an anomaly at the same time was very small. And I could rescan results that overlapped and could be 2 kinds of pins. It also depends how the pin is on the belt, they have holes, short side, long side, round, axle. So it's not an easy result saying tan = 40/10/5 RBG for example. it will be a range.

I tried to make a more budget version, but then hit the wall again, that it's impossible with just 1 color sensor. Tried to get the sensor as close as possible to the pins, and with the dark coloured pins I identify them pretty good on length+color. But Tan pins are so damn hard, really need a dual sensor setup to find the anomalies, the overlap in length for 1,5L and 2L is so big it's impossible to do with this simple setup. I wanted to make just a little belt that could then show on screen or say what pin it scanned, or be used as a counter if you wanted like only 2L blacks and 200 of them, and it reverses all others. Time to put this project aside now, and go back to a new version 6DoF, or something else..

Thanks Ord, I'm curious what you will be able to make with it, if you have any questions feel free to ask me. When I initially made the instructions (it were my first ever) I thought no one would need/want them and maybe have 1 sale in 5 years, but now already need my 2hands and 2 feet to be able to count them and only 8months far. Glad I've been able to help more people to make these great arms, if only I would see some more feedback of them. So far found a video who modded my arm with pneumatics, and one I helped changing the program to work with 1 Robot Inventor set (and succeeded). But they are very fun to play with, and everytime to try get it better working (and offcourse fail many times, and go back and try again).

My model does not use springs as they need very good bracing to much straigth, if they bend a little they will work against you and make it even worse. Also the small travel is limiting, but maybe the new shocks from the BMW motor could be off some help? But I don't have them to test. So I did design my robotic arm to have the correct gearing to be able to operate in all positions without load, this allows for highest speeds possible. The thing then is the load, I see it more as a forklift. Depending how far forward you place the load, and how high you want to go, the max allowed load goes down. So if you reach out to the max point the arm can go, a load WILL prevent an axis to go to full speed, but my program sees this in the next step, and that slowed motor gets the highest power, the rest is slowed down, to keep the fork flat. This way I don't limit myselve to a low load that allows reaching max speed at any time. Or i would need to gear down and reduce the speed. Initially I did try with counterweight (Using 1 or 2 EV3 bricks), but it was not so easy to make this move in the opposite direction as the arm and still have enough room to bend backwards enough. About the motor settings, I do use the control class to change the "limits" parameters. There I changed the acceleration for every movement. I have done a lot of testing, and there is a 'to much'. If the acceleration is set to high it will get bad, it will overshoot the desired angle and run backwards, this makes a very bumpy movement as many endpoints are send. I did find the best acceleration for my robot that makes it not overshoot but still an aggresive acceleration. Offcourse in the ideal world it should always reach it's received speed, this will be possible by lowering the max speed for the motors, and keeping power at 100%. It will then track better (and slower) if instead of 800degrees/second you set 400 as the max speed. Maybe I will start over again and redesign the robot arm, and try to get longer arms. But then I certainly will need a counterbalance system, and/or a damping cylinder or something like in the real ones. Preferably I would make one with Robot Inventor as it's better available now, as I can't get my hands on new/2nd hand EV3's at the moment, but the lack of any sensors would make it hard to have a full 360° axis 1+4+6 like I have now with 2xEV3. (But I don't have any RI/Spike, and to be able to do so, need to sell a few more instructions on Rebrickable ( https://rebrickable.com/users/Mr_Jos/mocs/ ) to explain the cost as I will need extra motors as I have 0 :D

Awesome that it even learned Sit! Roll! Dead! Haha Front legs movement looks good, it lifts the legs, but rear legs seem to drag over the floor, would be cool if all 4 would come off when walking (running). Great job already anyway.

Oh man it's a great discovery that I found out you are planning 1 set per month, but the bigger ones like this will be a challenger to make that big enterprise work. About the tracks you use going in/out, when you pushed on them it seemed like there was no guiding underneath them? Could maybe putting tiles/liftarms depending on the gear you use help? I did put them everywhere as much as I could under my chains/small tracks to prevent them tearing apart. But it might be a great endeavour to put guiding under all, maybe try with the module giving the most problems. Getting hungry from writing, gonna eat an orion cookie.

It's never to old to talk about Mindstorms here. And certainly this robot not, as I'm still using it in my current projects, and changing the code little by little to get it better. I'm not using standard PID regulation for the motor controls, because the problem is resistance. If the bot bends forward, it will 'fall' and have no problem to maintain the wanted speed, but when coming back upwards it needs to put down a lot of power, and depending on the load it will not reach the desired speed. Because there are 6 motors, it's near impossible to program a map, and know the load on each axis at any given position. So best way (for me) is to get the current motor angles, and compare them with what they should have been/what the next set will be. The speeds are calculated by the degrees each motor needs to turn to reach the next sub-point. I don't actually calculate the forward kinematics anymore during steps, I just use the encoder feedback. Example (simplified; motor angles used real, not taking gearing in account): All motors start at 0° (M1-M6 = 0°), with forward kinematics the XYZ position is calculated lets say X=100mm, Y=0mm, Z=100mm. We now want to tip down to X=100, Y=0, Z=20 My program measures the longest moving distance (Z100->Z20 = 80mm) it divides it by steps of 3-6mm depending on my max speed settings, let's say 5mm here. So it will make 80/5 = 16sub steps. Motor 1 will not run, as there is no Y movement, Motor 2 and 3 will both run to lower 5mm and keep at distance X=100. M4 will need to make a sharp 90° turn directly at the start to be able to keep the fork flat with Motor 5 whilst keeping Y=0. Motor 6 has to counter react to sharp M4 and counter turn 90°. M2 and M3 will have to change maybe 2° each. M4 and M6 90° each. The program calculates the speeds for each motor by the maximum allowed speed for the fastest motor, so M4+M6 will both run at 100% speed. M2+M3 at 100%/90°*2° = 2,2% speed. The program calculates by the amount of degrees M4 (largest change) needs to turn, how long it will take him. Lets say 400ms for this big movement. All motors get their speed+position send at the same time and start running to it, the next step (2) starts to be calculated and takes 50-80ms, so the program waits with sending these next commands. Just before the motors will arrive at their position the next set of motor speeds+positions is send, so they don't stop. If all is perfect M1 + M4 + M6 will now not have to turn anymore at all for the next 15steps, so their speed is set to 0 (actually I do send a minimal speed) and send to the same position every next step. But now we encounter real life; If M4 had some resistance in the bearing, it did not reach max speed, so didn't turn near the 90° it should have but only 80°. If I would not measure the real motor angles I would send the speed to 0, and it would stall at 80° (turning slowly to 90°, but the fork would not be flat). So I see that M4 is behind, and react by giving it again max speed as it will still be the largest movement to perform in step 2. The problem is, this can happen with all 6 joints that a load or internal resistance holds it from reaching the desired speed. So that's why I made my program to react to it by calculating the distance to turn by feedback motor angles. This line is for the people who did read this all, and want to know how to make their robot faster (I did find something some time ago), I doubled the amount of steps I can do per second by separating the motor commands from the calculating. I had it in a loop; Calculate, send motor commands, calculate, send motor commands, .... I found out that sending motor commands took half of the time in this loop, so I put the motor commands in a multithread and send them at the same time as calculating next points, making the movement smoother.

Finally finished the instructions for this model, had a lot of work adding the explanation for everything in the program and I added a easy to use calibration function to find the background RGB colors for both sensors when no pin is on the belt. Pin sorter instructions on Rebrickable A new video has been added alongside to show the new functions. Few pages from the instruction and included program; Guess it will be a breakdown now, maybe I will have to design my XL highbay warehouse in Stud.IO now aswell.. I didn't plan to as I would go to events with it, but corona decided they are cancelled.. So might break down all and start to design new models. The warehouse will just be for myselve to rebuild when events are allowed again, planning to bring both of these machines then, just need an extra EV3 battery.

Looks interesting, way past my knowledge. But if it can help to be able to make more complex builds I'm all for it. Good luck and have fun with it!

Great find. About more sets changed, there are some sets with alternative parts lists, mostly color changes or something.

And the complete 3D is finished. I've learned a few techniques to be able to model it faster, certainly with all the angles in this build. 2093parts total including the 829 chain pieces (39%) Without starting to make the instructions (just the steps I designed it in), it's at 365 steps/pages, but I will heavily reduce that now. Edit: After day one, at instruction page 93 now, total pages reduced to 251 and 339 steps leftover (callouts reduce them). A few more evenings needed to finish the PDF. /End Edit A few upgrades have been made in the model that gave little problems in the original that is on the video, like the catching walls on the swingarm, with this design they don't keep hanging anymore once in a while.