Develop your own robot

DIY
1

Hello to everyone here on this wonderful forum.

First things first. I got acquainted with VR adult movies a couple of years ago, somehow I heard a lot about it but never got to try it. Also as my hobby I sometimes mess around with mechanics and electronics and at the time I was just wondering how to use that prototype device I was making at the time. I’ve been familiar with adult films for quite some time, since the VHS era - VR movies just struck me. It was quite impressive and the idea of creating my own device to “free my hands” and synchronize the process with what I was seeing was born.
I understood that such devices were out there, everything was usually invented before us. About a month ago I found your community, some of you are creating scripts for these devices, a lot of people here have these devices, know and understand the principles of their work. Therefore, I decided to ask local forum users about some of the features of ease of use, to learn the wishes and tips before I start to translate my idea into reality.
Let’s think about what kind of device, in your opinion, would be almost ideal. In order:

  • Noise. Unfortunately none of the manufacturers do not specify parameters of noise at work and even strong vibration motors (the more linear actuators or servos) can be clearly heard through the wall.
  • Speed of operation. Here in some threads (and some manufacturers indicate too) there are mentions - up to 400 mm/sec speed and a limit on command processing (1/6 second at best) that is for example combining a fast start of movement with deceleration at the end for scenarios is problematic.
  • Stroke length. Here all is ambiguous, the models have a stroke length up to 115 mm (4.53 inches), although according to Wikipedia the average length of the penis is 14.9 cm (5.9 inches) with a standard deviation of 2.1 cm (0.8 inch). So 115 mm (4.53 inches) seems a little short.
  • Degrees of freedom. Most commercially available devices have only 1 degree of freedom - the Z-axis. The only exceptions are OSR2(+) and SR6 according to reviews, but purely mechanically considering this device as a kind of a parallel manipulator I would argue. Of course I want six degrees of freedom (forward/backward, up/down, left/right as well as yaw, pitch, roll).
  • Bracket mount. Sounds like a necessary option to me, maybe a basic must-have feature. For it is to free your hands, relax and fully immerse yourself in what is happening that these devices are needed.
  • The presence of batteries. On the one hand plus - you can not get tangled in the wires when you are in a VR-helmet, on the other hand minus - you must not forget to charge (may run out at a crucial moment), with less charge will be less speed.
  • Ease of use, turn on - run - works - pause - turn off - run from the same place - works - stop - run a new video - turn off. Without extra downloads, scripts, synchronizations, account elections with two-factor authentication and offline.
    Currently thought out my device and mathematics / logic / data transfer protocol for the device, now simulate it in 3-D editor, ready to order components as I make a rendering and be confident that with minimal alterations to create a working prototype. With you I share my thoughts and want to read criticism, suggestions, advice and just hear a different opinion. English is not my native language, I apologize in advance.
2 Likes
2

it all depends if you make it for yourself or intend to sell them to others. but im going for the last one.

in my humble opinion most important is ease of use, affordability, reliability, and being able to use different sleeves with it.

I myself prefer a powercord (it never runs out of steam and can run stronger motors, and its way better for the enviroment, as high quality rechargeable batteries are filled with very pollutant materials) (something the electric car owners tend to forget :grin:).

Speed 400mms is minimum but a bit more like 600mms would be great i think the 50ms reaction time that the handy has is short enough.

Stroke lenght of 12cm is enough (im above average but never noticed the lack of stroke length), if you make it longer your member might fall out during use, if you decide to make it longer make sure it stroke length is easily shortend.

Noise is very important the more silent the better, i always say if you put it under a bed sheet and stand outside the room with the door closed you should not hear it (depends on the kind of walls of course, in my case its stone).

Bracket mount is the least important i tend to use them when lying on my bed, most mounts are for mounting on a desk. but you could design a system where it can be held by a desk mount and a (lying) belt.

multiaxis is nice but as a commercial scripter i can tell that creating a high quality single axis script takes between 10-20 hours, creating a multiaxis one doubles or triples that time and thus is hardly done. So until scripting AI becomes a lot better. multiaxis is not that important. If you want to implement more then the up and down i would go for twist, it is easier to script than gyrating motions. also something that could increase/ decrease the grip level of the toy could be interesting as that could be easily scripted (on and off) as that would greatly increase the reality feel of a handjob. but in both cases a better scripting tool is necesary, one where we can input all the actions in one screen.

2 Likes
3

I don’t know yet, now I’m doing it for myself because it’s interesting (and probably will be nice).
Regarding the sleeves is a very good point - have not thought about it yet, I’ll add it to the header of the topic.
I don’t know what the speed will be in my device, as soon as I finish modeling, then I can check.
About the length of the stroke, it is clear that there are nuances and I think you just need to make a setting in the device that everyone was able to adjust.
Mounting thought to make simple enough, the device itself to make VESA compatible and buy a desktop mount for the monitor, attaching it to the bedside table.
image
About the multi-axis scenarios - you’re right, it’s very complicated. So far this is the plan in my head:

  • create a model by parameters similar to the actress, for example in makehuman,
  • using the time points from the regular scripts we create a 3D depth map from the VR video,
  • in the editor for time points we put the model in the right pose.
  • fix the position in space of the anatomical parts we need.
  • by interpolation we calculate the intermediate positions for the desired frequency.

Thank you for your objective opinion.

4

I’ll raise the topic a little bit.
I have not abandoned my interest in creating my own robot. I decided in the beginning to try to create it with one degree of freedom. I took the Sarrus linkage as the basis.

I designed it, printed it out, and made the mistake that the rail fixing should be rigid. In general, the work is in progress.
image

1 Like
5

As a result of a couple of weekends of work, I wrote a program in python for the PC. It connects to DeoVR, gets the name of the playing file from it, searches for a script with the same name in the folder with the script, parses the script and sends MQTT actions synchronously with the viewing.
I built a circuit with two servos, WeMos D1 mini board + Power Shield, by the way new servos arrived - the difference with the old ones is visible to the naked eye (faster and quieter).

In general, I’m moving a little bit - I will put it all together.

1 Like
6

Looks interesting. You know I always wondered if stepper motors would be quieter than servo motors, I have no idea how they are driven, and will likely be more complex. That scissor stole mechanism looks cool but I would be very worried about pinching :grimacing:

I have an osr2.1, and I just used the cheapo servos, but you are correct that the noise is the number one complaint. Even the guys with $100 servos still talk about it, surely something can be done. When I think about stepper motors I tend to think about the ones on 3D printers but I know that there are smaller ones out there. I guess maybe they might not have the speed.

1 Like
7

As for the noise, there are a few thoughts on how to do it right, I’ll try it:

  1. Noise comes from vibration and moving parts.
  2. To protect against vibrations you need to use vibration inserts.
  3. To protect against moving parts, you need to shield them with a special “acoustic material”.
  4. The noise from the gears depends strongly on the profile and the amount of lubrication.
    In the video I want to point out that the servos are on the table, so that the sound is amplified. if it will be on vibration mounts the sound will be an order of magnitude less. I think I will assemble two versions (with cheap and brushless) and measure the noise level - it would be ideal not to be heard from behind a closed door.
8

Using a stepper motor with a timing belt like used in 3d printers would be more quiet, as it has no gears. You could derive this for example from the Prusa I3 X-axis using two smooth rods and three linear ball bearings. The stepper motor requires a dedicated driver, 12 V supply an an Arduino to connect to the PC via serial to USB. Looks very feasible.

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

6 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