Mr Jos

Another machine in the making, this time a gantry system. Main chassis is a T-bot moving up/down/left/right by combining the movement of 2 motors on the main chassis. The third motor also mounted on the main chassis makes that the moving part is very light weight and can move fast! Instructions available at: https://rebrickable.com/mocs/MOC-80519/Mr_Jos/t-bot-gantry-3-axis-superfast-robot/#details This is the base model, now need to find out what I will make as end-piece and make it actually do something. Making the end piece move with its motor so far away and through many moving parts was not easy, need to improve it by testing some more.

Thanks for helping together to find a better solution! I will have a look at at soon when I clean up my workbench as my next project (that is failing for few weeks already, is taking up my whole table [Technic pin sorter]). I'll implement your new code and see what it does and if it can smooth out the movement some more. It might take some days for me to answer back how it went!

Nice slim design, the panels make it look good (I don't have any panels). Once you get the IK control working you will love the robot, seeing motion where all 6 axis end exactly at the same time, and where the end-effector stays flat is so nice and brings a long smile

Aha ok, got it. I hope it will work well with this solution you found.

The 56T large turntable is also 1/7 reduction with a 8T gear, not 1/3?

I will see what is wrong, they seem to be set public, but I will upload the program to Dropbox. I'll already send you the link, and add it to rebrickable aswell.

After very long programming, thinking and little building the instructions are now available incl program. Please let me know if you try it out and find any problems, it's the first time I upload a MOC. https://rebrickable.com/mocs/MOC-76666/Mr_Jos/6-degrees-of-freedom-6dof-fully-automatic-robotic-arm-with-inverse-kinematics-programmed/#details

I started a new project, but now I don't get any suggestions showed anymore when starting to type anything. When I load a previous project the problem remains, no more list with auto-suggestions to complete the code. I tried to search for a solution but without success. Really hard to code anything now, so hope anyone knows how to turn it back on. (And/or how I did turn it off..)

Nearly there, all files submitted. 3D File, 2D instructions, cabling instructions, MicroPython programs (1x Master with PS4 teaching, 1x Master with only preprogrammed waypoints, 1x Slave only homing and moving it's 2 motors the way masterbrick tells him), Partslist. Anyone wanting so see if they have all the parts needed for this toy;

When I make the instructions the numbers showing the length of axles/beams/etc is showing correct in studio (size 18 for the numbers) When I let it make the PDF the numbers shown are really tiny, unreadable. When I make the size=60 the numbers stay that small, but the 1:1 sign and the circles get really huge.. I can't find a way to make the numbers in the PDF version a good size. Any solutions?

It would be correct if the gearing would be 1:1, then you don't need homing for the motors. But now there is big gearing down meaning that the motor at 0° can be at many possible positions of the arm. So you will still need to do homing. To remove the sensors you could use stalling detection by letting it jam at its end. But 3 of my joints are infinite, so they will never jam.. A robot with finite joints will be possible with one RI I think yes, but I don't own any (yet), only 4x EV3. The IR sensor can be left out, it's only for emergency that I added it. As it might damage the robot if you start the homing when the pitch base joint is completely forward and the top arm touches the floor, it will start to home the top arm by going down even more. With the IR you can then first move up the base arm as far as you want and start the homing by pressing the beacon button. By just deleting this waiting for the beacon you can delete the sensor.

Yeah true, anyway before I did read your comment I already made the instructions for the whole robot excluding the cable routing, that I wanted to add with making some real pictures. Might finish it anyway haha. This is what it's so far. It's nice in subassemblies that get added to the complete arm step-by-step. 75Pages is not to bad I think. And an example page; I never published anything, so will look for some explanation how to upload the 3D files/instructions/programs and make inventory list with bricks used etc (will have to manually add cables as they can not be drawn).

I did just look at your other video's on flickr and saw it could move faster up before without this new code, I think maybe the "acceleration = smooth' might be the problem. Try to set it on most aggresive acceleration for elevate_move. Now it starts with low torque trying to smoothly ramp up, but the low torque is not enough to quickly move the arm up. I set all my accelerations to maximum for highest available torque.

Hey, I know what it is, it's called gravity :D When 'falling' down the motors can move fast and without much torque needed. When moving up it needs a lot of torque to be able to lift up the arm. This will even go slower if you extend the upper arm more outwards, and go faster when the upper arm is moved closer to the center. The motors will try to reach the desired speed, but if the load is to heavy it will not reach that speed. This is the reason you can not make time based movements with these robots, and you can not say lower arm joint has to go same amount of degrees as upper arm joint, and just both send them max speed and expect them to arrive at the same time, as the 'stressed' lower arm will always be later, and the arm will not stay flat. These robots are fun, but they require a lot of programming if you want to do it good, you need to build in some control systems to check angles etc.

Finished it faster then expected. Only 1011 parts (If I didn't forget to draw in any). Now instructions.. what is the best way to make them, with Studio or other application?

One of the things that need to be done is putting 4x pin with bush in a panel, but only 1 deep, then later when the 'marriage' happens from the base and arm, the pins need to be pushed in further. I don't know how to move anything during instructions on more then just the adding of that part page. There are the 4 pins, they lock the lower arm to the turntable base, but can only be pushed in completely when it's sub-assembly is finished, and the beam above it blocks it from being added after the marriage. And the cables are tight, as I wanted to use only standard Lego cables (max 50cm long) they have to be perfectly routed, But they are curved through the frame so many times.. Studio does not allow this I think.

The output is not send with Bluetooth to print it on screen of the laptop, it only prints it when running wired with USB running a debug. When directly run from EV3 and nothing connected with USB it just executes the program. It's already better and looking better, but I still want to try improving the whole program. Soon maybe others might be able to help when I've finished my instructions for the robot arm, and test themself and try to see what I can't figure out that slows the movements a little.

Stud.io progress is going good so far, only making the base rollerbearing was a pain with all the round tiles not possible to connect and each giving an angle + XYZ value to position them in the gear. With some luck 3D file will be finished end of this week, only instructions will take some longer I think, don't know yet how I will draw in the cables yet and put explanation...

In the ideal world it would work without forward kinematics, but not without inversed kinematics at all, I'll try to explain with simple points; I save waypoint 1, Stored data: (X=200, Y=-100, Z=250, Roll=0°, Pitch=0°, Yaw=0°) I save waypoint 2, Stored data: (X=200, Y=100, Z=250, Roll=0°, Pitch=0°, Yaw=0°), this means the arm will move from left side to right side in a straight line, while maintaining altitude and fork levelled. To do this both pitch joints have to make the arm go closer to the center until it reaches Y=0, and then start stretching again. To do this there is a constant change in speed for these 2 joints, reaching 0m/s at Y=0. Problem is that speeds are calculated in ideal circumstances, arm going up or down is the same, but the weight and stress on the joint may make it move slower then wanted, if it lags behind and you reach Y=0 they would completely stall without knowing the real reached position, this gets caught now with the forward kinematics and it will speed up the joint lagging behind as it now has to move a larger distance. Note that in this example both these motors will be at exactly the same angle in start and end position, but they do have to move forward and back to make a nice straight line between these points. Only the end theta1 and theta4 will not be the same end result once all movement is finished. For the inverse kinematics, it is needed to make these nice straight lines, if I just save all motor angles that I reached with the remote it would be an ugly path. When moving down, forward and turning yaw 90° it takes many steps with the PS4 to reach the wanted position. But I save only the start and end position. Inverse Kinematics then "build in realtime" a path that goes down and forward and meanwhile slowly turning 90° yaw. This can be seen in the video going from waypoint #1 to #2. My moves were messy with the controller, but in auto mode it made a smooth descend.

Reason for the jamming of the roll joint has been found. Had 1 of the 2 plugs for charging the EV3's unplugged since yesterday when I started playing with the labelprinter.. Battery was near empty and not able to handle the 'lock' on that joint with low gearing. Now going to put my time in disassembling it and making instructions.

New video made with better explanations. Hope it's better this way, my video-editing skills are close to '0'.

And the answer to that; At least half the cycletime gone for this inverse kinematic calculation. To late now to test with the arm itself, but will do that tomorrow, and try to finetune again. No, I don't hard code the angles my motors need to go to. I just send them the angle they need to try to reach, and then adjust on the fly and send them new angle and speed to reach that angle with all 6 motors at the same time. If I don't calculate with forward kinematics I don't know how far each motor got when I send new coordinates+speed. If 1 motor is 50% far and other 5 at 75%, and I send new coordinates without forward kinematics used, the motor behind would not be speeded up. With these forward kinematics calculation it "sees" that the motor is behind, sends the new coordinates and sets a higher speed then it normally would have. This makes that I can use the PS4 controller as a teaching pendant, and only use it to store a few waypoints. The program then calculates the straight line between those points and adjusts the speed based on live stress at each joint. It would be much easyer to just hard-code a path, but that would be no fun as you can't easily make a new path, and you need to use a computer to change the waypoints. This program I wrote is some next-level thing for LEGO 6DoF with only EV3, and no computer doing the calculations. I send a set of coordinates for each motor with each it's own speed, and send the new coordinates before the old one finished, trying to make it look like a smooth movement. The thing now making it jerky was this long cycletime, but it should be lower now. If all works fine, and I have finished cleaning up more of the code, and find time to make a 3D model with instructions I will publish it.

I'll give that a try, and the project is my 6DoF v2 arm

Moved all the math.radians out to the top and seems I gained a little bit of cycletime, meanwhile cleaned it up to see how the calculation actually looks like.. perhaps there is more time to save by eliminating some of the double cos/sin calculations.. but each one of them is needed for correct XYZ positioning in millimeters...

Hey, I tried to find the bottleneck slowing down my program and it appears to be this Forward Kinematics being calculated every re-routing to a next point between the waypoints. It takes around 45-80ms of the 65-105ms needed to get new speeds for the motors calculated. The sub-routine is completely on screen and is running in a While True: loop with only that routine. If anyone would know how to speed up this proces feel free to let me know.