Colinear Tripteron Progress



  • Some of you may remember I reserved a kinematics type number back in August 2019.

    And some of you remember I wanted to take a break from 3d printers.

    Well, I failed either so far. But as of today, I have a prototype machine built that I can implement for. Luckily, someone did it for Smoothieware (the same person whose prototype build I copied, with his blessing and help).

    Here is a first photo:

    IMG_20200524_181505.jpg

    And here is a short video of me abusing delta mode and absolute tower moves to show that it's only mostly dead:

    https://photos.app.goo.gl/c4ptuJajXeWNc8di9

    Still missing are endstops, belt tension, anything on the effector to do useful stuff, a surface to do stuff on ... but for implementing the kinematics this should be sufficient. Let's see if I can get to there in less than nine months (-:



  • Looking very nice, yet complicated 🙂 . As a big fan of the delta style robots, my soft spot is certainly tickled by this one.

    Is there any specific advantage over a delta? It seems like more efficient use of Z-height could be a candidate.



  • Less z height overhead, and linear resolution about the whole print area. Arguably fewer parts (depending on design of course). But you pay for that with the elbows sticking out of the frame "like a rude dinner guest" as someone said about this.



  • Hi,

    As long as it makes you happy that is all that really matters.

    Do you believe it is a truly practical design?

    Frederick



  • I like weird machines, so I am biased (some may remember that I built a SCARA once just so).

    I like that due to the limited overhead in Z it fits under my desk with room to spare at 80% the same attainable z height as my long-retired delta which needed almost a meter high uprights (I.e., triple the height).

    I don't think it's super efficient in terms of space and recent CoreXY designs (like Voron0) beat it in that regard. The design is patent encumbered until 2022 I believe so you won't see it much outside non-commercial / research projects like mine.

    That said, if we all would just build practical / sensible machines we would never enjoy things like deckingman's CoreXYUVAB -- not that I claim the same ingenuity or mechanical engineering skill. But that machine spurred the development of the mixing hotend; who knows what this or any other "objectively less practical than existing designs" will give rise to?



  • Teaser:

    Finished building target: Duet2CombinedFirmware.elf
     
    make --no-print-directory post-build
    Generating binary file
    arm-none-eabi-objcopy -O binary "C:\Eclipse\Firmware\RepRapFirmware\Duet2_RTOS/Duet2CombinedFirmware.elf" "C:\Eclipse\Firmware\RepRapFirmware\Duet2_RTOS/Duet2CombinedFirmware.bin" && crc32appender "C:\Eclipse\Firmware\RepRapFirmware\Duet2_RTOS/Duet2CombinedFirmware.bin"
     
    
    22:42:50 Build Finished. 0 errors, 0 warnings. (took 56s.852ms)
    

    Well, that might at least not fry the board when I upload it (based on the 3.1.1 tag because the 3.02-dev branch doesn't build for me currently)


  • administrators

    @oliof said in Colinear Tripteron Progress:

    the 3.02-dev branch doesn't build for me currently

    Have you updated the RRFLibraries project?



  • I did update RRFLibraries. I likely made a mistake. I will try again tomorrow.

    Update: As it is past midnight, I just tried again and now I was able to build successfully against v3.02-dev plus my pretty self-contained patches (only kinematics additions). I will sacrifice test on my prototype machine later this week.



  • The firmware runs, and nothing burns or explodes. First move:

    https://photos.app.goo.gl/JPLjTp6sa2km2GvX6

    Astute observers will see the completely wrong tool coordinates at the end of the video. Other things are also wrong (object model for example does not report the name, and some other things are not as I expected. In other words: This needs more work).


  • Moderator

    @oliof Very cool. Love it!

    Ian



  • And with a bit of strategic lifting of code from other kinematics and the original implementation, we have the first proof of coordinated moves in Colinear Tripteron Kinematics in RepRapFirmware:

    https://photos.app.goo.gl/UyoLtbQVdYme7fNd8

    It's a short minute of test move to Z100 and then some straight lines on X and Y.

    Some observations: A tower is to the right, and X goes from left to right. This is seemingly absurd coming from the world of linear deltas, but it simplified the kinematics.

    Now, this was the easy part. The hard part is implementing all the things people expect like endstop correction, object model, etc. I'll keep you updated.



  • Implemented endstop correction (without autocalibration for now) and added endstops. Found out that moves in the X/Y plane are off by a factor of 1.25, and while that is close to the typical 16/20 tooth confusion for steps/mm, movements in Z are correct so it's not that.

    My hunch is that it has to do with arm length, but I currently lack enough extrusions of different arms to replace the ones I have, and my actual understanding of the kinematics isn't deep enough to reason about it mathematically. If all else fails, I'll implement a compensation factor.

    Also, the considerable backlash is concerning, and in parts a result of the multiple linkages moving around in different planes. I do have some Rc car dampeners on order to see if they can improve the stability.

    On the software side, some things don't seem to work even though I lifted them from other kinematics verbatim (NumHomingButtons from LinearDeltaKinematics for example -- I still get individual buttons for homing X/Y/Z even though NumHomingButtons returns 0. I likely missed some other thing I need to set is one; the kinematics info in the ObjectModel is the other).

    And I really need to get to LimitPosition and write down some notes how to construct a Colinear Tripteron so it prints reasonable (basically you need to allow arms to move lower than Z=0).



  • For me all this is like Cyrillic 😰 but I'm curious...
    For backlash do you mean the small wave when it start a new strait line ? (it is pretty clear at any start line). Seems there is some play that all the time found its rearrangement at specific angles of the arms , how is intended remove it with dampeners?



  • The system is not very rigid, if I push an arm or the effector, there is some back-and-forth action:

    https://photos.app.goo.gl/m4fgY8rMg5vfDYd1

    An experiment with rubber tubing seems to alleviate that a bit:

    https://photos.app.goo.gl/DFMC1Wirr2k1nVTy8

    But that configuration means the rubber would need to stretch across the whole build area.

    So I need to figure out another way to "eat" the energy without disrupting the intended moves.

    The shock absorbers are an experiment, I have no idea if and how they will work out.

    Mind you, according to the original designer, this is the second known build of this design, and his was scrapped at this development stage two years ago. So I am basically on my own here (and a bit out of my depth to be honest (-: ), striking new ground.

    Adventure!



    • Compensation factor works!
    • Kinematics are reported as implemented in the object model!
    $ curl -s 'http://192.168.86.203/rr_model?key=move.kinematics&flags=v,d4' | jq
    {
      "key": "move.kinematics",
      "flags": "v,d4",
      "result": {
        "armAngle": 30,
        "homedHeight": 140,
        "name": "colineartripteron",
        "planarMoveCompensation": 0.8,
        "printRadius": 120,
        "towers": [
          {
            "endstopAdjustment": -0
          },
          {
            "endstopAdjustment": -0
          },
          {
            "endstopAdjustment": -0
          }
        ]
      }
    }
    
    • DWC does not use NumHomeButtons to determine whether the axis specific homing buttons are shown, but matches the kinematics names. @chrishamm I will likely send a patch your way soon.

    My experiment with shock absorbers was a success, because I learned something: They clearly limit the inherent backlash in the loosely coupled linkages (the joints are fine, it's just an aspect of the colinear tripteron's multi planar setup), but the ones I tested with also interfere with the movement system. I can either try to find a better fit (with no idea how to improve from where I am other than I need shock absorbers with longer arms), or live with it for now.

    Biggest missing piece for something I find worthy of requesting a merge is a half-way proper implementation of LimitPosition.



  • Forgot a photo!
    damper.jpg

    This RC car shock absorber is 70mm in length and likely installed suboptimally.



  • Replaced the 70mm ones with 128mm ones (which improved actuating length from 12mm to 24mm).

    Here are two videos, first one showing some arc moves, second one showing some 90 degree turns (the latter one at 20/40/80/100/120 mm per second).

    https://photos.app.goo.gl/Y3frGmEFgrJKHJWF6
    https://photos.app.goo.gl/MVpwJCj64moNfV69A

    Especially in the second you can see that backlash is still there and while the shock absorbers eat them, they also make for weird starts and I'm still not 100% sure that they are a good idea overall.

    Oh well. Unless someone has a good idea, I think I am at the mechanical limits of this build. Maybe if RRF 3.2 implements junction deviation this particular kinematics would benefit from it. Maybe not.

    Time to take a break from this (I have a CoreXY to get up and running again sitting nearby, possibly a welcome distraction).



  • @oliof This is a nice looking printer and the first version is IMHO a prototype and proof of concept and a source to get new ideas. The shock absorbers look nice, I will try them (for a totally different idea).

    I would have some ideas, but better for a new prototype, like making the frame stiffer or trying Hylite or another compliant mechanism as hinges.

    Anyway, Tripteron is an interesting printer, because the three arms should give high precision.



  • @JoergS5 thanks for the reminder that this is but a prototype which has fulfilled it's main duty: A reference machine to use for testing the kinematics implementation for RRF.

    Compliant hinges are a great idea, unfortunately I lack the workshop to machine Hylite at any precision.

    The frame itself is quite stiff, but some additional bottom corner bracing could help. I have the right stuff around for that (-:

    I have one more idea: shorter arms, which should reduce the lever action somewhat. Also needed to improve my understanding of the kinematics. The extrusions for that arrived a bit late yesterday, but I should be able to give that a spin today.



  • @oliof said in Colinear Tripteron Progress:

    Compliant hinges are a great idea, unfortunately I lack the workshop to machine Hylite at any precision.

    I saw that you are located in germany also. I bought a few plates of Hylite and when my CNC is ready, I will make tries. I can give you some samples then for testing, for free of course. But it will take maybe 2-3 months from now until I can route them precise.

    I bought 3 of those here:
    https://www.modulor.de/hylite-alu-pp-verbundplatte-silber-1-2-x-250-x-500-mm.html



  • Thanks for the great offer! l am looking forward to what you'll do with Hylite (the Hylite thing I hoped for never came to be, sadly). Let me know when you are ready and we will sort something out (-:

    In the mean time I exchanged the arms for shorter lengths (150mm per segment, rather than 200mm), and backlash reduced visibly on my square movement (so much that I can drop the shock absorbers. Oh well). But now I have the hinge collapsing if arms stretch out, so they're likely to short (for the planned workspace, but for this prototype it's cool beans).

    Also, my compensation factor is still needed, so it's probably tower distance that affects effector placement. Bears testing, but likely not before July (experimentation funds running low).

    PS: Modulor is just a bike ride away from me, very dangerous place. For my wallet.


Log in to reply