Paid development of Rotary Delta kinematics for esp32[FR]

[mac7988]

Is your feature request related to a problem? Please describe. A clear and concise description of what the feature is:

• HAL kinematics

Describe the solution you'd like A clear and concise description of you would like to achieve and who it should work.

Describe your target machine hardware A clear and concise description of your target machine hardware (mechanics, electronics, etc..). Delta robot Additional context Add any other context or screenshots about the feature request here.

[Paciente8159]

Hi there, Thanks for your feedback.

About payment, this is a free project that I maintain out of heart. Contribution are welcomed to help me acquire new electronics work in the project expansion...but they are not mandatory. You can contribute WHAT you want and IF you want. Other ways to contribute is to help me test out new things in hardware I don't have available, report problems and help me grow this project.

So with that out of the way I'll be more than happy to help you achieve this and add this feature to the project. Can you send some more info about your machine and if possible a picture of it or other that is similar? Just one note kinematics will work on any current supported MCU and future supported.

[mac7988]

thank you for your response.

1) I am trying to bring Delta robot more accessible to small makers.(see image below)

2) below is a Kinematics this developer has which converts XYZ into degrees https://www.marginallyclever.com/other/samples/fk-ik-test.html

I am in the process of designing a small delta that can be 3d printed so we can test. I can also pay for for the materials required so you an I can test on the same platform.

[Paciente8159]

That's a really nice project. Just one question. There will be some homing switches on the top of the arm biceps for homing?

Just another note on the matter. µCNC is not designed to serve as a 3d printing firmware. It's aimed towards CNC and laser (and in that sense can be used to control a machine like a robotic arm). Although it might be extended to do 3D printing it's not the scope of the project. For that there are plenty of much more capable projects like Marlin and Klipper.

I think this should relatively straight forward by using the code provided on this site directly. Homing and the rest of the core motion calculations should be similar to the way the linear delta is handled.

Looking at the draft I should be able to source most of the materials needed. I already have the electronics and steppers laying around and I can print my own parts including the pulleys. I think the only stuff I may not have around is the closed belts and the forearms with the ball joints.

I'll start working on the kinematic and I will let you know on the progress of it. I found a simulator that I can use to check if the generated steps are correct or not.

[mac7988]

There are homing switches where the bicep would be horizontal to the floor. Which would be 0.

That simulator is really kool. I have a few pcbs on hand. I made a 6 axis esp32 board that uses 74AHCT595 for step and Direction pins. Does your firmware support this?

[Paciente8159]

Yes 74HC595 is supported and can be customized to fit your board.

[mac7988]

That is amazing. I made the board to work with fluidnc. It works great on fluidnc but they don't have support for Rotary Delta.

On Tue, Nov 1, 2022, 7:39 AM Paciente8159 @.***> wrote:

Yes 74HC595 is supported and can be customized to fit your board.

— Reply to this email directly, view it on GitHub https://github.com/Paciente8159/uCNC/issues/323#issuecomment-1298393094, or unsubscribe https://github.com/notifications/unsubscribe-auth/AET6ZCJXT4VEBS5S5BY5HETWGD6QBANCNFSM6AAAAAARR4NTNM . You are receiving this because you authored the thread.Message ID: @.***>

[Paciente8159]

Sorry about the lack of news. I've been unable to touch the project for the past 4 days, but I think I'll be able to resume work now. I've implemented the kinematics based on what I've researched, but I'm still trying to figure why the output is not matching the results I'm getting from this calculator. I'll do some more testing to see what I can come up with and I'll let you know.

EDIT: OK after parsing my C code and the javascript implementation on the site I found the bug in the my code. Everything seems to be lining up.

EDIT2: 2h after this initial comment I have (I hope) found the last bug in the kinematics implementation. The only thing missing is to compute the working volume boundaries and the new kinematic should be up for testing.

[Paciente8159]

Just another question. What will be the total resolution in steps per angle in your machine (the geared belt ratio + microstepping)?

EDIT: Also at what angle will the bicep arms home relative to the base?

[Paciente8159]

Motion is implemented, boundaries calculations and homing too. It's available in this branch Regarding home it's not actually complete because there is still the need to reference the homing position to a spacial coordinate to sync the biceps angles and the effector position. After that it should be controllable.

After figuring that part is a matter of actually putting it to a spin test.

[mac7988]

You are super fast. I am also almost done with the mechanical design. Should be done by the 15th.

Regarding homing. If you home where bicep is horizontal to the floor as 0 degree that would keep everything relative to that position.

[Paciente8159]

Yes 0 degrees is a well known position. My question is. Your endstops will be triggered at 0 degrees? Will the biceps not go above that angle?

I would like to make this adaptable to any delta bot.I've seen videos of several bots that home well above 0 degrees and I'm trying to figure a way to make this easy to configure.

[mac7988]

I totally agree with you that it should be more adaptable to any Delta.

I wonder if making a home offset configurable would a way. For example if your home sensors is at -15 degree the machine should move to center line of the bicep and forearm after homing. If this is not horizontal to the floor you just input the difference and rehome.

Let's say $180 = 2 ( additional compensation to 0 degree)

On Mon, Nov 7, 2022, 5:42 PM Paciente8159 @.***> wrote:

Yes 0 degrees is a well known position. My question is. Your endstops will be triggered at 0 degrees? Will the biceps not go above that angle?

I would like to make this adaptable to any delta bot.I've seen videos of several bots that home well above 0 degrees and I'm trying to figure a way to make this easy to configure.

— Reply to this email directly, view it on GitHub https://github.com/Paciente8159/uCNC/issues/323#issuecomment-1306325610, or unsubscribe https://github.com/notifications/unsubscribe-auth/AET6ZCJYPZ6R7DWYMIAKULLWHGAVJANCNFSM6AAAAAARR4NTNM . You are receiving this because you authored the thread.Message ID: @.***>

[Paciente8159]

It can be done either way. Or via distance or angle. I guess I will go with angle then. What is your experience on that matter with other firmware?

[mac7988]

Delta x firmware had angle.

On Tue, Nov 8, 2022, 4:22 AM Paciente8159 @.***> wrote:

It can be done either way. Or via distance or angle. I guess I will go with angle then. What is your experience on that matter with other firmware?

— Reply to this email directly, view it on GitHub https://github.com/Paciente8159/uCNC/issues/323#issuecomment-1306891137, or unsubscribe https://github.com/notifications/unsubscribe-auth/AET6ZCNYBLBDHKME3O4TOE3WHILVHANCNFSM6AAAAAARR4NTNM . You are receiving this because you authored the thread.Message ID: @.***>

[Paciente8159]

I've implemented the homing setting and angle. I guess the thing left to do is to try and run/simulate this. I'll start by doing that on the virtual HAL for windows and see if it all works as expected.

[Paciente8159]

Homing seems to be working although I have to review a behavior. The issue seems to be regarding calculating the correct feed rate at these really (and I do mean really) lower steps per second rates. Motion is a bit wobbly but I guess that is expected since the positional error is significant with a mechanism like this. I'm testing things with a configuration of 3200 steps per full rotation of the bicep which results in a motion precision of about +/-0.316mm.

I still have some work debugging and modifications but if everything goes as well it should be ready for you to test before you build it. In the mean time you can also join the µCNC server on discord if you want to leave any message through that channel, regarding implementation of the kinematics.

[mac7988]

This is great news. You mentioned resolution of +-.3mm. where did you calculate that from? Was that from marginally cleaver calculator?

On Tue, Nov 8, 2022, 5:49 PM Paciente8159 @.***> wrote:

Homing seems to be working although I have to review a behavior. The issue seems to be regarding calculating the correct feed rate at these really (and I do mean really) lower steps per second rates. Motion is a bit wobbly but I guess that is expected since the positional error is significant with a mechanism like this. I'm testing things with a configuration of 3200 steps per full rotation of the bicep which results in a motion precision of about +/-0.316mm.

I still have some work debugging and modifications but if everything goes as well it should be ready for you to test before you build it. In the mean time you can also join the µCNC server on discord https://discord.gg/KdtKq9THN9 if you want to leave any message through that channel, regarding implementation of the kinematics.

— Reply to this email directly, view it on GitHub https://github.com/Paciente8159/uCNC/issues/323#issuecomment-1307942460, or unsubscribe https://github.com/notifications/unsubscribe-auth/AET6ZCPAA3I4U7J3CVAJP7LWHLKHLANCNFSM6AAAAAARR4NTNM . You are receiving this because you authored the thread.Message ID: @.***>

[Paciente8159]

Yes. I'm using the same settings for the delta simulation I'm running. Obviously those figures will all change according to your design (gear ration, microstepping, bicep and forearm length, etc...).

I have the homing pretty much nailed with the latest changes I believe.

About the speed issue (and after running the code in my head for a couple of times) I think I know how to address the issue...but it will be a somewhat significant change to the motion control core module that will affect all kinematics so it will require some more in-depth tests. I'll keep you posted on the evolution of it all. Hopefully will also result in a significant reduction in the number of CPU cycles spent on the core planner...let's see what I can come up with..

[Paciente8159]

I'm merging a branch with the modified feed calculations that is able to cope with non linear kinematics. At this point I would say the firmware is ready for a spin.

But this whole problem left me the feeling that I may have to review a substantial portion of the core code that goes from the final stage of the motion control, planner and stepper interpolation.

For now I will leave it as it is and will start rework on that in parallel.

[Paciente8159]

I did the full review on the motion control, planner and interpolator and made all the necessary modifications and code cleanup to have an overall better and cleaner solution to handle feedrate calculations for all types of kinematics.

The kinematics is ready to be tested and added to the firmware.

It's just a matter of testing now.

[mac7988]

Amazing work. I am printing the parts now. Hoping to have a working robot by end of next week. I will be using a nema 34 closed loop stepper for the robot directly connected to the bicep. Just to keep the design simple.

On Thu, Nov 10, 2022, 6:04 PM Paciente8159 @.***> wrote:

I did the full review on the motion control, planner and interpolator and made all the necessary modifications and code cleanup to have an overall better and cleaner solution to handle feedrate calculations for all types of kinematics.

The kinematics is ready to be tested and added to the firmware.

It's just a matter of testing now.

— Reply to this email directly, view it on GitHub https://github.com/Paciente8159/uCNC/issues/323#issuecomment-1311018140, or unsubscribe https://github.com/notifications/unsubscribe-auth/AET6ZCPFCTPBGOD224GVI2LWHV5RNANCNFSM6AAAAAARR4NTNM . You are receiving this because you authored the thread.Message ID: @.***>

[Paciente8159]

Can't wait to see it fully assembled and running. Do you have your project publicly available somewhere?

To save you some time in the initial setup here are some hints.

Settings

You need to take this in account while setting up the firmware.

$106 = is the base radius length in mm $107 = is the effector radius length in mm $108 = is the bicep length in mm $109 = is the forearm length

Settings $100 (steps per mm for X), $101 (steps per mm for Y), $102 (steps per mm for Z), should be interpreted as steps per full 360º rotation of the bicep.

Regarding homing:

$28 = is the homing switches angle (in degrees) You need to enable homing ($22=1) and hardware limits ($21=1). Since this is a delta machine and homing is done by moving away from the base you need to invert homing direction $23. Only Z axis direction is considered (X and Y mask is ignored), but to simplify thing just use $23=7 (invert X, y and Z homing direction) and you will be good to go.

Modify speeds and accelerations as you wish. I recommend starting conservative. After modifying all settings, do a soft reset or turn the board off and then on to rebuild the kinematics.

Initial pre-flight checks

Make sure all stepper motors and limit switches are matched. Motor X should be paired with X limit switch, Motor Y should be paired with Y limit switch and Motor Z should be paired with Z limit switch.

If you have controls pins enabled and ESTOP wired test it to see if it kills everything and resets the machine.

REMEMBER - if the control pins are enabled and ESTOP is defined in the boardmap and not wired most probably the board will be an locked state (permanent emergency stop alarm triggered)

Test all limit switches and check if the limit switch status is showing correctly. Send a short motion command up at slow speed like G1Z2F50 and confirm that all motors are rotating in the correct direction.

The next step is to send a home commands. As always if you don't have a wired ESTOP properly wired and tested I recommend having a way to cut power to the machine in case it crashes anywhere.

[mac7988]

Quick question. If the move is not possible will it error or attempt to execute to move?

[Paciente8159]

It's configurable. If you enable $20=1 (enable soft limits) it will check the computed software limits and will not execute that gcode command issuing an error for that specific command.

If the remaining gcode is executed or continues is up to the controlling software.

You can also toogle check mode $C prior to run a particular gcode. This will execute gcode without doing any motion. Everything is processed apart from the final motion stage. After disabling check mode the firmware will soft reset and you will have to home the machine.

[Paciente8159]

Hi there. I've tested the changes that affected feedback calculations in the core (including Laser PPI mode) and I will be merging this branch in the master (even without a real machine test in the rotary delta). I need to push it so I can continue to work on other features.

In the last days I've been doing a full rework on the ESP32 HAL to get more juice out of the MCU. This will also be merged soon and includes:

• Migrating most code from Arduino to Espressif IDF
• dropped WiFiManager (not workin properlly)
• added system commands fro WiFi and Bluetooth that now can be compiled together without crashing
• IO manipulation is now alot faster (direct)
• added special support to use I2S to control the 74HC595
• moved part of the interrupt handling to a different core to balance ISR handling

Hope you are doing good and I hope to see your machine soon