Something I’ve discovered during recent scripting.
The pattern above is the actual script. The pattern below is an illustration of the Handy’s movement as I’ve observed.
The pale (middle) section is too slow to be performed correctly. So the FW blended them into a single upward stroke. It also offsets the top point, resulting in a much slower downward stroke.
So, when there are action too slow to be performed, it not only causes stutter but also affects its surrounding actions. When this happens it can be detrimental to the script’s precision.
Before we figure out what the bottom speed cap is, do a lot of testing before publishing your script.
I did some experiement and think this still has something to do with minimum speed. Most likely caused by the pale section in the middle which is too slow. Though I didn’t expect the FM will alter the movement in such a way that it affects the commencing downward stroke.
All three patterns has a downward stroke of 450 unit/s.
Pattern A has an upward stroke of 58 unit/s and is performed as-is.
Pattern B has an upward stroke of 90 unit/s followed by a stroke of 35 unit/s. These two strokes are combined into a single upward stroke, and the downward stroke is executed early at a drastically slower speed.
Pattern C, curiously, bypassed the optimisation and is performed as is.
I think what I learnt today is that vibrations can also be used to script slow movement that would otherwise performed incorrectly on the machine…
Some helpful documentation over the device’s specifications. Though we need to translate the speed units into OFS’s “unit/s”.
Max output speed: 400mm/s (capped in FW)
Min speed: 32mm/s (capped in FW)
According to this post it will be 363.636 units per second. But that’s way slower than my experience. Testing with this script shows it can handle up to 480 unit/s.
Sometimes with scripts, extra points like in your first pic can cause a complete stop, followed by a jerky situation/stroke after that, so I end up simplifying a lot of scripts on my own end. Using wired gigabit internet… still get a lot of unsmoothness.
Just a broader issue that I have with “detailed” scripts - they’re not smooth or comfortable to use usually.
Something like this for example is really uncomfortable to use:
Good research! We are rewriting the whole motor driver and adding predictive model regulation (MPC). The result is much more accurate script playback. I think there will still be issues when the script has high frequent motion outside the speed range (32-400mm/s theoretically and 32-350ish practically due to acceleration). Need to test more when we are closer to release. Alpha is hopefully out before summer.
I dont know the firmware version i have, but noticed that there was a case where if the movement was too slow, it might skip the next node entirely.
The start is at the 0, and the next node 30s later is at 100, and 1s after that it goes to 0 again. The handy in this case stays at 0 for 31 seconds. And this is VERY common at the start of a script.
Could this be a related issue?
(the workaround is adding another node about 2 seconds before it at the top, which if it hasnt moved yet, still means a 2s movement which is fast enough to perform - but its not neat)
Given the speed of it I think it’ll be fine (on Wi-fi mode).
On Bluetooth mode this is going to feel less fine due to the micro-stutter after each action. The node on the centre is especially unnecessary as it doesn’t represent speed changes.
For me it’s the sudden speed changed. In the last downward stroke you see the curve changing from green - red - green. This usually doesn’t feel very well.
Thank you very much for your answer. Originally, my algorithm fits the cos function for Handy and interpolates 3 points. I saw that maybe interpolating 2 points is enough. I will modify my algorithm and try it out
Now the result is like this. I don’t know if it’s Handy’s best interpolation solution
At present, I want to determine the best interpolation scheme for different device, and then I will start a post with best practice for different device
Well, I’ve come to the conclusion that it’s better not to interpolate inside scripts for best compatibility… Unless there is an obvious change in speed that you want to represent, in which case you add middle points specific to that action.
Interpolating inside the script, according to my experience:
Any Bluetooth Device → Causes Stutters
Handy on Bluetooth → Causes Stutters
Handy on Wi-fi → Generally okay, but fast actions feels abrupt and uncomfortable.
OSR over serial cable → Handles it well. However MultiFunPlayer also has a built-in interpolation.
Yes, the purpose of my interpolation is to reflect the changes in speed through mathematical functions because performing this part of the task manually is too laborious. I am aware that MultiFunPlayer has an interpolator, but it might overshoot. Additionally, complex animations require easing in and easing out, parabolic trajectories, or even Bezier curves for fitting. Clearly, MFP’s interpolator is not capable of achieving these.
If more than 5 points can be inserted, the motion will become very smooth because the speed change must be gradual, so I really want to know if Handy can handle so many points
It can (if over wi-fi), however it may not feel smooth. If you send the script I can test it out for you.
In the mean time here’s a old discussion I’ve prompted (like 1 year ago). I was obsessed with interpolation at the time (not anymore). Maybe give it a read:
