Hey folks. Dated a belly dancer back in the day. She could keep her vag entrance in the same spot, but rotate her torso around it. While riding up and down… is this replicatable with a sr6? I’ll attach a video, bottom of the cup being the opening to the sleeve.
I don’t have one but I do believe that’s possible.
I wasn’t sure. I’ve been cruising the forum under the multi axis tag, kinda thumbing through all the videos with motion simulators. I havent seen one yet that spirals while going up and down.
You can watch its movements on https://www.ayva-stroker-lite.io/. I think the movement you’re looking for is named vortex-tease.
Yep, even the OSR2+ can do that. Wonderful machines.
Yeah, all you would need is the OSR2 with the pitch/roll axises since all those do is tilt it left/right and tilt forward/back. So all it would have to do is activate each tilt accordingly.
Vortex tease, gotcha! Ill try searching that. Ive just been running LO scripts with the other axis linked and set to random. Kinda bored of it, need a movement for parts of the vid that don’t have script, like the steip tease. Anyone know a program that even a dumb dumb like me could figure out to try to make said script?
I’m gonna be that guy: Not entirely true, since the opening of the sleeve is below the rotational axes. Therefore you need surge and sway to compensate for that movement to truly have the opening stay at place. It will depend on the software though. I don’t know whether or not there is linear compensation for linear deviations from rotational movements.
Indeed they are.
Have you tried with OpenFunscripter - a scripting tool - 3.2.0 release ? I think OFS is always worth a try. If you want to have a circular movement, make sure roll and pitch are shifted, s.t. where one is at maximum, the other is at 50% like a sine and cosine:
Or if you want to smooth it more to look like a real sine and therefore a smoother circle:
Im going to have to give it a shot!
It is a shame that we can’t use the position signal wire to make a script.
Cause these servos know what position they are in, right?
Seems like moving the sleeve case by hand and recording the servo positon would be a thing.
Nice! Good luck. And of course just ask, if there’s anything that’s unclear.
Exactly! A servo normally has a potentiometer, with which it does feedback control internally. The position signal wire is only an input though. The position is not output afaik. Maybe there is a servo somewhere with a serial interface or something like that, which could output the position… 
Or maybe we should just build an OSR2/SR6 and replace all servos with only readable potentiometers. The only thing I’m worried about with any such input devices, is that it’s too imprecise (both timing as well as position), so it would necessitate post-editing which will probably be a complete re-script.
Hey I have wondered about this for years. The abosolute zero position around which the SR6 and OSR 2 rotate around is in the very center of the reciever ring. Therefore, the toy’s opening is out “in front” of this point by whatever amount the toy sticks out past the ring. It seems to me there should be a firmware solution that could compensate for this distance and put the rotational zero point out in front of the ring so that the toy’s opening could truely be the orbit point. That could make some movements with some toys work much better. Some BJ toys could really benefit from having the orbit point be right at the mouth opening. How can we make this dream a reality?
Yes, that’s correct. I haven’t looked at how exactly the SR6 does it, but the OSR2+ would basically move the entry on an orbital path when only moving roll and pitch. This can also “lengthen” the distance, which means, that slipping-out can occur, which is usually counter-acted by shortening L0 and using smart limits to limit pitch/roll at the tip 
.
Just by the kinematics, it is not possible with the OSR2+. The best you can do there, is to shorten the stroke axis depending on pitch&roll (and maybe their speeds), s.t. if the L0 says 80%, then the resulting contact will be at 80% and not 90% despite roll/pitch. I’ve done that in the L0-script itself for my recent multi-axis scripts, which means, more script versions until the software can handle that.
I’ve asked @Yoooi before and with the plugin function of the newer Patreon-Release of MFP, something like this can be implemented, such that the original script can be used without sacrificing too much pitch/roll at the top or total range on L0 (at the sensitive tip).
With the SR6 and the two added linear axes, it should theoretically be easy to compensate the linear deviations caused by the angles, but I haven’t yet looked at the firmware to see, whether that’s the case or not.
Word!
I’ll have to think about where the best place is to do this. So here goes:
If we do this on a firmware level, at least for the OSR2, the exact correction values would depend on the defined range. And this and other parameters are usually defined on the player level (like MFP - think axes’ ranges) and not the firmware. So I think that the player would be the appropriate place.
For the SR6, to get the same effect of not overextending the length when the surge/sway axes aren’t in the middle, the same holds true. And even if we only correct for the pitch/roll, then it would still need a user parameter, namely how much the toy’s entry protrudes from the plane of the receiver (i.e. the radius of the sphere). Which can also vary with the specific toy. And then also a safety margin, depending on the toy/penis geometry and personal preference(so the sphere becomes an ellipsoid).
So again, I think the player is the best place to do that. If there was a compensation in the firmware already, it would be slightly imprecise, because these parameters have to be fixed at some arbitrary value. But then on a player level we could still account for that and correct it.
In short: I think we’ll have to write a plugin for the Patreon release of MFP. Or kindly ask @Yoooi and @Khrull to incorporate this natively in their players
Maybe we’re thinking about this all wrong. Maybe the receiver ring should be redesigned to have the axes attach points physically lower down or even have some sort of manual adjustment using screws or bolts or something that could allow the ring to be repositioned up a little higher.
Isn’t the plugin as simple as copying R1 position to L2 and R2 position to L1? The strength/height would then be adjusted with L1/L2 range sliders in output.
Also the plugin wont work with a script on L1/L2, that would require internal MFP changes. You could I guess detect script changes for L1/L2 and adjust the scripts to correct for R1/R2 scripts. But this wont work with L1/L2 scripts while R1/R2 is using motion provider.
This could be implemented in 3 ways, in firmware, in software, in hardware.
Each has different pros and cons.
Is this even something that would be noticeable?
I don’t know if it would be noticeable, but I would certainly be very sensitive to any changes. In some scenarios with pitch and roll movement and some toys, I think you could improve the toy alignment and the resulting sensations. I guess what got me thinking about it was when I was playing in VAM and I noticed that in debug mode, I can see the wire frame that shows exactly where the movement is being calculated from, and I noticed that the cylinder that represents the girls orifice whether it’s her mouth or her vagina is exactly at the opening, but the toy in real life is actually protruding out beyond that calculated point of contact, so I just wondered if maybe it would be an improvement to have that point of contact in the game be more accurately represented in real life.
Thank you for joining the discussion. Always good to have the actual developer chime in.
If we were to do it correctly, it’s a function of f(L0,L1,L2,R1,R2, parameters) → L0, L1, L2. The best way to think of it is: If a single axis script is at 100%, then no matter what L1,L2,R1,R2 are doing, the contact point at the irl penis should be at 100% (and not 114% → slip out). I would probably derate the corrections with L0 < 50% (to be defined) since at 0% the correction is not possible or sensible.
For Firmware vs. Software, I’ve already laid out my main arguments. Since there are individual, day- and sleeve-dependent parameters, the more logical solution would be in software. Additionally, although the EEPROM should take a few cycles, I’m not a fan of re-flashing every time.
Hardware changes would introduce new receiver mechanics (doable, but everyone who wants the functionality will need new parts) with new points of failure, added weight to the moving mass, and also have the following issue:
The most lowest position would be pretty painful for the user, if it makes contact, since there has to be some hard plastic or a screw or something in the same plane as the entry of the sleeve. That the toy protrudes a bit like today does have the upside, that it’s the sleeve making contact first while keeping the plastic away from the user. (Think of grinding motions getting literal). If we put a cushion on it, then the sleeve entry does not reach the bottom, if so configured.
The theoretical argument: Yes, since there can be more bandwidth around the sensitive tip of the penis without using smart limits as of today and/or large safety margins and still be safe. Both in that the contact and pressure points can be more varied due to the additional axes being able to fully engage at the very tip. As well as with L0 still reaching the tip, if everything else is centered. And lastly, if someone wants to fully experience the memory of his belly dancer ex, this makes it possible 
Anecdotal Argument: I have tried a fourth option in the meantime: An extension in OFS to stunt L0 depending on the other axes, deactivating Smart Limits and minimizing the safety margin. I can personally say, that it makes a huge difference even with only an OSR2+Twist, although I have not yet heard back from anyone else trying it.(It is quite risky trying that for the first time with a full script, since the appropriate safety margin will hinge on the individual mechanical setup and its stiffness)
I think before we go at any other implementation, the fourth option is a quick and dirty way (that necessitates more script versions) to get feedback from. I will probably release the extension soon - I just jumbled up something to try for myself and want to include more functionalities - and hope to get some feedback from more users. This way the question of how noticeable/useful this is, can be answered with more statistical weight to it.
I did some tests and there is not enough range in L1/L2 for it to depend on L0. I’m assuming you want the stroke to work at an angle not just vertically up and down, but that requires more L1/L2 range.
Doing a simple correction based on R1/R2 at full L1/L2 range lowers the orbit center around 2-3cm when L0 is at idle position (first part is without, second part is with correction):
(R1, L1, L2 range 0-100%, R2 range 8-92%)
public class Plugin : PluginBase
{
protected override void OnInitialize()
{
var l1 = DeviceAxis.Parse("L1");
var l2 = DeviceAxis.Parse("L2");
var r1 = DeviceAxis.Parse("R1");
var r2 = DeviceAxis.Parse("R2");
var strength = 1;
var intervalMs = 3;
StartThread((token) => FixedUpdate(() => !token.IsCancellationRequested, (values, elapsed) =>
{
var r1Value = ReadProperty<double>("Axis::Value", r1);
var r2Value = ReadProperty<double>("Axis::Value", r2);
InvokeAction("Axis::Value::Set", l1, r2Value * strength, intervalMs / 1000.0, invokeDirectly: true);
InvokeAction("Axis::Value::Set", l2, (1 - r1Value) * strength, intervalMs / 1000.0, invokeDirectly: true);
}, intervalMs, true));
}
}
I was thinking about having a parameter in the web ui, so no need to reflash.
Firmware is the one doing the kinematics so it knows the physical dimensions, MFP only operates on 0-100% values.
IMO another problem is that at least my SR6 unit is way too sloppy/loose for this to have any effect. It would have to be way stiffer.
Oh wow. Thank you for doing testing already. It clears a few questions I had.
I fear, my ramblings were a bit unstructured and we are actually talking about multiple things. Although they are connected, they are not the same:
Furthermore, from your animation I take it, that the SR6 does not do any corrections either, but each script axis is just a linear translation of that specific script without cross-dependencies.
It is to be expected, that there will be limitations to what can be compensated at the axes’ limits.
But I must admit, that I didn’t do numerical calculations, just analytical, so here goes:
Looking up the numbers for an SR6, both angles have a max. range of ±30° and both surge and sway have a range of ±30mm. That means that if the sleeve entry protrudes 60mm from the rotational axis (where the main arms are mounted to the receiver) then you would need the full L1/L2 range to correct full R1/R2 amplitude, as you’ve stated. I’ve measured my fleshlight sleeves and they are all around that range (maybe a bit shorter where the actual grip is).
This means that if someone wants to script that specific movement:
In light of that, I’m beginning to think like you, that compensations affecting L1/L2 should not be done automatically, but that the scripter has to intentionally script it that way. If anything, we can write extensions in OFS to help with a catalog of functions to make different kinds of compensations and patterns.
The downside of course becomes that the playthrough will be sleeve dependent and the difference in protrusion can only be corrected mechanically. So if @2oferagon is still reading, sorry mate 
This to me seems more critical because of both the safety implications and improved detail at the tip.
Using the full ranges of the devices, fixing the bottom base point and assuming a linear full translation from the input, the stroke length can reach:
(EDIT: I had speed dependent components in the calculation initially with extreme speeds. Have corrected the values)
(If the kinematics on AyvaStrokerLite are correct, then for an SR6 a change in pitch alone, only affects the top two servosl, so I used the same equations for both devices).
To counteract that, in MFP there’s the Smart Limits, but they only work from L0 → R1/R2/L1/L2. This means that at the tip (if set up at center, at the very top), there can’t be any angles or surge/sway. Which means that if one takes an existing L0 script, it is not possible to just add stuff to it and it actually translating. Additionally there’s the possibility to set up the device lower, which takes away dynamic range at the most sensitive part of the penis, but allows for some deviations with a different SmartLimits setup. (Without Smart Limits: >=26 mm lower than tip, if full R1/R2/L1/L2 ranges are used somewhere in the script)
What I am proposing is the exact opposite direction. If there are deviations in R1/R2/L1/L2, then L0 must be stunted, as to avoid slipping out, while allowing for angles and off-center positions at where there is the most sensitivity. This also has the added effect, that (within limits) the contact point on the penis stays the same as intended in the original script, without changing the original script.
The downside here is that the actual possible range is limited to the nominal max. stroke range of the device, which can mean the lower position is not in contact with the body (which can be the case anyway). So there is a priority judgement from the user, on what to use and how to set up.
To summarize the options:
My Proposal: More variation at the tip, limited to nominal max. range
Safety Margin: More total range with possible contact at base, but far from the tip if not at (full) angle/deviation.
Smart Limits: Reaching the tip only without angles/deviations, limited to nominal max. range
Of course there can be a mix of the second and third options, but is a bit difficult to set up correctly.
How it is now, the firmware uses the geometry to get specific motor movements, so the axes are isolated. I.e. a roll is only roll, but needs four motors to move in a specific way depending on the geometry.
Bingo! In my OFS extension I got an additional “safety” parameter that reflects that issue and should be set individually, depending on the stiffness of the total mechanical setup, sleeve/penis shape, etc.
Personally to get maximum impact, I have tried to make everything as sturdy as possible, especially the clamping mechanism. And of course it is always advisable to check if all the screws are tightened.
Yeah still reading friend.
@Yoooi I like that animation you posted above. The code underneath that animation, i believe it said “plug in” and I believe ive seen “plug in” on mfp app. Can that be copied into MFP for scientific purposes? 
Save it to a text file in the “Plugins” folder, change the extensions from .txt to .cs and the plugin will be loaded automatically. Depending on which version of MFP you are using it might not work.