Forum Replies Created
-
Posts
-
Hi! I may not be able to give a very concise and accurate answer on this, as I did it many years ago and don’t remember it very well. I will try to do the best I can-
The home cycle is a function of GRBL that I just tuned to work with Thor. In the firmware file
config.h(lines 75 to 79) I added the homming sequence. The firmware filemotion_control.ccalls a function calledlimits_go_homethat appears to be in charge of the homming process. And sadly that’s all I can remember :SAbout the second comment, I may be wrong but I guess that when I was tunning the configuration file, I wrote the BIT and the digital pin of each sensor associated with its motor. As the motor C uses the same homming sensor as the motor B (as they both power the articulation 2) I copied the configuration of the B motor on the C one and I left the previous comment just in case I would need to locate the sensor’s pins. Same goes for the G motor.
Hope it helps! 😉
Hi Sebas!
I just saw that you already solved it! I did not face this problem, but I’ll write down the solution in case it happens to someone else!
Thanks 😉
Hi Claudio!
As you say, to do the homming cycle you should have connected every stepper and every sensor. The homming sequence is:
1. Articulation 2
2. Articulation 3
3. Articulation 1
4. Articulation 4
5. Articulation 5If you want to jog the motors without doing the homming cycle you can send the GRBL command
$X(Kill alarm lock) to bypass the homming.Hope it helps!
Hi Claudio!
If the servo is working fine by itself and it fails when assembled into the clamp, I can think of two things:
– The zero position of the servo is not the zero position of the clamp. The zero position of the servomotor should be when the gripper is fully open. If the zero position causes the gripper to try to open more than is mechanically possible, the motor will vibrate.
– The pick-up position of the servomotor is too high. As in the previous case, if we force the servomotor to go to an unreachable position for it, it will continuously try to reach it, which will cause vibrations and, sometimes, it could even burn the motor.Let me know if you have any of these two cases!
Hi Alex!
Sorry for the late reply! I’m glad you managed to find the answer to your problem!
About the question of the function of the jumper connectors, they are used to control the step size of stepper drivers.
As you can see in the PCB Schematic, each driver (marked as U1, U2, … U8) has 3 pins called MS1, MS2, MS3 (MS comes from Micro Stepping). These pins can have 2 states: LOW (0V) or HIGH (5V). I used jumper connectors to connect MS1, MS2 and MS3 to 5V and configure the microstepping as 1/16. Other configurations can be made by using different states in MS pins as shown in the “Step (and microstep) size” section of Pololu A4988 Driver product page.I hope I have cleared up the doubt!
Hi Bartek!
Yes, it is possible to prepare a sequence of GCode commands.
In the Rubik’s cube video I used the software Universal Gcode Sender to load a custom .gcode file and run it!Creating a custom .gcode file is simply as open the Text Editor, write the GCode commands you want the robot to execute and save it as FileName.gcode
After that, open the UGS, do the board connection, load the GCode file and run it 🙂Hope it helps!
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!
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.0To 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! 🙂
