• If you would like to get your account Verified, read this thread
  • The TMF is sponsored by Clips4sale - By supporting them, you're supporting us.
  • >>> If you cannot get into your account email me at [email protected] <<<
    Don't forget to include your username

The official Ticklebot thread

Sure we could try that. I'm really not worried at all about the release mechanisms though. I've had plenty of time to think it over and I have a few mechanisms that can work alongside each other without interfering. As long as one works each time that's all that will matter. If failure occurs in a mechanism more than once in a hundred test runs we won't use it. That way the chances of real failure will be less than (1\100)^N where "N" = the number of active fail-safes. I think a minimum of 5 fail-safes should be used, making the chance of total failure less than one in ten billion. Safe enough for ya? 🙂

I've been thinking of the robotic hand and I just remembered one of the reasons I hadn't seriously considered it before: programming. The great advantage of a hand is that even a simple one is capable of more complex movements than an electric toothbrush on a stick, but that means you can't just rely on random movement for it to work; I'll have to program finger strokes. Given that the rest of the programming is easy enough and I can insert any kind of module coding into the program without having to rethink the overall design, I'm prepared to give it a go. If it works it should be awesome, but if not it may cost a lot of time, money and effort. But ain't that the philosophy we work by.

What I think I'll do is program stroke patterns both for individual fingers and the whole hand, so that you can get both one finger doing its thing or all of them working together in sync. It should just be a matter of timed servo commands. I can cook up a bunch of different actions or templates to stick in the primary coding level for that module, then they'll be activated and coordinated from the secondary level. If I'm right, the only difficulty will be in working out how to make the hands tickle and how to turn that into a sequence of code.
 
Oh sodding Hell, a few random variables still need to be inserted into the equation for it to work properly. Perhaps variations in speed, position of the hand to apply more or less pressure etc. It's going to have to use very simple movements or it'll just be too complicated to program.

Secondary coding level:

Basic movement to carry out
General level of intensity


Primary coding level:

Carries out simple, pre-programmed actions
Adds random variables to position and speed
 
Funny how something that appears so simple quickly gets soul-destroyingly complicated once you get into the details. I'm already stuck on programming the part of the user interface that lets you calibrate the maximum ranges of motion for each axis of a module. Should be a cinch. What I didn't count on was the fact that I can't seem to call on variables without declaring them within a subroutine, which is useless if what I'm after is the existing value. I'm spending about 95% of my effort trying to work out how to make the system user friendly in case someone makes a simple error like inputting a higher minimum value than the current maximum. Either I need to come up with a better system for even the simplest functions or I need to be prepared for some seriously frustrating times ahead.

Maybe if I ran subroutines to store values in another form to be called upon... Sorry, if I don't write it down somewhere I'll forget. And I feel like venting my frustration.
 
Okay maybe it's just my lack of experience but I'm starting to be really concerned as to whether or not a robotic hand will really tickle the user and some for some people the tickling sensation stops after a while with brushes.
as for the minutes you can just make the minimum time that you can input less then the maximum time you can input.I know that won't take care of everything but it is one way to help
 
I highly doubt that the first hand-tickling module we come up with will be capable of tickling the user. Or the second. Or third. It's going to take a lot of trial and error to see what works and what doesn't as well as a lot of clever thinking to make a module that can effectively tickle. We know this isn't going to be easy and we certainly won't get it right the first time but it has to start somewhere right?

I think I've worked out my little problem with the min\max input. Turned out to be a simpler process than the one I was trying, as usual.

In theory yes everything should work fine as long as the user always inputs a minimum number that's less than a maximum but everyone makes mistakes. I'm trying to make the system full-proof for the user so they don't have to worry so much about setting things up to crash.
 
However long and however many attempts it requires to get right will be worth it if we end up making a fair-dinkum tickling machine.

Smade's set up a project site for this so we can organize and update our notes more easily. I don't know how much updating I'll do here now since it looks like no one else wants to try helping out, but I'll update the first page here when something big happens. At the moment the primary level coding is going pretty well, we're still trying to decide what the best control board would be to use as an electronic hub, we've got a few good candidates for a software-electronic interface and some third-party designs for simple robotic hands anyone could build.
 
Ok quick question for anyone who's still following this thread.

I'm designing the user interface that'll be used for most of the tickling modules and I've included a bar that lets you set and calibrate intensity levels. It works in two stages:

First stage is the user has to calibrate each level. That means every moving part of every module needs to be calibrated at every intensity level to get the most out of it. You could just copy paste the settings but that would make it less interesting.

The second stage is when the secondary programming level tells a module that it's going to be activated at a particular intensity level. So the settings you've saved will then be used when it's turned on. This way whatever program you're using the Ticklebot with has control over how intense each module is, and can utilize them in any configuration.

Now I could just put in a sliding bar that uses some complicated formula to come up with the values but that would be a lot harder and may even be less efficient in the end. If users can calibrate each setting themselves then they'll know just how ticklish each setting is.

Assuming that we can build a tickling machine that is in fact capable of torturing the user, how many intensity levels should there be? I'm halfway between 3 and 5 at the moment.

If the lowest setting is more of a pleasant massaging sensation and the highest is the most intense tickling the machine can possibly dish out, how many levels should be in between? Keeping in mind of course that each level needs to be calibrated which could take a very long time if you want a full 1-10 scale.
 
Just to give an idea of the complexity of each module and the amount of calibrating that needs to be done, I've provided a screenshot of the module interface I've been working on so far. Each box under the "Stored values" sections represents a value that needs to be input for an intensity scale of 1-5.
 
I say 1-10 because it would give a wider range of possibilities for the machine and the different tickles but I'd be satisfied with 1-5 too
 
Thanks QueenBeeBeeMari, it seems I can always count on you for a response to a question :lol

More choice isn't always a good thing. Technically it makes the machine more flexible but then game developers have to decide exactly which level to use at any given point. How much difference can there be between a 6 and a 7? Plus that would be a LOT of calibrating for the user, which I imagine would be difficult as well as time-consuming. I don't know about you but I don't know if I'd be able to decide on 10 distinct levels of intensity. I mean let's try writing descriptions for different levels at different ranges:



1. Light, pleasant tickling that teases or massages
2. Moderate tickling that is just around or above the user's tolerance
3. Worst tickling possible

1. Light tickling as above
2. Mild tickling that elicits a response without being unbearable
3. At user's tolerance level (user would pull away if possible)
4. Above user's tolerance level (user would stop machine if possible)
5. Worst tickling possible

1. Very light tickling, more for anticipation
2. Light, pleasant tickling
3. Mild tickling
4. Intense light tickling
5. At user's tolerance level
6. Slightly above user's tolerance level
7. Moderate tickle torture
8. Intense tickle torture
9. Very intense tickle torture
10. Worst tickling possible



Also keep in mind that this is for each individual tickling module. You could have a large range of settings for a module cluster, for example every module targeting the feet, which have modules going at different intensity levels.
 
looks like you did it hehe,they sound good to me.I wouldn't mind to taking the time to calibrate the machine if it would make it more effective though I can't speak for everyone else.Just for the record though,how long are we talking?
 
How long to calibrate? Hard to say.

I think a safe estimate would be half an hour to an hour for a full-body complement of tickling modules each with 10 levels of intensity but there are a lot of things to consider. Originally I thought you'd just come up with a single calibration and as long as it worked that would be alright, but then Slaver pointed out that if the machine were working at the same intensity at all times it would be less effective.

The upside is once it's calibrated you can save your settings and not have to worry about it the next time you run the program. Unless you change your position or the arrangement of the modules, in which case you'll have to account for any difference.

It might be possible to have a setting where you can decide whether you want 5 or 10 levels but I'd have to give it some thought.
 
I've decided to go with 10 levels of intensity for a few reasons.

If the user can't be bothered spending twice the time calibrating the machine they can just copy paste every second value. Easy peasy lemon squeezy.

It save game makers the hassle of worrying about intensity levels. All the third-party developers need worry about is the basic commands. If they only want to use 5 levels of intensity that's also easy. Just program the game for levels 2, 4, 6, 8 and 10.

I really doubt people will need more than 10 levels of intensity. I had a tough time coming up with a way to describe each one and I'm not even sure there'll be a great deal of difference from 7-10. This way people definitely won't feel short-changed by having too few options.
 
Yayy!If they can't be bothered then,just calibrate what you want and save that and come back later or just leave it.
 
Working on a system to save settings. Visual Basic has a weird way of accessing files, but the premise is simple; you just save the values to a text file then load it up when you start again. That way you can have a different file for each position the module might be used in.

But anyway, I'm here again concerning a question I'm a little embarrassed to ask. In the original tickling machine thread (http://www.tickletheater.com/showthread.php?t=45784) it was fairly unanimous that people would use on if they had one. The idea of forced sexual stimulation was also brought up by a few people. At first I thought the user could just attach a sex-toy like any other module, but there might be a few problems with that. Pretty much all the problems are related to guys in particular, which seems a shame since I think there'll be more guys using this than girls :lol

1. The machine can't tell when the user experiences an orgasm. This might be desirable if continued forced stimulation is the goal, but being a male I'm pretty sure I at least would not want to continue. The user could have the control to turn off the machine once they're done but that would only work if they didn't mind also having the power to stop the tickling, or if they didn't mind being tickled post-orgasm.

2. Girls might not experience this, but guys generally don't have much interest in sex or anything of the sort after finishing. If I were in the machine at this point I doubt I'd get any enjoyment from it continuing to tickle me. Continued stimulation would probably be even worse. Damned refractory period.

3. It'd be pretty hard to do anything safely around that area unless you were immobile, which would mean maintaining an erection at all times.

Anyway it'll probably be a long long time until we start developing anything along these lines (Slaver and Smade seem to be taking new year's off) but the more we know about how the end-product should function now the sooner we can have finished detailed plans of the wholes system. Any thoughts on this would be helpful.

Looking over the old thread it seems far more discussion occurs when no one plans on getting anything done...
 
I think we've reached the death of this thread too somehow. I guess I severely overestimated the amount of enthusiasm for the idea. I'll just go back to lurking until I have something more to post.
 
Okay No,I am against it.Sorry to rain on the party or be an ant at the picnic but no,I'm against the idea of forced sexual whatever I don't give a you know what.
 
Okay No,I am against it.Sorry to rain on the party or be an ant at the picnic but no,I'm against the idea of forced sexual whatever I don't give a you know what.

And now we're back to people misunderstanding the point of the machine again. I'll just post to say this machine isn't intended for rape any more than forced orgasm fetish is about rape. If it's just not your cup of tea then fine, but since you've said you're "against" it I have to assume it's more than that. Since it's highly unlikely that you'll be the last person to see things that way I'll just drop the idea and save myself the hassle. It's been frustrating enough trying to explain safety precautions to people.

Weird to think how many hours I've already spent making this thing easy for everyone to use, when it will only end up benefiting people who don't seem interested in it.
 
I think people will be interested in it,they just don't believe it is going to happen.They think it's all talk right now
 
So far I've written over 2000 lines of code for the core programming, which all up has probably taken over 12 hours. Believe me, I have spent a great deal more time and effort working on this thing than talking about it. But you're right, people won't care until we actually have something to offer them.

I'm not put down by the fact that this whole community can't believe in the project enough to stay interested, in fact I feel very fortunate that I found even just two guys who are prepared to see it to the end.

Sorry to keep posting when I should be lurking but I wanted to leave on an assurance that this project is going to continue with or without the support of anyone else. Maybe in a few years time we'll have something to share, and when we do it'll be posted here for everyone to enjoy.
 
No,dude I really wanna hear it and be a part of such a cool thing.I know I can't help with much but I can put in my two cents and help with decision making
 
As long as there's still at least one person here who has thoughts they'd like to share, I'd be happy to field questions. There aren't many broad decisions left to be made that don't require technical knowledge of programming or electronics, but I'll check in here for input on everything else that could use another opinion.

At the moment I'm trying to organize the way the tickling modules are structured in the program. It wouldn't be very convenient if game developers had to tell every single module how to behave, nor would it work very well since each one is interchangeable. Hence I've come up with a system that will hopefully solve that.

Each individual tickling module will be assigned to a "channel". The channels are there mostly for the benefit of game developers. If you're writing a game and you want a specific module located between the toes to be activated for example, you would include documentation that tells the user to place a module there and assign it to channel 9. That way the game maker just has to send commands to channel 9 for that particular module. If it sounds complicated now I'll make plenty of tutorials when the programming is finished so there's no confusion.

Of course it still wouldn't be very efficient if the game maker had to account for every single tickling module, and the user may wish to add a few extra ones. Each channel will be assigned to a cluster and group. Clusters represent specific body areas like right toes, left sole, left underarm etc. Groups represent general body areas like feet, lower half of the upper torso, upper half of the upper torso etc. This way if a game maker just wants the feet to be tickled they only need to send a command to the "feet" group. This also means that users can assign as many modules as they like to clusters and groups without clashing with the program.

What I need to know now is how the clusters and groups should be structured. Is "right foot" enough for a cluster or should it be broken down into "right toes" and "right sole". Maybe the top of the foot should also be included. I'm also planning to have a full-body group which has a min and max input, so it activates every module at random intensity levels within those min max values.
 
Last edited:
What's New
1/12/26
Visit Door 44 for a large selection of tickling clips!

Door 44
Live Camgirls!
Live Camgirls
Streaming Videos
Pic of the Week
Pic of the Week
Congratulations to
*** brad1701 ***
The winner of our weekly Trivia, held every Sunday night at 11PM EST in our Chat Room
Top