Help in understanding multi-axis scripts

I am familiar with mathematics, know how aircraft angles differ from Euler and know how to use quaternions and dual quaternions. So let’s skip the math part.

I want to try to write a 6-axis script, but my math knowledge is a little out of sync with what I see. How does the program then process these files (JSON)? Why do I need so many of them (every topic with multi-axis scripts has 3 to 5 of them)?
If with the normal script everything is clear - the movement on one axis and we specify the position and time, then in my opinion for multi-axis scripts there should be only 3 files (or maybe even two) - the normal script, the script of position in three-dimensional space (like a vector) associated with the first (by timestamps), and the 3rd separate one with rotations in space with its timestamps.

I don’t want to make scripts like a monkey, I want to understand the basic principles of the movements I’m trying to describe in the script.

If I’m not wrong you have the following (unsure of the name of each axis):
standard axis for up/down, i.e. the axis all normal strokers use
pitch, axis for how the sleeve lean left or right,
roll, axis for how the sleeve lean forward or backward,
twist, axis for how the sleeve is rotated
sway, axis for how far the sleeve is from you (typically to script grinding)
surge, axis for how the sleeve moves left or right

So basically, 3 axis for movement and 3 for rotation.

Have a look at the protocol documentation for a picture:

1 Like

Thanks for the link to the documentation on the protocol used by OSR2/SR6.
But my question is a bit different. Since I’m thinking about developing my own robot - I’m looking for correct mathematical methods for it, which will be compatible with existing similar multi-axis devices. My choice is a movement vector with timestamps + rotations (quaternion) in space with its own separate timestamps which can be combined into one JSON. To translate this script into a regular or multi-axis one, a separate transfer utility would be sufficient, or the developers could add the ability to read the original files. I want to do it right and well in scripts.
Which point in space is the origin of the coordinate system for OSR2/SR6?

i dont think it has a origin perse , it simply tells the servos to have a specific voltage. Its probably best to ask at tempests discord since its T code based

Am I correct in assuming that a multi-axis device other than the SR6 simply does not exist?

1 Like

You can download the SR6 software here (no registration required): https://www.patreon.com/posts/march-update-63230196. The relevant code is this:

  // SR6 Kinematics
  else {
    // Calculate arm angles
    int roll,pitch,fwd,thrust,side;
    int out1,out2,out3,out4,out5,out6;
    roll = map(yRot,0,9999,-3000,3000);
    pitch = map(zRot,0,9999,-2500,2500);
    fwd = map(yLin,0,9999,-3000,3000);
    thrust = map(xLin,0,9999,-6000,6000);
    side = map(zLin,0,9999,-3000,3000);
    // Main arms
    out1 = SetMainServo(16248 - fwd, 1500 + thrust + roll); // Lower left servo
    out2 = SetMainServo(16248 - fwd, 1500 - thrust - roll); // Upper left servo
    out5 = SetMainServo(16248 - fwd, 1500 - thrust + roll); // Upper right servo
    out6 = SetMainServo(16248 - fwd, 1500 + thrust - roll); // Lower right servo
    // Pitchers
    out3 = SetPitchServo(16248 - fwd, 4500 - thrust,  side - 1.5*roll, -pitch);
    out4 = SetPitchServo(16248 - fwd, 4500 - thrust, -side + 1.5*roll, -pitch);
    // Set Servos
    ledcWrite(LowerLeftServo_PWM, map(LowerLeftServo_ZERO - out1,0,MainServo_Int,0,65535));
    ledcWrite(UpperLeftServo_PWM, map(UpperLeftServo_ZERO + out2,0,MainServo_Int,0,65535));
    ledcWrite(LeftPitchServo_PWM, map(constrain(LeftPitchServo_ZERO - out3,LeftPitchServo_ZERO-600,LeftPitchServo_ZERO+1000),0,PitchServo_Int,0,65535));
    ledcWrite(RightPitchServo_PWM, map(constrain(RightPitchServo_ZERO + out4,RightPitchServo_ZERO-1000,RightPitchServo_ZERO+600),0,PitchServo_Int,0,65535));
    ledcWrite(UpperRightServo_PWM, map(UpperRightServo_ZERO - out5,0,MainServo_Int,0,65535));
    ledcWrite(LowerRightServo_PWM, map(LowerRightServo_ZERO + out6,0,MainServo_Int,0,65535));
  }

As far as I can tell there is no proper inverse kinematics and no proper origin. It just rotates/moves, approximately in the right direction. If only L0 (thrust) is modified, it doesn’t even move in a straight line.

I have an SR6 clone with proper inverse kinematics that rotates around a specific origin, but I haven’t settled on any specific origin (needs more testing).

Funscripts use separate files for each axis. This is slightly annoying but it’s not a problem. What is a problem is that the order of rotations and the origin are undefined.

1 Like

Well, you can calculate the origin point from the script - it has one Z-axis. Whether it is necessary to use inverse kinematics for calculation is a question for me, I think forward kinematics will be enough.
Inverse kinematics will be needed when we need not only to move around the point, but also to position to it.

We have the following:

  1. Having 6 scripts for multi-axis movements is complicated and redundant.
  2. Those that are multi-axis devices do not calculate the kinematics of the movements.
  3. Using quaternions + vectors in scripts will solve several problems (interpolation, lack of articulation lock, speed of calculations, and brevity of writing).
  4. Since we are the first to be able to choose the vector of development :wink:

Wishes, comments and advice are welcome.

Inverse kinematics are necessary in the motor controller to calculate the motor angle that results in the desired tool (fleshlight/vibrator/dildo) positioning. If you’re working on the scripting side, maybe it’s not important. It depends on how the scripting interface works.

I think you have good ideas. The first order of business should be to define a spec for positioning one (or more?) objects in space. I’m not sure how we should do this, for some tools (fleshlights) it seems natural to place the origin of rotation at the entrance. For dildos it’s the opposite.

Upon closer inspection, I don’t think quaternions solve any actual problems. Whether you use quaternions or angles, 6dof is 6dof. You can use every interpolation method you want regardless of the format in the funscript. No devices currently on the market have full 360 degree rotation in all 3 axis and I doubt we ever get one, so you can always choose you axis definition in such a way that articulation lock will never occur. Speed and brevity… really don’t matter. We’re controlling a toy, not a game engine.

yep as a robotician i was surprise by the simplicity of the code but apparently simple addition do the job.
no one need a toy be precise at 0.1mm
but i join you that inverted kinematic can change the linearity of the speed (and change some feelings)
maybe one day i will build one SR6 to see how much difference there is with th handy.
(and yeah play a bit with the code)

That’s why I started with writing my scripts on one axis - everything is clear there.
Now I’m a bit stuck on modeling and printing, my printer is bad - the area is only 100x100x100 mm. To create a 6 axis robot and need to understand a lot of axis scripts - but as it turns out everything there is new, no one has dived deep into the topic. I’m looking at the Stewart platform and positioning control via quaternions + vector.

as i know this type of structure is mainly used to be higly precise but not really fast and it need space for little movement.
But in the same spirit is the delta robot work pretty much the same way.
i don’t have checked it exist some example like :

The platform is the only mechanism with a minimum of motors and a maximum of degrees of freedom. If you use linear actuators, it will be slow. If servo actuators, similar to SR6, it will be fast.

The Stewart platform is an example of a parallel mechanism with 6 degrees of freedom, but there are infinitely many of such parallel mechanisms. There are also infinitely many serial systems with 6 degrees of freedom. For example, you can remove one of the motors from the stewart platform and connect the missing link to one of the remaining motors (so there is one motor with 2 links attached). If you then mount the entire thing on a linear rail, you still have 6 degrees of freedom with 6 motors.

Also, the sr6 doesn’t actually implement 6 degrees of freedom with 6 servo’s, it uses a 7th servo to operate the twist axis because the particular servo arrangement it uses results in barely any freedom in twist axis.

I’m working on a design with one powerful linear rail and 5 cheap servo’s to obtain 6dof. The advantage of such a design is that the cost goes way down because you no longer need 6x€80 servo’s, you need 1x€100 motor and 5x €20 servo’s. The disadvantage is that the mechanical design is hard.

1 Like

Topic updates.
Tried using Blender as a software for writing 6-axis scripts.
It worked really well.
ezgif.com-gif-maker (3)

I’ll have to try and figure out exporting moves/rotations to script files later.

Blender works great.
ezgif.com-gif-maker (4)

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.