Why does the SR6 twitch when playing high-frequency scripts?

Help
1

The script is probably high-frequency. The OSR3 is a product purchased from a seller and runs stably. The SR6 was assembled by me, using two 25kg servos and five 45kg servos. It works normally when playing scripts that are not too frequent, but once the movements become slightly more frequent, twitching easily occurs. What should I do?

I asked GPT, and it suggested that the possible causes could be that the OSR6 PID/firmware parameters are not suitable for high-speed direction changes, or that the Bluetooth queue is accumulating, etc.

For the firmware versions flashed on this ESP32, I found TcodeEsp32 and SR-Control online and tested both. With the former, after flashing the firmware and connecting the device through MultiFunPlayer, only the left servo of the L0 axis responds and can move up and down. The right servo, as well as multiple axes such as L1 and R2, do not respond. With the latter, none of the servos respond at all.

Then I installed the third-party firmware provided by the seller’s website. After flashing it, all seven servos of the SR6 responded and the device operated normally. If I only play scripts that are not very high-frequency, the machine runs normally. However, when the script frequency is increased slightly, the twitching problem appears, as shown in the video.

OSR3+OSR6 Video: Transfer.it

OSR3.MP4: The device is a commercially sold product from a seller.

OSR6.MP4: The device was assembled by me.

MMD R-18妖精大戦争.funscript (92.2 KB)

How can I solve this problem? If it really cannot be fixed, I may have no choice but to purchase the OSR6 device sold by the manufacturer. Personally assembling an OSR6 has some serious flaws…

2

Ignore those high-frequency scripts. Normally, 600 units/s is the limit for the SR6 (it depends on your servo response time, measured in ?s / 60 degrees — it could be higher or lower). Personally, I suggest you don’t play any scripts with a max speed over 600 units/s, and the average speed should be kept even lower. High-speed scripts usually taste like shit. Even on the Handy 2, which can reach 900 units/s, it still tastes like shit.
The advantage of the SR6 lies in the immersion brought by multi-axis rotation that matches the video, as well as the more delicate sensation from the lateral pressure generated during slow-motion movements. Excessively high speeds will ruin everything. Only for individual shots that require impact force will some quick impact actions be performed, reaching speeds of up to 600.

3

Servo response?

I asked the OSR6 servo seller about the servo response speed. It is 0.13s/60°, which converts to 461 degrees per second. The seller said that if it exceeds 461°/s, it will only move one degree per second.

If I had known this earlier, I would have chosen a servo with a higher response rate. It might have solved the problem of frequent high-frequency twitching…

Is there any way to reduce the frequency of high-frequency scripts? I don’t have much experience with OFS, but I could also write a Python script to batch re-edit the funscripts. The key question is: what should the interval between “at” and “pos” be set to so that the frequency stays just below the limit of 460°/s?

4

That’ll depend heavily on your update rate, which depends heavily on your connection type.

If you can use serial plugged directly into the mobo that’s the best you’ll likely be able to get from the device. You can even play around with Baud rate to try and min-max performance out of it. But ultimately, if the interval rate is still jittery with serial connection then no other connection type will do it either.

I’ve never used SR6 with BT or WiFi but I know the Handy performed better for me with detailed scripts over wifi. If you can’t connect serial maybe try that out instead.

I wouldn’t, that’s a good way to jack up scripts. It’d be far to easy for an AI to write a script that “fixes” all points within a set interval but actually ends up introducing a slew of other issues in place of it. And if you try batch running it on a library you might not even find out you have hidden dick destroyers until weeks later when you boot up a random video.

I’ve seen other threads that say 50ms is a good limit between points, but if i’m being honest it’s not something i’ve really dived into heavily with testing to say that you should follow that.

5

Okay, you’re right. I won’t modify the script anymore. I’ll just use the high-servo-response OSR3 device instead…

I’m connected via a serial port. I just tested it: in Device Manager → COMX → Properties → Port Settings → Baud Rate, I changed it to the lowest value, from 9600 to 75, but there was no change at all. The twitching phenomenon still occurs.

6

The servo’s response time of 0.13s/60° is likely the limiting factor for high-frequency scripts. Haptiq.app can help by editing the script to reduce speed peaks while maintaining overall intensity through its timeline editor.

7

Baud rate is the speed at which data transfers from one end to the other. Lowering it to 75 would only decrease performance, significantly decrease it at that. Try 19200, 38400, 57600 etc. to see if it helps your issue. It might not even be Baud rate is the limiting factor, I only said experiment with it just to see if it helps, since changing baud rate is free and the easiest thing you can do.

8

Changing baud rate does nothing, the app specifies baud rate on connection. Even if you managed to change it the device expects it to be 115200 or it wont be able to read commands.

For me that looks like PSU issue. What PSU do you use? (voltage/amps/model)

Also the reason other firmwares didnt work was probably only due to different pin numbers specified in config for each servo.

9

I modified the TCodeESP32 source code and successfully got it running. Currently, I am using Codex to try to add a rated servo speed setting to the firmware. For example, if the detected script command frequency is greater than or equal to the servo’s rated speed, the firmware would reject the command for that axis.

However, after flashing the ESP32 firmware multiple times and repeatedly unplugging and reconnecting the servo power adapter during the process, I now have a problem: whenever I connect power to the servo, it starts twitching continuously. It no longer moves according to the funscript, and the twitching does not stop at all. I have no idea what happened. It seems like the servo may have failed.

Even after flashing the third-party firmware provided by the seller, it still didn’t help. The servo continues to twitch constantly. This is a disaster — I’m afraid I may have damaged the servo. Now I may have to purchase the complete SR6 device sold by the seller.