Requirements for a dildonics protocol

This is the place for all suggestions, releases and feedback regarding Milovana Hardware efforts.
Post Reply
Jabber
Explorer
Explorer
Posts: 32
Joined: Fri Jun 20, 2008 9:07 pm

Requirements for a dildonics protocol

Post by Jabber »

I'm thinking about the requirements for a protocol between the PC and a dildonics controller, as I would like to design one. We need this protocol (and of course a free reference implementation) at an early stage, so we can easily integrate experimental input- and output-devices with software for controlling outputs and analyzing input data.

So I am calling on you, as your ideas could provide valuable input to this process.

IMHO, these requrements are needed:
- The protocol has to be simple. Looking at past attempts to protocols at IETF, the simple protocols tend to win.
- We have to realize that the external (to the PC) dildonics controller has limited capabilities. Because of this we should limit the work the dildonics controller has to do.
- We need to make it possible for the PC to control various outputs, like vibrators.
- We need to make it possible for the PC to get readings on various inputs, like penile plethysmographs, rectal pressure sensors and other input devices. For these devices we often need a high sample rate, as postprocessing this data on the PC is key to the optimal use of this data.

So I am thinking about (and half way implementing) a simple protocol with these properties:
- It is a simple command-response protocol, except for asynchronous messages from device inputs.
- Inputs can buffer readings on the controller and send these asynchronous to the PC.

My idea is to design the protocol and a reference implementation on a PC and an Arduino, so we have a framework we can use for future development. With this framework, and the right PC-side analysis software, new inputs like seraph0x's penile plethysmograph and my rectal pressure sensor can easily be integrated into any software someone writes for this framework for analysis and/or feedback to outputs for arousal and orgasm control. Any software I write for this will be free software.

But I would really like some input from you, as I know many of you have thoughts about this. Even if you have not thought about this, please spend a few minutes thinking about it, and let us know your thoughts. We can easily filter out bad ideas, but I am certain that some of you have some really good ideas that I have not thought about.
blondetaurus
Explorer
Explorer
Posts: 7
Joined: Mon Jun 16, 2008 11:14 pm

Re: Requirements for a dildonics protocol

Post by blondetaurus »

Im not quite sure what you want from us? Can you lose the jargon and use laymens terms?
Jabber
Explorer
Explorer
Posts: 32
Joined: Fri Jun 20, 2008 9:07 pm

Re: Requirements for a dildonics protocol

Post by Jabber »

blondetaurus wrote:Im not quite sure what you want from us? Can you lose the jargon and use laymens terms?
Well, I am not sure if I can lose the jargon.

But what I am asking is what you think would best for a protocol between a PC and a dildonics controller (a hardware device interrfacing the human) to obtain the maximal amount of sexual frustration, or whatever you might like sexually.
blondetaurus
Explorer
Explorer
Posts: 7
Joined: Mon Jun 16, 2008 11:14 pm

Re: Requirements for a dildonics protocol

Post by blondetaurus »

What is a protocol?
Jabber
Explorer
Explorer
Posts: 32
Joined: Fri Jun 20, 2008 9:07 pm

Re: Requirements for a dildonics protocol

Post by Jabber »

blondetaurus wrote:What is a protocol?
A protocol is an agreement of two parties (here a PC and a dildonics controller) on how to communicate. For more info, see http://en.wikipedia.org/wiki/Protocol
miss_tina
Curious Newbie
Curious Newbie
Posts: 1
Joined: Wed May 13, 2009 4:59 am

Re: Requirements for a dildonics protocol

Post by miss_tina »

Here you go, a bit of a brain dump from my twisted mind:

I'm imaging at least 3 types of devices (I added one from your input/output) and a few of the ideas for examples that came to my mind (or you mentioned):
1) Sensors, for example:
- body temp thermometer (internal or external)
- moisture detection (skin, vaginal, urine/precum/ejactulation detection)
- motion sensor
- vaginal/anal contraction sensor
- pulse rate sensor
- erection sensor
- breathing rate sensor
2) Toys
a) pleasure/fun : all the obvious one :-)
b) pain/discomfort (probably limited by safety, but could have a few things):
- mild heat/cold
- light shock
- release valve on something unpleasant (ice cold water for example)
3) Locks - electronically controlled locking cuffs, etc

Some commands that I think would be needed for the PC to send to the controller:
- command to query for available devices
(controller then reports each available device and some kind of info on type of device (sensor or toy, etc) available options (vibrate, motion, etc), and where device is located)
- command to 'subscribe' to a sensor - will then get reports on some interval
- command to 'set a watch' on a sensor - will then get a report only if some threshold (if it was measuring body temp for example, then it reports nothing unless temp goes outside the watched ranged)
- commands to turn on / off toys
- commands to lock/unlock locks
- commands to set levels or activate features on toys (what was possible would need to have been reported)
- each of the commands would need some sort of deactivate command also
- probably some sort of deactivate all command would be needed

You might get some sequence of commands like:
PC: DEVICELIST
CONTROLLER:
5 DEVICES
1 TOY VAGINAL VIBRATE 1-5 ROTATE 1-4
2 TOY CLITORAL VIBRATE 1-5
3 TOY RECTAL SHOCK 1-3
4 SENSOR TEMPERATURE VAGINAL
5 SENSOR MOISTURE VAGINAL
PC: SUBSCRIBE 4
every 5 seconds controller responds something like:
4 TEMPERATURE 37.2
PC: ACTIVATE 2 VIBRATE 3
(the controller would then send some acknowledgement message)
PC: WATCH 5 AT LEAST 20
controller does nothing with the watch until sensor 5 reports 20 or higher, then:
5 MOISTURE 20
PC: ACTIVATE 1 VIBRATE 5
(the controller would then send some acknowledgement message)
PC: ACTIVATE 1 ROTATE 4
(the controller would then send some acknowledgement message)
PC: SHUTDOWN ALL
(the controller would then send some acknowledgement message)

and so on. I hope this helps you. Please let us all know if you implement anything.
Jabber
Explorer
Explorer
Posts: 32
Joined: Fri Jun 20, 2008 9:07 pm

Re: Requirements for a dildonics protocol

Post by Jabber »

Some interesting thoughts.
miss_tina wrote:Some commands that I think would be needed for the PC to send to the controller:
- command to query for available devices
(controller then reports each available device and some kind of info on type of device (sensor or toy, etc) available options (vibrate, motion, etc), and where device is located)
A command to query the controller is of course needed, so we don't have to manually configure all software that connects to the controller.
miss_tina wrote:- command to 'subscribe' to a sensor - will then get reports on some interval
Yes, this is where I see the asynchronous messages from the controller coming in. For some sensors we might need a high sample rate (like several hundred samples per second) for frequency analysis on the PC, so to overcome the limited bandwidth of the serial connection, we might need some kind of buffering too, so that several samples can be sent from the controller in one message.

Unfortunately this means that we also want to use interrupts in the controller to transmit to the PC, and this may prove tricky, as the Arduino software doesn't use transmit interrupts.
miss_tina wrote:- command to 'set a watch' on a sensor - will then get a report only if some threshold (if it was measuring body temp for example, then it reports nothing unless temp goes outside the watched ranged)
This would be nice to have. But it can also easily be implemented in the PC software, if the PC gets sensor readings. So to keep the protocol simple, I would prefer not to have such a command in the protocol.
miss_tina wrote:- commands to turn on / off toys
- commands to lock/unlock locks
I had not thought about locks, but I think they can be considered outputs, just like vibrators.

In your example you have more then one output setting for some toys. To keep the protocol simple, I'd prefer to only have one output setting for each output. Toys with more than one setting can easily be controlled by using several outputs in the controller.

Also, I think we should try not to include units (like temperature) in the protocol.
miss_tina wrote:- commands to set levels or activate features on toys (what was possible would need to have been reported)
- each of the commands would need some sort of deactivate command also
I was thinking about one single command to set outputs, like "SET OUTPUT [ID] [VALUE]". In most cases setting the output to value 0 means turning off the output. For locks and other binary outputs, the possible values could be 0 and 1. The value 0 then means unlocked, and the value 1 means locked. For vibrators we could use a range of values, like 0-255 to set the intensity of the vibration.
miss_tina wrote:- probably some sort of deactivate all command would be needed
Yes, we should probably have a RESET command that will reset everything and put the controller back in the state it has when it is initially powered on.
seraph0x
Administrator
Administrator
Posts: 2654
Joined: Sun Jul 23, 2006 8:58 am

Re: Requirements for a dildonics protocol

Post by seraph0x »

And reason why we shouldn't just use the Firmata protocol? Not a rhetorical question - I might be overlooking something. It just seems like the obvious option.
Jabber
Explorer
Explorer
Posts: 32
Joined: Fri Jun 20, 2008 9:07 pm

Re: Requirements for a dildonics protocol

Post by Jabber »

seraph0x wrote:And reason why we shouldn't just use the Firmata protocol? Not a rhetorical question - I might be overlooking something. It just seems like the obvious option.
The main problem I see with Firmata is that it doesn't really support fast data transfer from the controller to the PC. Unless I have misunderstood something, every reading has to be transferred in a separate message to the PC, which induces a lot of protocol overhead. While we could overcome this by extending the protocol (ie. inventing our own, based on Firmata), there are some other limitations in the reference implementation that could make it hard to obtain a high data rate from the controller to the PC. The problem is that I/O in the Arduino environment by default is very slow. An analog read by default takes about 100 microseconds while the processor is busy-waiting, so we can at most do 10.000 samples per second, and we can only do this if we do not spend processor time to send the data to the PC. But sending data to the PC from an Arduino is also very slow: The software does not use xmit interrupts, so the processor is busy-waiting during the entire transmission.

I also have several other reservations:
- Firmata seems to be targeted at people who want to do a lot of controller-side programming. I'm more interested in a protocol and a framework that makes it easy to use a controller that has already been programmed with software to speak whatever protocol, and configured with hardware for the sensors and outputs needed. Basically a protocol for a dumb I/O device. The controller-side framework I intend to make is a library with almost all the needed code, so the main Arduino sketch is almost nothing but setting up the configuration according to the hardware connected, so the PC can query and use it.
- Firmata is binary. This may be a bit more effective than an ASCII--based procotol for low-bandwidth communications. But ASCII-based protocols tend to survive better, as it is a lot simpler to debug them (you can use any serial communications program on your PC to communicate with the controller). And we only need the efficiency of compact binary data for the asynchronous messages from the controller, which will only start when we send the controller a command to start sending it.
- Firmata cannot be used for querying the way we want. We can get a number of pins for input and output, but we cannot see what is connected to them. I'd like a simple interface so that software without any prior knowledge than the serial port can query the device and see that it controls "PENIS RING VIBRATOR", "BUT PLUG VIBRATOR" AND "SHOCKER", and has "PENILE PLETHYSMOGRAPH" as an input. This way an advanced tease program can see what devices are available, and ask intelligent questions like "Where is VIBRATOR 1 located?" if needed.

Finally I hope for a protocol that could become an industry standard. The cost of mass-producing hardware for controlling one or more vibrators is getting so low that it probably is becoming interesting for some chinese manufacturers to produce it in volume, if they can see a market. Their problem right now is probably PC-side software, but if they could say "This device supports Simple Dildonics Interface Protocol (SDIP)" and point to existing freely available PC software using this protocol, there might be a market.
Jabber
Explorer
Explorer
Posts: 32
Joined: Fri Jun 20, 2008 9:07 pm

Re: Requirements for a dildonics protocol

Post by Jabber »

Here is the draft on Simple Dildonics Interface Protocol (SDIP) I am currently working from. Most of it has been implemented both on an Arduino (using the 0015 libraries) and in Java on the PC side. The latest changes I've done to the protocol draft after thinking about all the good input I received here have not yet been implemented in my code, but these changes should not be hard to do.

On the Arduino side I have had surprisingly few problems. I've created a nice little library for interrupt-driven serial transmissions that works nicely with the standard Arduino HardwareSerial library. I have not yet tested the code for the asynchronous channel messages (though the Arduino-side code has been written), but most of the rest of the protocol seems to work fine.

The worst problems I have had are (quite surprisingly, since I am a Java software professional) on the PC side, in particular with the serial communications. Getting RXTXcomm to play nicely without coredumping was hard, and I still have an unidentified problem where the USB system on my Ubuntu 9.04 gets into a state where opening /dev/ttyUSB0 keeps on giving an error until I reboot the OS.

But already now it is fun to play with. I've fooled around with some classes for generating sine waveforms, and AM and FM modulations of them, and it is quite interesting how little code is needed to create a really frustrating waveform that you really cannot ignore.

So besides the release of a reference implementation of the protocol on Arduino and Java (again, depending on your valuable input), expect me to soon (depending on how much free time I have) to release a new kind of very simple but hard tease: Run this waveform on a vibrator placed at a sensitive place for at least an hour without jerking off, removing the vibrator or going insane ;-)

But I wanted to post the draft protocol for your comments:

Edit: Snipped long and outdated protocol specification. Please look here for the current specification.
Last edited by Jabber on Mon May 25, 2009 3:04 am, edited 1 time in total.
Jabber
Explorer
Explorer
Posts: 32
Joined: Fri Jun 20, 2008 9:07 pm

Re: Requirements for a dildonics protocol

Post by Jabber »

I have just created a Google Code project, and uploaded the protocol description and the Arduino framework (working, but probably still quite buggy) to it: http://code.google.com/p/sdip/
Jabber
Explorer
Explorer
Posts: 32
Joined: Fri Jun 20, 2008 9:07 pm

Re: Requirements for a dildonics protocol

Post by Jabber »

For those interested in the gory technical details and programming,. I have just committed some PC-side code to the above repository. A big "thank you" to seraph0x for letting me use the milovana.com name in the Java package names.

The idea is to distribute the SDIP protocol on the net, so dildonics becomes tele-dildonics.

This code is centered around a server that ensures anonymity and allows people to connect to each other. On one port of this server, people with a dildonics controller they want other people to control can connect. On another port people who want to control other people's dildonics controllers can connect and list the available dildonics controllers before connecting to one of them.

Besides the server there is a simple client program that people with a SDIP-capable dildonics controller can use to connect to the server. Another simple client program can be used to connect to the server for controlling other people's dildonics controllers. Nothing fancy - just simple console-based programs.

The code is still a bit buggy, and distributed channels are not yet fully implemented. But with this code it is possible to remote-control vibrators and other interesting output devices.
User avatar
qDot
Explorer
Explorer
Posts: 57
Joined: Mon Jun 01, 2009 2:17 am
Gender: Male
Sexual Orientation: Open to new ideas!
I am a: None of the above
Contact:

Re: Requirements for a dildonics protocol

Post by qDot »

So, I'm really just skimming the SDIP docs here, but why not go with OSC (http://www.opensoundcontrol.org/)? Seems like it does everything you want, in a format already supported by a TON of languages and libraries.
Jabber
Explorer
Explorer
Posts: 32
Joined: Fri Jun 20, 2008 9:07 pm

Re: Requirements for a dildonics protocol

Post by Jabber »

(For other users who do not know this new user here: I am pretty sure this is the person running the (for dildonics interested technicians) famous Slashdong blog about dildonics.)
qDot wrote:So, I'm really just skimming the SDIP docs here, but why not go with OSC (http://www.opensoundcontrol.org/)? Seems like it does everything you want, in a format already supported by a TON of languages and libraries.
I was not aware of OSC, but after having had a look at it, it looks really interesting. It it not quite what I am attempting to do with SDIP, but all the functionality of SDIP could be implemented by having both sides acting as both client and server. SDIP is a connection-oriented protocol sending messages in both directions, while OSC is a message-based protocol with support from a lot of software.

My main objective for SDIP is to have a simple protocol that dildonics hardware manufacturers can use to communicate with programs on a PC while using less than 1 Kb of code in the microcontroller for a simple output-only device and less than 8 Kb for a full implementation including sensor devices (channels in SDIP) - even if SDIP has to enumerate the attached input and output devices so the software using the device can see what it is meant to be used for.

So while I am not (at least yet) ready to abandon SDIP, bridging this protocol to OSC definitely makes sense.
lantin
Curious Newbie
Curious Newbie
Posts: 1
Joined: Thu Jul 23, 2009 3:19 am

Re: Requirements for a dildonics protocol

Post by lantin »

When I think "dildonics protocol" two things come to mind. One is "computer controls vibrators", the other is "user communicates actions to another user".

We don't yet have a convention for these two different, but related, concepts. I'll address them separately with respect to how we solved these problems in the OpenVibrations project (http://sourceforge.net/projects/openvibe/ and more info at http://wiki.opendildonics.org/OpenVibrations).

A separate issue (in terms of how the OpenVibrations project approached the problems outlined in this thread) is how to get input from devices.

Computer controls vibrators:
----------------------------------

For the Open Vibrations project (http://sourceforge.net/projects/openvibe/) we chose to implement the Rez Trance vibrator's protocol for controlling USB-based vibrators. That has the advantage of having a fully assembled device available immediately (http://tim.cexx.org/projects/vibe/buyone.htm), but also the availability (same link) of a device for a hardware developer to use to interface with their own device (ie: Tim makes a controller you can connect your device to with a mini-USB cable).

He uses PWM to control the vibrating bullet, so if your hardware can interpret those signals, you can write software to drive your hardware using a Trance controller.

qDot has a libtrance project to control these devices, and there's a Linux kernel module as well, so there's an API available for software developers.

They need to understand what the values of 0-255 mean to your hardware, but that's a trivial matter.

In the implementation of the OpenVibrations project, we decided that 0 meant "off" and 1-255 were increasing degrees of "on" for Trance-like devices. We also support various other devices (http://wiki.opendildonics.org/ComputerInterfaces).

User communicates actions to another user:
-----------------------------------------------------

This is communicated in two parts in the OpenVibrations project.

At the most basic level, a user controls a vibrator using the Vibrator Control Protocol (VCP), which was an April Fools RFC from several years ago, but which defined a perfectly acceptable way to control Vibrators. We have succeeded it with version 2.0 which adds some features like controlling multiple vibrators (see http://wiki.opendildonics.org/VibratorControlProtocol for more info). Having a program that speaks VCP frees the developer from having to understand how a vendor chooses to communicate with their hardware - be that USB, RS-232, Parallel, ZigBee, etc. Hardware vendors develop their device-to-computer API however they want, and write a VCP compliant interface to it, and the dildonics software developer doesn't ever have to think about it. This falls back to the "computer controls vibrators" above.

In terms of users communicating directly to other users, the OpenVibrations Communications Protocol (http://wiki.opendildonics.org/OpenVibra ... nsProtocol) is used. This in turn frees application developers to focus on the user experience and the Internet communication process, and not have to think about how a device is controlled (regardless of whether the other end of the connection is speaking VCP to its vibrator drivers, and what hardware-level protocol the drivers are using to control the actual vibrating bullets).

Inputs from devices:
------------------------

As for input back into the system, OpenVibrations does not currently address this. The Simple Gynoid Simulator sub-project (also at http://sourceforge.net/projects/openvibe, and more info at http://wiki.opendildonics.org/SimpleGynoidSimulator) is working to address the issue of inputs into the dildonics experience.

At the moment the Simple Gynoid Simulator only accepts positional input such that it can determine the position of the user, and imply the position of locations on the user's body that require vibrational interaction.

Feedback on what sorts of input would be important for a first generation protocol would be valuable (beyond simple depth-of-penetration).

Future generations of these protocols would require the ability to communicate all sorts of input values, like those specified in the Maria Script documentation by xxxtoytech (http://wiki.opendildonics.org/Mariascript).
Post Reply

Who is online

Users browsing this forum: No registered users and 23 guests