Right. It wont be that hard I know how to approach this. I just have to get the free time and hardware to make it a reality.
For now you get proper depth sensing and 1 axis stroker control.
1 Like
Don’t waste your time - it is impossible to achieve perfect Z rotation with IMU, I once broke my head trying to remove deviation in the vertical axis.
You can’t do it without optics - that’s why I use HTC Vive controller to write multi-axis scripts. And the PS Move I bought with cameras is sitting on the shelf.
2 Likes
@flowerstrample Out of curiosity, do you know if it’s possible to map a standard Xbox/PlayStation controller to achieve the same thing with the sticks? Just looking for a simpler multi-axis solution.
A quest 2 controller would also work in my particular case. I just don’t really want to buy a vive controller for it lol.
I started out with a simple gamepad.
Now for complex scenes de need several passes I use Access controller
If interested and in demand, I can try to recreate the process of writing a multi-axis script with PS Move and PS eye camera.
But it’s a very heady setup with the help of several intermediate programs.
1 Like
That looks fucking amazing! I don’t want to hijack this post any more than I already have, but I’d love some guidance as to how to replicate that setup. Please message me if you are willing to explain 
1 Like
You guys can post here. I have the same questions and interests.
Flowers - I think a 9-axis BNO085 should be able to maintain yaw/ Z axis stability for long enough to record a scene or do a control session. Also, do you know of a way to record live video and scripts at the same time?
I am also interested in creating a device that a model could wear for multi axis live control like a more complex version of my fleshlight demo above. The model would be like the fleshlight in my gifs above. (I’m not calling women fleshlight.)
This can already work for models like I mentioned before. You just need to stick it to something and move in front of it. I’m just not going to record a demo of my ass in front of the sensor.
1 Like
1 Like
I never tried Bosch sensors, rumor has it they are less accurate than TDK’s and more expensive.
I used MPU-9250 in my old project, also tried ICM-20948 - they have almost the same characteristics. But the first one is being discontinued, the second one is not recommended for designing new devices 
There are 13 sensors with batteries in the video.
There was even a board developed, I stayed on real world movements (positioning by RSSI + accelerometer). There are about 30 sensors lying on the shelf now
Theoretically, if there are no very fast rotations, the data from DMP (special co-processor in sensors) is quite stable.
You can use the same Blender to record scripts and videos (it’s pretty easy to capture serial/mqtt etc. data in it), then just export to familiar funscripts
1 Like
Amazing!
If you are interested I would love for you to help me test this and make it better for scripting. Im not an experienced scripter, and the people I have helping me test now are also more interested in the gaming and live control aspects.
1 Like
I’ve never turned anyone down for help - reach out. Maybe your project will grow out of childhood, and your experience and skills will stay with you forever.
1 Like
Almost done. It can be made waterproof.
♤NO WARRANTY 
2 Likes
Posted to github. The first version is just the universal UI slider dragging mouse mode. I’ll see if people figure that out first. I have more modes that i am testing and making.
1 Like
Sorry if it was explained already… have you already implemented xtoys support? I guess it would be as a custom toy via HTTP post? Altough I am not sure if it’s fast enough for all the position updates.
1 Like
In the firmware I released XToys support is done through the mouse mode that drags UI sliders. It works in the X and Y axis so you can control all of the XToys sliders. This is done over wired USB and mouse position changes can be sent every time there is a new sensor reading (every 20 ms if the target is moving and the sensor reading is valid). In my testing I found that this also moves the toys smoother than some of the other methods.
The only bad thing about this slider hack is that you cant use your mouse while doing this, you have to re-grab the slider when you want to go back to using it. It isnt that big of a deal for how easy and universal this control method is, but I understand it is not ideal.
The best and fastest way of implementing XToys support that I have developed is using serial commands. I held back on releasing this because you need to create a custom toy to take in the serial messages. Then you need to create a script to link that toy to a generic output and pair your other toy to that. It works very well. Speed isnt an issue. I actually have to throttle back the speed that I send commands because toys cant handle the number of commands I can send. With this method there is no unnecessary complexity of extra web servers and all of that too.
If you build one I can add that mode and write up how to make the XToys custom toys if you want. I have lots of stuff that I have developed and tested. I wanted to release a simple version at first because this can get confusing for a new user.
Gotcha. Serial is also a nice idea. It needs a wired connection between the machine runs xtoys and the device if I am right?
Right now it is only over wired USB. I have bluetooth developed for the mouse mode. For that you would need an external battery for this controller. You can wire a lipo one in, use a usb powerbank, or wait for me to swtch to another controller board (In progress).
There are ways to do other things like you mentioned with web based approaches but those need custom XToys toys and scripts too (plus I would need to write the code and UI for WIFI).
If you want to use MQTT you need all of that plus run and configure a MQTT server.
I will add the keyboard mode from my ID-01 project and serial comm. I am looking at adding gamepad modes but those require software which can turn that into something useful.
Everything has tradeoffs and is a balance of how I want to scope the project. The develoent plan for this project is to switch over to an M5 controller with an internal battery which will make the project more accessible to people and add more control modes.
The great thing is the C.A.T sensor itself can be used in anyones project if they want to develop their own software. I consider that its own project. It is a way to make an affordable durable ToF sensor from readily available parts. There aren’t many (or any) options to buy a waterproof ToF sensor with the capabilities of the VL53L1X and the C.A.T. Some of the other ToF based devices only have 200 mm of sensing range because they chose an old sensor. The C.A.T can be used like the bj trainers plus anything else you can imagine because of the way I designed the sensor as a remote component from the controller.
I’m just one person who does this for fun. Unless people make one and are interested in me adding things it is just me making something for myself. I am interested in hearing what people want. So if you have ideas or things you want in a project I am happy to hear them 
Hey,
I’m still working on this. I got it ported to the M5 StickC Plus2, and worked on some new designs for sensor modules. I’m finishing testing some new modes and will add them to the firmware soon.
4 Likes
If I understand correctly, this device can only measure 1d distance, right? Is it possible to map 3d? If you can map 5-6 axis at the same time, I think the process of creating multi-axis scripts will be dramatically easier. One creator told me he spent 70 hrs for a script. That’s the best use case I can think of for this device.
1 Like
It is very useful right now if you want to control 1 axis of a machine. You can use it to remotely move an OSSM/ Handy in real-time, record 1 axis scripts on the fly, and other things. The only multiaxis toys that I know of are the strokers from Tempest. However, I am going to add the IMU to this once I finish some other things that I am more interested in at the moment.
Except the recording must be done at the source, and i dont think a lot of porn creators will realy care. If you record someone using a fleshlight that tries to mimic it, its barely going to do anything as following movement is hard. Even if done in slow motion, a lot of mistakes will be made.
And that is already relying on it working perfectly. Something that experience says rarely happens. You are going to spend a lot of time clearing out noise from the scripts.
You might as well just try to record 1 axis at a time instead and then clear that info. Being just 1 axis should make that part easier to do causing less errors in the result.