Develop my own robot

DIY
9

I see several problems with stepper motors:

  1. Less power for the same size compared to servo drives, above correctly said that you have to do belt drives or add a reducer (which will have a negative impact on noise).
  2. The possibility of slippage, stepper motor can skip “steps” and has no feedback on its position, you need to add a calibration mode + some sensor.
  3. They are more expensive than servo drives, and more difficult to integrate.
10

Im no pro robotics expert (im a farmer) but I found that if I shim the gears in my airsoft rifle (for barn rats) the sound goes from very noticeable to almost silent. Wife doesnt even know what im up to! Im assuming thats also the point here :wink:

1 Like
11

Hello all, there is an update on the progress.
For a long time puzzled with MQTT, there is a suspicion that a large number of messages on the reception is badly handled by esp8266 - there were a lot of skipping movements.
I rewrote motion data transfer to sockets.
It turned out that there were glitches with the wireless module. Fixed it with the right SDK.
Had a little trouble with the buffer.
To do:
Need to work on synchronization - transferring current time from player to controller and correcting for time of receiving data from player and transferring movements.
A lot of things in the script for PC will have to be rewritten, it’s a shame to show the code there.
The first more or less decent result of movements on the video.

13

I don’t understand your comment.

14

Hello there. OSR2/SR6 creator here.

Just thought I’d drop by and say that it’s great that you’re working on a design of your own and to keep up the good work!

I would also recommend that you check out the T-Code open source infrastructure that exists, because this will save you from having to re-invent the wheel when it comes to getting the commands to your device from a multi-axis video player. My Arduino sketches for the OSR2 are all publicly available at this point and a big part of why they exist is to make stuff like what you’re doing easier.

Best wishes!
Tempest

8 Likes
15

Wow, a special guest star!

Nice of you to take the time and thank you. Of course I looked at your work and the specification for the protocol.

And tried to interpret the coordinates in global system (+/- 50 mm on X and Y axis, 0-100 mm on Z axis, +/- rotation in radians on XYZ axes) into scripts, to make the values play correctly. There is a little confusion in the names of the scripts - by the way can you advise how to properly convert the rotation motions so that they are correctly received by your devices (meaning SR6).
I still stick to the opinion to use quaternions + vector, in my future multi-axis device.

One reason is the order in which the rotations are applied (which is hard to fix).

image
image1181×791 70.9 KB

image
image1161×784 69.7 KB

The second is the difficulty of calculating intermediate values (spherical linear interpolation).

16

In practical terms I don’t believe that quaternions are necessary: this isn’t a precision CnC machine.

Angles (they’re sort of Euler angles I guess) work just fine. The pitch and roll rotations are angles that practically only go to +/- 30 degrees. From the point of view of a user, there is absolutely no way during use that they would notice if the difference if angle rotations were applied pitch then roll, or roll then pitch, so either can be used.

1 Like
17

Quaternions are difficult to understand, but easier to calculate (the calculations have to be done on a microcontroller) and more promising. I use +/- 0.5 radians for all axes, which is about +/-28.65 degrees.
Perhaps I am an idealist, and immediately want to do it right.
Collecting money now to buy a 3D printer, to create the first prototype :wink:

1 Like
18

image
Yes I want to continue the conversation :wink:

Just now realized how long I was silent about this topic…
3D-printer of usual volume (200x200x250 mm) was bought a year and a half ago. Started to collect my first prototype at once multi-axis a couple times during this time. The first time after having assembled the base with servo drives and running it on a microcontroller just to spin - I was horrified by the noise and abandoned this case on the shelf.
I decided to build a platform Stewart on stepper motors, were bought motors with gearboxes, long searched for a board with 6 drivers for stepper motors. As it turned out there is a very peculiar implementation of connection with drivers, sharpened only for one project - reverse engineering of the code took quite a long time and the process continues.
While thinking about using a ready-made board for a multi-axis robot or try to build it on my knees, with further development of the board, I realized that I lack the mathematical part of the robot control (vector + quaternion). Up to this point, the mathematics of calculating the moving part of the platform over the fixed base for linear actuators was ready.
As a result of the math and hardware testing (usability/size, etc.) I decided to go back to servos, keeping in mind stepper motors with planetary gearboxes and especially with wave gearboxes, which are quiet and more compact.

So, where I am now:

  1. I stick to autonomy in the work of the robot, so I use microSD memory cards to store scripts.
  2. Since the microcontroller doesn’t have much RAM I had to make some multi-axis scripts for myself in JSON Lines format.
{"at": 2538250, "pos": 70, "vector": ["3.96", "25.11", "65.22"], "quaternion": ["0.9827", "-0.1822", "0.0306", "0.0098"]}
{"at": 2538416, "pos": 35, "vector": ["0.25", "9.31", "33.74"], "quaternion": ["0.9909", "-0.1342", "0.0042", "0.0048"]}
{"at": 2538683, "pos": 85, "vector": ["9.27", "36.40", "76.25"], "quaternion": ["0.9738", "-0.2188", "0.0599", "0.0174"]}
{"at": 2538916, "pos": 15, "vector": ["-1.54", "3.86", "14.41"], "quaternion": ["0.9902", "-0.1298", "-0.0523", "-0.0027"]}
{"at": 2539150, "pos": 90, "vector": ["15.60", "38.84", "79.67"], "quaternion": ["0.9706", "-0.2199", "0.0951", "0.0254"]}
  1. Implemented methods on esp8266 to ping DeoVR wirelessly, open the script, and synchronize playing the script with the video (including jumping forward/backward through the video). Synchronization can be long.
  2. Re-printed the arm holder, servo levers, and base. I use carbon fiber tubing with a ball joint on one side and a metal ball on the other to connect to magnets sleeve holder.
  3. As microcontroller - Wemos D1 mini esp8266 + power board + card reader board + servo board pca9685.

I will run playback of multi-axis scripts.

1 Like
19

Ball magnetic connectors bought two different sets - after assembly it turned out that some hold strongly (force 7 kg each), the other weakly (1 kg force). I ordered something average - 5 kg and a bigger ball.
Before the new year the connectors were delivered, the base and holder were reprinted.
First test on the video :slight_smile: Do not throw stones.


What is different from SR6 - fully vector control, I will add quaternions (for rotations) later, as well as synchronized video playback on DeoVR with script from memory card.
I send from the keyboard numbers from 0 to infinity and through semicolon the second from 0 to 100 - the controller interprets the first as time in ms and the second as a 3D vector (0.0, 0.0, x.0) and with a frequency of 50 Hz calculates the interpolation of this vector and arms rotation.
The mechanics have shown their weaknesses:

  1. Arms need to be thicker.
  2. Base needs to be changed - the mounting of the upper servos.
1 Like
20

The pitcher links at the top need to form a triangle rather than run parallel if you want to have left-right translation control. Flip the two upper servos so that they face inward, as they are on SR6.

1 Like
21

Thanks for the comment, although I was thinking of doing it differently - flip the base 180 and flip the bottom servos 90 degrees. Since besides the problem with moving the holder left-right, there is also a problem with Z rotation at the bottom point (now it is -100 mm) at XY boundary positions (+/- 45) the rod rests on the holder.

22

Reprinted the base and arms, rewrote the math several times - there were errors in calculating and interpreting angles, broke two mounts. Now though it works, but I do not like the result - it will be inconvenient in work, it is necessary to turn the base and can be reprinted on a smaller one. In general - the work is in progress.

original_f0acbf89-3b89-4155-bbfd-18bf5dfbe97e_PXL_20250112_225855199
original_f0acbf89-3b89-4155-bbfd-18bf5dfbe97e_PXL_20250112_2258551991920×1809 268 KB

1 Like
23

As usually happens at startup burned one servo (good that I buy a stock - break/loss), ripped off one linkage, but finally finished the firmware, albeit with some problems - but I think everything will be solved. The video is still without the holder (the rod is glued) :wink:

  1. Of course with a holder it will be clearer. I will glue the rod - I will take another video of the work.
  2. Z rotations work (twist scripts - +/-45 degrees)!
  3. Synchronization is kind of excellent up to ms (by eye in running DeoVR on the phone).
  4. Still the limitations of the PCA9685 PWM controller on slow movements are noticeable - about 0.5 degrees resolution.
  5. Figured out how to do the same functionality (6 servos) to compress - by rotating the upper part relative to the lower left/right +/- 30 degrees on the thrust bearing.
  6. I do not like the mechanics I think horizontal arms rotate relative to the X axis 30 degrees up, and vertical +/- 30 degrees relative to the Z axis. It would then be possible to reduce the base and increase the twist to +/- 60 degrees.
  7. There is a random skip of points in the script - I think because of the time synchronization of the controller and DeoVR.
  8. Math is a cool thing - you can position the robot not directly to the user’s face, but to the right or left - recalculating the coordinates.
  9. Also interpolation should be reconsidered - now it is linear.
3 Likes
24

i would suggest using a more powerful powersupply. the servos can have really high spike power draw.
My SR6 has spikes of over 10A at 6.5V.

I am curious to see where your project goes in the future! It looks interesting

25

I use a 1-12V 10A power supply with a regulator - I have not noticed any power/current shortage (you can see it in the photo and video above). I burned the servo drive because of a math error - one of the rods got jammed and it overheated.

26

I assumed you may had a slight voltage drop due to too high power load in your video. But if it works good, then ignore me :smiley:

27

I’m now thinking of a coordinate system other then L0/L1/L2/R0/R1/R2

From the POV of the robot it’s entirely correct, but from the point of its user, which is a stick fixed at one end, the meaningful measures somewhat differ

  1. Bottom robot point is defined by
    1.1. A radial distance. 0 means it’s completely inside, 1 means it gonna fall off (by definition of 1 as the point where it falls off)
    1.2. Longitude and latitude. I guess 0deg will be the top and forward/clockwise (back would have more sense but forward gives better analogy with analog clocks)
  2. The direction of the robot is defined by
    2.1. The angle between the zero-input vector and the robot. You don’t want it to be of any large value for safety purposes. 0deg is straight.
    2.2. The angle between the zero-input vertical plane and the robot.
  3. Twist

image
image690×667 31.7 KB

28

Since I wrote my multi-axis scripts in Blender, I took its coordinate system as a base when developing.

image
image927×540 91.3 KB

The bottom of the holder is the main reference point:

  1. Down to the maximum is 0.0 in Z.
  2. Up to maximum is 100.0 in Z.
    Consider the 3D coursos (sphere) is where the penis grows from.

With regard to XY movements you don’t have to worry, I specifically calculated correctly so that the vector length does not exceed 100 when moving. I write the ZXY rotations (yes exactly in this order) in this way, and then I convert the obtained angles into quaternions (it is more convenient to work with them).
I will probably describe the math of the work as the first ready prototype for public use.
By the way, I checked on my robot the movement of -50 to +150 mm is normal.

1 Like
29

…well i think that’s genius, you’re incredible. My suggestion would be to give it a face, cos then it would look moar robot…

1 Like