Forum Replies Created
-
AuthorPosts
-
It may be possible to use GRBL to additive process, but as I have no experience doing that I can´t ensure it… I remember that someone made a Marlin Version for Thor in the past (Marlin is a common firmware used for 3D printing). But I can´t remember who did it…
Knowing that you have checked the driver and that it works correctly, I think I know where the problem with the movement of articulation3 may be. Have you tensioned the open belt using the tensioners inside the Art2BodyA part? If the belt was not tensioned, it could cause the effect shown in the video.
On the other hand, regarding the separation of art2 from art1, this has happened to me. It may be that the play that the second articulation has over the first one is excessive and causes a sufficient displacement so that the gears do not make contact. Make sure that the Art2BodyUnion piece is well tightened and that the rods of the axis that joins both articulations have the correct measures. If after this the excessive backlash is not resolved, you could try increasing the length of the shaft opposite the motors slightly, to force the contact between gears. In case it helps, user imernchavez posted on this post http://thor.angel-lm.com/forums/topic/suction-cup-tool/ a modification to add a bracket to art2 that helps support the weight of the arm and that may be of help to you. This is the piece: https://github.com/AngelLM/Thor/blob/developer/stl/mods/SupportRoller.stl
Best regards!
——-
Sabiendo que habéis comprobado el driver y que este funciona correctamente, creo que ya se donde puede estar el problema con el movimiento de la articulación 3. ¿Habéis tensado la correa abierta utilizando los tensores del interior de la pieza Art2BodyA? Si la correa no estuviese tensa, podría provocar el efecto que aparece en el video.
Por otro lado, respecto a la separación de la articulación 2 de la 1, a mi si me ha pasado. Puede que el juego que tiene la segunda articulación sobre la primera sea excesivo y provoque un desplazamiento suficiente como para que no engrane. Aseguraos que la pieza Art2BodyUnion está bien apretada y que las varillas del eje que une ambas articulaciones tienen las medidas correctas. Si tras esto el juego excesivo no se soluciona, podríais probar a incrementar ligeramente la longitud del eje contrario a los motores, para forzar el contacto entre engranajes. Por si ayuda, el usuario imernchavez publicó en este post http://thor.angel-lm.com/forums/topic/suction-cup-tool/ una modificación para añadir un soporte a la articulación 2 que ayuda a soportar el peso del brazo y que puede serte de ayuda. Esta es la pieza: https://github.com/AngelLM/Thor/blob/developer/stl/mods/SupportRoller.stl
Un saludo!
Hello Nexus!
I have not seen anyone using Thor for 3D printing yet. If you are going down that road, let me warn you of a couple of things that can go wrong if you use this robot.
The control firmware used for this robot is a modified version of GRBL. GRBL is a firmware designed for CNC machining machines, not for 3D printing, so you would need to adapt a 3D printing firmware (e.g. Marlin) to work with Thor’s configuration.
On the other hand, trajectory generation would be a problem.
Currently the programming of Thor’s movements are manual. I have not developed any specific trajectory generation software for Thor and I do not know if there is any that can be adapted to this robot.
Even now, with GRBL I have complications to make straight lines with the robot, since the GRBL configuration allows me to configure the motors to start and end their movement at the same time, or for each of them to do it at the indicated speed, but so far I have not been able to ensure that you can make movements in a straight line only by entering a starting point and an end point.In short, you could use Thor to 3D print, but I think only the mechanics and electronics. But you would have to develop the control and trajectory generation part yourself.
Obviously, if you decide to take the step, I’ll be happy to give you a hand if you need it!
Hi Epiktetos!
Thanks for your words! It is always a pleasure to hear that more people are attracted to this project 🙂
I heard and seen some things about RoboDK and yes, if that software would work with Thor it would be very interesting.
But as RoboDK is neither Open Source nor free, it has not crossed my mind to explore how Thor could be compatible with this software.Anyway, if you are going to try it and I can help you in any way, don’t hesitate to ask me!
Best regards!
Very cool!! I love it! <3
Hello Sebasshare!
Looking at the video, and ruling out mechanical problems, it looks like it could be a power problem in the driver.
I would tell you to do a simple test. Try to move that joint holding the weight of the robot yourself, helping it with the load. If this does not produce a loss of steps in the motor, it is probably a power problem in the driver.
If so, you just have to adjust the driver voltage, increasing the current it provides to the motor of that joint to see if that solves it.Keep us updated!
—
Hola Sebasshare!
Viendo el video, y descartando problemas mecánicos, tiene pinta de que puede ser un problema de potencia en el driver.
Te diría de hacer una prueba sencilla. Prueba a mover esa articulación sosteniendo el peso del robot tu, ayudándole con la carga. Si de esta forma no se produce una pérdida de pasos en el motor, seguramente sea un problema de potencia en el driver.
De ser así, solo tienes que ajustar el voltaje del driver, aumentando la intensidad que proporciona al motor de esa articulación a ver si así se soluciona.Mantennos al tanto!
Hi Mohamed! No need to apologize! You see I can’t answer immediately sometimes either.
The firmware I use to move Thor is a modified version of GRBL. And instead of using steps/mm what I did was to use steps/degree.
That is, the DEFAULT_X_STEPS_PER_MM variables of GRBL config files units are steps per rotation degree instead of steps per mm. And these are the values of the vars:#define DEFAULT_A_STEPS_PER_MM 44.5 #define DEFAULT_B_STEPS_PER_MM 270.0 #define DEFAULT_C_STEPS_PER_MM 270.0 #define DEFAULT_D_STEPS_PER_MM 265.0 #define DEFAULT_E_STEPS_PER_MM 20.0 #define DEFAULT_F_STEPS_PER_MM 250.0 #define DEFAULT_G_STEPS_PER_MM 250.0
To calculate each one I just used the step angle of the stepper motor (usually 1.8 deg), the gear ratio of each articulation and the microstepping of the driver (usually 1/16).
For example, for the first articulation, we have a stepper motor with 1.8 deg/step, a gear ratio of 5:1 (as the driver gear has 10 teeth and the driven one 50 teeth), and a microstepping of 1/16 configured in the stepper driver. So, (1/1.8)*16*5 = 44.4444… Rounding up to 44.5.About the printed gears, I used helical geard instead of spur gears because they have hreater tooth strength and can withstand higher loads. The parameter of each gear (module, angle, teeth, etc) can be seen in the FreeCAD model. If you open the FCStd file of a part with a gear, you can navigate through the Tree View to the involutegear object to see the parameters:
Hope this helps! 🙂
Hi Mohamed!
Your Thor looks great! I hope you will tell us more in the future about the control software in matlab 🙂
Now it is registered in the Worldwide Section as the number #25!
Welcome to Thor family 😉
Hello necaettin,
I don´t know what part are you referring to. If you are looking for the gripper STL files you can find them all in Thor’s github repository
Hope it helps!
Thanks for the contribution! 😉
That’s what I was thinking…
Could I ask you for that design as well? I would like to include it in the modifications section of the github repository along with the design of your end-effector!
In fact, if you have a github account and want to make a pull request with your designs to Thor’s repository, I’ll be happy to accept it 🙂Some time ago I also thought about developing my own firmware. Actually, with GRBL, Thor’s movements are not like those of a normal robot, since the movement of all motors starts and ends at the same time, making linear movements not possible. Or at least I think so.
If you decide to design your own firmware, please keep me updated!Hi Mendy!
You can see the configuration files of GRBL I modified in order to make it work for Thor: https://github.com/angellm/grbl
However, these are the most relevant ones:
Steppers ENABLE/DISABLE signal
#define STEPPERS_DISABLE_BIT 1 // MEGA2560 Digital Pin 40
Steppers STEP signals
#define A_STEP_BIT 6 // MEGA2560 Digital Pin 28 #define B_STEP_BIT 4 // MEGA2560 Digital Pin 26 #define C_STEP_BIT 2 // MEGA2560 Digital Pin 24 #define D_STEP_BIT 0 // MEGA2560 Digital Pin 22 #define E_STEP_BIT 1 // MEGA2560 Digital Pin 23 #define F_STEP_BIT 3 // MEGA2560 Digital Pin 25 #define G_STEP_BIT 5 // MEGA2560 Digital Pin 27
Steppers DIR signals
#define A_DIRECTION_BIT 1 // MEGA2560 Digital Pin 36 #define B_DIRECTION_BIT 3 // MEGA2560 Digital Pin 34 #define C_DIRECTION_BIT 5 // MEGA2560 Digital Pin 32 #define D_DIRECTION_BIT 7 // MEGA2560 Digital Pin 30 #define E_DIRECTION_BIT 6 // MEGA2560 Digital Pin 31 #define F_DIRECTION_BIT 4 // MEGA2560 Digital Pin 33 #define G_DIRECTION_BIT 2 // MEGA2560 Digital Pin 35
Endstop signals
#define A_LIMIT_BIT 7 // MEGA2560 Digital Pin 42 #define B_LIMIT_BIT 5 // MEGA2560 Digital Pin 44 #define C_LIMIT_BIT 5 // MEGA2560 Digital Pin 44 //3 // MEGA2560 Digital Pin 46 #define D_LIMIT_BIT 1 // MEGA2560 Digital Pin 48 #define E_LIMIT_BIT 0 // MEGA2560 Digital Pin 49 #define F_LIMIT_BIT 2 // MEGA2560 Digital Pin 47 #define G_LIMIT_BIT 2 // MEGA2560 Digital Pin 47//4 // MEGA2560 Digital Pin 45
Tool signal:
#define SPINDLE_ENABLE_BIT 4 // MEGA2560 Digital Pin 7
As soon as I have some time I’ll add it to the mods folder at Thor’s repository and I’ll note it down to incorporate it for future versions! 🙂
Thank you very much for contributing to the project! 🙂
Impressive job! Thanks for sharing the design! 🙂
I noticed that your robot has bearing supports under the second joint. It seems to me a great solution to release the load that falls on the axis. Have you noticed improvement in the movement?
-
AuthorPosts