Notifications
Clear all
Topic starter
2025-02-02 4:38 am
A demo video of my assembly of the 4DOF Robot Arm from LK Cokoino.
Here are the kit packaging and parts
On the right is a leftover sprue from the acrylic parts. You get 2 small screwdrivers, for M3 and M1 screws, and tiny wrench you need to hold the small M3 nuts in place during assembly. The bags are labeled to help keep track of where things are, which is helpful. There are 4 SG90 servos, one of which has metal gears. There is a 3-inch Lazy Susan used in the base and then set of metal and nylon spacers. The kit comes with a set of joysticks and connecting wire to control the arm and well as a battery case for the oversized batteries used. Finally, you get the Arduino Nano and a custom shield that everything connects to.
The build is fairly easy and should take no more than 1-2 hours. Some of the small screws can be a bother and the servo connections need good lighting to see properly.
The final result does what they say but I found it unsatisfying. The USB cable is too short at 12 inches so that it feels cramped. The bot is lightweight so that it tends to hop about with rapid movement and needs some ballast. The joystick control is both jerky and over sensitive; the bot tends to drift due to joystick jitter. The button control on the joystick is not used (but needs to be) and the full range of motion is not achieved.
However, for the price, it's a good base to work from.
The one who has the most fun, wins!
robotBuilder reacted
2025-02-02 4:55 am
Perhaps it would work more smoothly if controlled by a computer code alone?
Is the issue in too much change taking place when you manually use the joysticks?
2025-02-02 5:07 am
Topic starter
2025-02-02 5:48 am
Perhaps it would work more smoothly if controlled by a computer code alone?
In general, I think so.
Right now, I think the SW implementation of the joysticks is the main culprit. Another issue is algorithm for the joints is very poor.
I have plans to make significant improvements with the code, as is, and then introduce kinematics and some smoothing code to see how well it can perform.
There's also some physics involved, though. There's a lot of mass above the elbow.
James Bruton has done smoothing of servo motors.
I have viewed James Bruton's video. He uses a damping calculation to get a "smooth-in" effect for the eye movement, which is very effective. He uses another technique for his walking robots. He has a name for it ("compliant" I think) but it's a reactive force that counteracts inertia. The electronics are more involved for that.
One thing I'll be looking to find out is if these techniques can be applied after the kinematics calculations and how well they work with cheap servo and a better servo.
The one who has the most fun, wins!
2025-02-06 1:45 pm
I got one of these for Christmas and assembled it. I found the reviews in here are accurate. Indeed, the servos are very jerky, and smoothing code would help a lot. Also, I think the joystick code could use some work. I started this but have limited time to complete. If anyone has replacement code, please post.
Topic starter
2025-02-06 4:06 pm
If anyone has replacement code, please post.
I'm working on this now. Give me time. I have a simple change to the joystick code that damps down the joystick jitter.
The servo code is ... peculiar. The input functions clamp the joystick positions to force a direction (UP/DOWN, LEFT_RIGHT) which is counter intuitive. The servo movement code sets the position angle (clamped to 0-180) but the move is unrestricted. After the move, a delay is applied in an effort to damp down the movement and allow the servo to reach steady state. it's ineffective.
I'm working on controlling the movement through the serial port, (the Nano space is just too tight) and using gtest for the test harness. My plan is then to apply the Arduino ramp code to smooth the movement out and also apply the Fabrik kinematic library to get the full range of motion.
The one who has the most fun, wins!
sj_h1 reacted
Topic starter
2025-02-08 8:06 pm
To explore the codebase, I've written some test code for joystick filtering to reduce jitter and another to test servo movement. The results are mixed. The joystick filtering works better than expected while the servo movement tests indicate significant structural or hardware challenges.
The video of the servo test is ArmExTests
I've attached a archive file that contains the code and documentation of the tests, so I won't cover them in detail here.
There are initial tests that explore the code base. The results are mixed. The joystick jitter code turned out better than I expected but, in the end, I think better hardware is needed.
Similarly, the servo test shows that there's still considerable jerky movement, but it would appear to be for one type of movement. I believe the cause is structural in nature so I don't hold out much hope that the ramping or kinematic code will overcome it. It might be related to the servo quality, but I'm not convinced of that. Also, I don't feel that damping code, such as that by James Bruton, will prevent it. I think what is needed is some sort of physical "shock absorber" (spring or similar) that would damp down the inertia.
Onto controlling the arm remotely through the serial port!
This post was modified 2 months ago 2 times by TFMcCarthy
The one who has the most fun, wins!
2025-02-08 8:18 pm
I think what is needed is some sort of physical "shock absorber" (spring or similar) that would damp down the inertia.
That is the impression I had when watching the video. As it lowers it seemed to get into a physical oscillation which was separate to the servo motor control.
2025-02-08 9:41 pm
@tfmccarthy I have NO experience with these things, but what I saw in the video is exactly what I expected to see. I think it's more mechanical advantage over coming electrical motor torque. The claw never jitters, the short arm also is either free of it or very sight, I can't remember what I just saw 1 minute ago. It gets worse as the moment arm gets longer. My immediate reaction upon seeing the video is 'what do you expect?'
I wish I had an answer, or even some fruitfully questions but so far nada. All I am saying is when I saw the video it looked exactly like what I expected to see.
Just went to watch it again, but to my eye there is NO jitter when rising back up. Again, exactly what I would expect. I wish I could provide better data, but this is what my gut is telling me.
How are the motors connected, gears, cables. Is more torque needed, what about mechanical looseness in the gear train or cable assembly.
I might just have to buy a kit and join the growing crowd of roboticists.
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, 360, fairly knowledge in PC plus numerous MPU's & MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
Topic starter
2025-02-09 5:17 am
As it lowers it seemed to get into a physical oscillation which was separate to the servo motor control.
I went back and checked Bill's DBWS video, and the same oscillation happens though to a smaller degree. As you had previously mentioned in a different post, the servos Bill uses are higher grade, so that has some effect. I can't quite see why rotation in the opposite direction doesn't show the same oscillation. Part of it may be the imbalance due to the claw, which makes me wonder about trying a counterweight on the end. But it's too early for that sort of experiment. I want to see what effect the Ramp and kinematic code have.
'what do you expect?'
None, really. I want to give Cokoino a fair shake in the testing. This is exploratory and characterization testing. I saw that the servo code could be made more efficient, which I deemed successful as it produces results similar to the original demo. It also demonstrated the full range of motion the original didn't use, so the kinematic SW won't get crippled. There's no "problem" to resolve but rather behavior to understand. There seem to be some limitations that I want to better understand before I try to overcome them. Right now, I feel the Cokoino SW can be better utilized.
The one who has the most fun, wins!
2025-02-09 5:12 pm
@tfmccarthy Is this the same kit? https://amz.cx/3Kso
What do you think of this kit? https://amz.cx/3Ksp
This post was modified 1 month ago by Ron
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, 360, fairly knowledge in PC plus numerous MPU's & MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
2025-02-09 5:25 pm
@tfmccarthy This is my 'gut' reply to your statement
I can't quite see why rotation in the opposite direction doesn't show the same oscillation.
The reason is the loose fitting gears are kept engaged due to gravity. Does that help?
Can you post a link to the kit, I am overloaded but I am also curious.
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, 360, fairly knowledge in PC plus numerous MPU's & MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
2025-02-09 6:59 pm
Maybe when moving down there is some kind of overshoot which is then corrected. Maybe some proportional (or PID) control required?
This demo seems to work smoothly?
Except I noticed when it was fully stretched and pointing straight up to the sky.
https://www.amazon.com/live/video/6384286c15494e7192c1926856a77242?ref_=dp_vse_rvc_3
I might just have to buy a kit and join the growing crowd of roboticists.
Easier and faster to trouble shoot if you have the product rather than do it remotely.
2025-02-09 7:16 pm
@robotbuilder Is it the exact same device?
The straight up situation is just bad coding, it should be hitting a limit and shutting down.
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, 360, fairly knowledge in PC plus numerous MPU's & MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
2025-02-09 8:18 pm
While the @tfmccarthy robot is fully stretched and during lowering it seems to move through some sudden drops the above example does not. it wasn't suggesting the same issue only that the video example had its own problem but seemed not to have the dropping issue. It would be much nicer to have the same hardware and see if you can work out the problem and then post an answer without the back and forth exchanges and guessing games. I see Bill's example is of a 6DOF dfrobot arm so not same product. I would like to build a robot arm myself but one that is useful and precise but the cost is prohibitive.
Page 1 / 2
Next