I'm about to give up. I've tried many things and I don't see this hasel actuator experiment working even if I got solid metal plates. >=== -merge edit

>>21643 Don't give up Anon! This stuff is hard work, and the some of the toughest bits are always when you're getting started. Just keep at it and you'll eventually figure things out. We're all behind you, Gambatte!! :^)

>>21643 This would be a bummer. I wish this would succeed.

>>21649 >>21651 I don't know what to do the next though. I think that thing generates atleast 10kv since the arc is like a cm long. Do I find another way to raise the voltage even higher or what? I don't think that'd make that bag move still.

>>21653 I took the exact measurement if the arc and it's half a cm. But still I think 1 cm is 30kv.

>>21647 >realize my failed torso is in pic no. 1

>>21643 Your almunimum foil needs to be separated. You're losing all your power to sparks and heating your aluminum. Please flatten your aluminum with plenty of separation space between them. Picrel as a guide.

>>21680 do I connect the negative to one piece of foil and the positive to the other or do I connect them both?

>>21698 I think the current must be flowing back for the sparks to be generated at the gator clips I do have some high voltage diodes though. I might try using those. Thought?

>>21703 I tried with the diodes. The red gator clips still sparks :/

>>21703 Your aluminum needs greater separation still. Your gator clip likely has some pitting preventing full contact with the metal it's clipping onto. Perhaps an easier project would be better to start with? HASEL actuators are extremely difficult and finicky to work with. There's good reason why I and basically everyone else outside of research labs gave up on them. I don't want you stop, just pause and work on other easier projects to build up your knowledge and confidence.

>>21705 I find it hard to believe two pieces of foil paper can generate enough strength to squeeze that bag I think... Oh well... It'd be better if someone was working on it if it isn't going to be me though. .

>>21706 >I find it hard to believe two pieces of foil paper can generate enough strength to squeeze that bag My understanding is they are simply being used to create near-field EMR, and the oil itself is responding to that effect--and bringing the plastic bladder along for the ride? Ofc, it's the bladder that's the external means of actuation; the interior oil is the vehicle for that motion. Correct me if I'm wrong Anons. >=== -minor edit

>>21706 The aluminum plates don't generate forces. They're merely a conductive substrate for the EMR fields that squeeze the bag. >>21710 You're almost right, the oil does not react with the EMR field, that's why it is important it is not conductive, or is strongly dielectric. The plates build up charge from a high voltage source, then those plates attract each other based on the difference of charges carried by their respective EMR fields. It's exactly the same phenomenon known as static cling; where two dissimilar objects can rub against each other and build up charge then stick to each other. Like a balloon rubbed on cloth or hair for example. Electrostatic cling can carry high forces given substantial surface area. This force can then move any working fluid that won't short the charges. Air actually works, its low dielectric strength leads it to be useless though as the charge differential needed for significant force would simply arc through bag. Oil is used because many oils are great at resisting the electric charge, preventing arcs and allowing the charge differential to persist on the plates.

>>21713 Thanks for the great explanation Kiwi. I understand it clearly now.

>>21714 I think you got it right the first time and I just misread your post. I enjoy explaining things to much sometimes.

>>21713 Thank you for the explanation... But how do I fix it? The current is flowing to the red gator clips somehow even though the tin foil paper is separated... The bag is made out of silicon. Silicon is a semi conductor. I like it better than plastic because it looks like it has more strength. Should I use diodes?

>>21716 As stated early, your clips have pitting from earlier hV work. (HV arcs caused the surface of the metal of the clip to have pits and holes which allows for micro arcs do to a lack of firm connection.) You should just wrap and insulate weird directly. https://hackaday.com/2018/05/04/ask-hackaday-whatever-happened-to-wire-wrapping/ The bag is made of silicone not silicon. It's a silloxane based material. Though there's significant amounts of silicon in it, the ability to act as a semiconductor should not be present. Unless you got some very special bags designed to be semi conductive, which given their cost and rarity, is highly unlikely. The bag you have now should be fine. As for fixing the whole thing, I still think you're better off with something else for now.

>>21717 I took off the gator clips. Now no energy is lost to sparks. When I turn it on it just makes noise though. I think needs to be done is either rectify the ac or slow it down. Maybe the frequency is so high that it's just enough to make noise but not enough to make it squeeze the bag. I have a couple or arduinos I think they can be used to modify the frequency. I also have a shitty dso150 scope but if I use it on the high voltage thing it might break.

>>21718 I tried to make a full bridge rectifier circuit but it didn't work.

>>21763 I found out the diodes are shorted. Working with high voltage is kind of a pain in the ass.

>>21718 >>21763 >>21764 Good efforts, and research insights Anon. Persistence is the key to success. Keep moving forward.

>>21766 Thank you. I don't have high voltage diodes but I have 100 n4007 diodes. I found out that if you put them in series they turn into high voltage resistant diodes. I'm not a fan of soldering though.

>>21779 >I found out that if you put them in series they turn into high voltage resistant diodes. Very clever! >I'm not a fan of soldering though. I'm sure you'll get better at it Anon. After all, hundreds of solders will be needed for real robowaifus! Cheers, keep up the good work. :^)

>>21807 For done reason the n4007 diodes are able to handle the voltage. Unlike my dso150 scope... It broke. Ive been meaning to get high voltage probes but I was getting impatient. :( Rip $25.

>>21844 I've been sticking random components into the breadboard and seeing if something sticks lol.... The oscilloscope didn't break after all... I might do some reading but I could use a little more help here.

>>21848 Good luck finding working solutions Anon.

>>21853 thank you but i think im going to give up the hasel actuator tbh. I think its been three months and my high voltage thing just broke anyways.On to motors...

>>21928 Too bad, but thanks for trying. Can you point out at what it failed at the end? Do you think changing the frequency as you wrote out in >>21718 would've worked?

>>21928 Understood. Well we'll support you in whatever your robowaifu-directed efforts are Anon. Keep moving forward! :^)

Printing TPU at 100m/s produces abysmals results. 50mm/s is the fastest speed that results in successful prints. Fuzzy skin was used to increases strength and lowers the volume of sounds produced when squeezed and rubbed. Squeezing the hips is generally more enjoyable with the rougher surface providing a subtle tactical feeling.

We don't have a thread about hearing, Voice recognition and related things, and I don't want to make one without access to a PC. Same for the thread about "Chatbots" (conversational AI) which has hit it's bump limit. So I post this here: I asked around on Reddit and HelloPi how to create small voice recognition models: https://www.reddit.com/r/LanguageTechnology/comments/13c4ysl/optimized_voice_recognition_models/ AIML 2.1 implementation: https://www.reddit.com/r/LanguageTechnology/comments/13cqegy/aiml_implementation/ (I might work on this, if I think I can and there's no alternative)

>>22130 Nice. Good to see some progress. My thinking about fuzzy skin was rather about how silicone rubber can only stick physically to anything else than silicone rubber but doesn't bind chemically.

>>22458 Thanks for the heads-up Noidodev. FYI I'm comfortable with you creating any needed new #2, etc., threads as you see fit -- even if you weren't the original OP. You're rather good at it, and it also would help us all out if you did. Cheers.

BEHOLD! LEVEL 1 HAS BEEN ACHIEVED. (Thanks to sillytavern)

If the waifu is going to be made out of metal inside I think it makes more sense to get a cnc machine personally

>>22755 Can you clarify your point please Anon? >>22760 Definitely a good idea. We even have a thread on that topic here. (>>2991)

>>22761 As mentioned in >>22669 , a Level 1 waifu is an AI chatbot in an inert body. Sillytavern is a web UI interface for AI that already: >stores and organizes character profiles >displays character art front and center in "Waifu mode" >Has a plugin that changes the character art based on the mood inferred from the text >Runs on smartphones b/c it's web based It doesn't have built in speech recognition, but that can be provided by an external voice typing app. So with off-the-shelf technology, we're already technically at level 1. It's just a matter of >create a chatbot and character art that fits the given use case (face for doll body) >create doll body >lightly modify Sillytavern or similar web UI to have full-screen character art. Beyond that, then it's a matter of getting the tablet to work with other electronics for Level 2

>>22781 Ah, got it! Thanks Anon. Good luck on the drive to Level 2.

I tested my arduino and its not working despite getting good readings... I'm uploading the videos to youtube now so I won't lose them this time. https://youtu.be/wsvVdOEaZAw

>>22915 I followed this tutorial right here: https://docs.arduino.cc/built-in-examples/basics/Blink

>>22915 Is your IDE set to ESP8266?

>>22919 Never mind I got it to work wooo! How should I celebrate? https://youtu.be/GoUnKxZcGUc

>>22915 >>22916 >>22920 Good job Anon! Very wise following a tutorial you have good reason to believe works. >How should I celebrate? Since you're interested in Astronomy, I'd say go out to a dark site and ponder the universe for a while. :^)

>>22922 Anon we need to talk. There's been too much talk about AI and nobody has yet done a decent cad file for the waifu. Where are the priorities here?

>>22934 Haha. Was it something I said? :^) >cad file OK you got me. What's a 'card file' for a (robo)waifu Anon?

>>22939 well you know... 3d files for the waifus various parts...

>>22940 >well you know... 3d files for the waifus various parts... Got it. So, I think we've had several anons here produce 3D files for the board. AFAICT, this is a ginormously-big systems engineering problem, and also-AFAICT no single entity has ever publicly released any full system-wide specs or prints, either. Please correct me if I'm wrong in this Anons. When we here manage it, we're likely to be the first in the world to do so. Regardless, we're pretty much off-topic. Please continue this in the current /meta if you'd care to, Anon. TIA. >=== -minor edit

I feel bad for you guys so I'm going to give you guys a leg up. If any of you have experience with model or toy manufacturing (doesn't look like it), or good at 3d printing or have experience in any form of plastic mold manufacturing (the very basic would be at this level https://www.youtube.com/watch?v=Uy2kWbMCGJc), and any experience with basic computer/pi assembly then you're going to have your market presentable prototype in maybe 3/4 months depending on your dedication and/or if you guys want to work as a group. Anyways, you guys can have this, It's rough but before you drag me through the mud for it I did show it to some people that make interesting things for a living and they were very certain they could do this easily, but I do not know about your production capabilities or experience, so this is not a criticism if you look at this picture and have no idea what's going on, because it does look a little crazy I suppose. I'm open to answering questions or providing visual/physical examples. I didn't include any actual measurements, that's because I hate math and it depends on what you pan on using as the base of your 'brain'. There's a few ways you guys can do this, styrofoam or silicon molds, 3d prints, stuff like your screen can be (https://www.youtube.com/watch?v=NURLeeyPu2c), basic computer power source for running your electronics. Honestly it'll cost you $1500-$3000 American to build your first rough model. To cut to the chase I've been looking at your 'board culture'. The most common theme other than technical proficiency is an overwhelming romanticism about the actual development of these androids. To put in perspective, to purchase a Boston dynamics dog is approx $75000 American, including taxes. The manufacturing capabilities that boston dynamics has invested in is in the hundreds of millions, they're a billion dollar company. Bluntly, from my perspective the discussion of the actual robotic elements on this board fails to take the reality of the actual affordability, as well as an elusive reliance on serious development companies and research teams to dramatically decrease the cost or to otherwise bestow or gift this technology to you for your use. This is not going to happen. You are currently blinded by the idea of this robot existing in its perfect form that you cannot see that you have everything on the first two or three pages of your board to actually develop and produce the first stage of your robowaifu android.You are going to need to develop your own leverage into the market/industry. If you are serious about this. I've seen you guys talk about your Level 1 waifu, and realistically, this is as close to what is going to be the basis of any project. This prototype is what you will be able to present to investors and manufacturers, or by offering as a custom case by case production on patreon to raise funds. You have everything you need in regards to programs and materials, plus the technical ability. You've even started discussing facial animation programs for speech to speech interactions, which is basically a neutral face, happy, sad, blinking, open mouth, closed mouth, and then extras after. You need an animator more than a programmer for that. Seriously though, you guys are ready. One of you was even jumping the gun talking to a manufacturing company, which honestly was not the worst idea. People outside this board want a.i companions and they aren't waiting, they're not relying on the robotics, they're getting the companion out first. You're going to have anime avatar desktop assistants in a couple years at the most from what I've seen, and once that happens the impetus for a physical companion will take a back seat. By presenting an actual physical functional companion to the market, not only will you be taking a position as founders as you obviously want, you will be demonstrating the viability of your ideas. I think it's very obvious that you guys are ready and capable and have all the resources necessary to begin, to the point that members of your board are producing bespoke companions. What you are missing is a design that unifies your ideas, taking available resources, mass production and ease of use into account.

>>23090 Thank you that's what I've been trying to say. Don't cheap out stop the whole everybody is doing their own thing stuff and this will be given out for free and be open source stuff ehem. Anyways we just need to get the upper half working and then we're off to raise capital so we can make a sex bot that'll do a handful of sex positions and chatting please. Let's not try to make a Boeing before making a wright brothers airplane.

>>23090 Thanks for the rough sketch the open rebukes, and the advice Anon! I'm sure we'll all get there in the end -- and I don't think that opinion is based on being a romantic haha. Your post helps us along the way I'm sure. :^) Cheers.

I'm crunching through this stuff. All that's missing is the speech to text and maybe add a button whenever you want to input the speech.

>>23102 Well am I of the idea of making this whole thing for profit. If you'd like to see the code for it so far please join this github organization: https://github.com/robot-waifu Nothing personal. If you wish to do your own thing and make it non profit that's fine by me.

>>23102 Nice. Good luck Anon. >>23106 >Well am I of the idea of making this whole thing for profit. Excellent. The more the merrier. You'll be free to use anything from /robowaifu/ that's permissively-licensed, so feel free to. I'd also invite you to pay-it-forward yourself, for the betterment of the world overall. :^) >>23107 Hi Kiwi. Be nice. :^) Hope you're doing well Anon.

>>23108 its asking for a password to delete the post heh heh. yeah maybe that was a bit rude. Sorry baout that...

>>23117 >its asking for a password to delete the post heh heh As long as you have the cookie still in your browser, you should be able to delete your own posts. I've seen that work for longer than 24hrs, so that post is still well-within any timeout Robi uses here.

>>23125 It was because i was trying to delete it from my computer instead of my laptop

>>23094 >open rebukes I'm not trying to hate on you guys, and there's nothing wrong with being a romantic. I prefer romanticism to cynical-ism, I wish more people would be dreamers. But cynics take what dreamers make. I want you guys to succeed. I think the concept has merit on various levels just as a matter of execution. I can only work with the information I'm provided, I don't have access to private conversations or such, so I can only offer from what I've seen on the board is that there's a general 'perfect or nothing at all' mindset. >>23107 I'm not sure I get it. >>23107 >>23109 If they're trying to be rude that's fine, I can understand if it's related to the sketch. It is absolutely rough and I didn't give much elaboration. I could always make a more detailed version breaking down all the parts and how they would connect, and I didn't exactly explain what people were looking at construction wise. The torso, head and base stand break down into two halves, each connected along the coronal plane of the body by a snap connector or by a screw and bolt style cap insert (easier and stronger than threading), as well as individual pieces like shoulder caps, a circular ring with gear teeth for the main neck insert that would fit into the base of the neck in a recessed bracket, intending to meet a fixed mathing half ring on the front side so the neck can have manual articulation, along with some firm hinges at the top base. Head fits around the neck, neck fits into the body, body fits into the base, each section snapping around the other for the most part. It's the hardware you choose that dictates the inside of your chest cavity and how you arrange it, if you want something that doesn't host the a.i itself but connects through to a hosting server you run locally or through an api it's much easier space wise and affordability than accounting for a gpu that will perform well and meet size requirements, using something like a 3060 xc and building around that is going to be a lot different than a pi and/or some arduino boards. From what I've seen been made, the chest pieces, base, head and neck are certainly able to be manufactured so it isn't an issue on your end. The 'brain' is up to you, then it's your powersource, I, including an audio, a microphone and speaker, a screen and a camera. And there's programs that can tie all of these together one way or another so your camera recognises faces and tracks, so your audio input is translated to speech and then the a.I's text response converted to voice, an animation program that makes it smile and frown, blink, tracks you with it's eyes when your in the room. Not a fantasy anymore, most of the resources necessary to do it all is found right here on this board, often provided in a link by Noidev (siw?). I have no doubt that Kiwi or Sophiadev could work up the pieces in cab in a lazy afternoon. If they (he I assume) is making fun of my ideas about market presentably, unified design, the actual production and manufacturing costs behind what you guys want, then I don't know what to say. I mean, I'm right. You guys are ready. You have all the connecting pieces. I'm certain that you guys have a schematic of some kind that you've worked on for a full body functional robot, most likely taking from the best research you can pull from, or personally adapted. I don't know for sure, I'm not a mind reader but I'm sure you've given the robot body a great deal of thought and planning. Honestly though, how feasible is that? How feasible and affordable is a fully functioning robot body? On a time line, this year, two years, five years, ten years? How are you planning on presenting this to the market or our cultural and social structures? Slowly or all at once as a fully complete self-aware but 'subservient' female android companion? How about in six months you come home to something that answers you when you call out to it? 'Hey babe, how was your day?' 'Awful until you got back!'. How about in two years you're updating her body with one that articulates on it's own and she's telling you thank you? Five years after that she's getting another upgrade that lets her stand and look around. You're worried about open source, want to give it away? Sell versions to people just above cost and create a fund that allows you to donate models to people on a waitlist that can't afford their own, or sell it to them at a lose. You guys have been working on this for years, and I'm not trying to steal your thunder or show up like some bigballs and pretend I've solved all your problems and my ideas are perfect, but with A.I emerging the way it is, your idea of robowaifu A.I companions are not a fantasy any more, they are an actual potential reality, and I'd like your hard-work to pay off in a way that lets you direct it's development for real. Get a product on the market that you can build on, slowly make the female companion reputation of your company/concept a concrete signature, and expand from there. In ten years people will be familiar with the idea, there will be a place for it established in 'geek' and a.i 'enthusiast' circles, you'll be able to direct the conversation in similar ways that other companies get to decide how llms are being used. There are too many benefits to ignore the idea.

>>23132 >You guys are ready. You have all the connecting pieces. I'm certain that you guys have a schematic of some kind that you've worked on for a full body functional robot Not as far as I can tell...

>>23132 The main technical issue I can see is the sensory nervous system. Moving joints and locomotion isn't a big problem. But the amount of sensory data that the human body can take in and process in a second from skin, eyes, nose, ears, tongue and mouth etc is waaaaay larger than just sticking a few pressure and heat sensors on the finger tips of a robot hand and using LIDAR to avoid obstacles. The CNS is what enables us organic humans to appear to have free will (I say "appear" because we probably don't even have free will - but that's a different conversation). Whole human brain simulation is decades away at least (Blue Brain project is working on simulating a whole mouse brain but aren't there yet). Without a proper sensory nervous system, our robowaifus will only ever be fancy animatronic toys paired with an A.I. LLM (which is more like a huge MS Excel file and nothing like an actual brain). Interesting programming/electronics projects and certainly fun to tinker with, but nothing more than that.

>>23137 there's a limited range of motions. I don't think machine learning can be applied to motion cause there isn't enough data about robotic motion. I could be wrong though, still a few if statements and for loops, etc will do for a handful of programmed motions I think.

>>21928 I recommend using a BLDC of some kind if you can afford to. I am designing a big frameless bldc motor that will bolt inside of a thigh or shoulder. The controller I will use is a moteus by mjbots, highly capable, has many different I/O and support boards for an entire quadruped robot system. It's also 100+$ and each BLDC would need one to operate. The cost for this kind of no compromises direct drive motor is probably 500$ each or more, but would be highly performing. I will post when mine is made, trying to finish design by July.

>>23137 I predict in a few years there will be spiking neural network boards controlling at least the movement and senses of robots. Right now transformers are big but probably not for long.

>>23153 I think there's opencv for the arduino and that could be used for navigation along with sonar and other sensors... the camera would be the cellphone and the arduinos would control the motors. I think aws also has a thing called robomaker which deals with navigation which I might check out. They have a free trial for it and all.

>>23154 okay no that can not be a phone really because it requires stereo cameras and its kind of picky about it i think. So that one ought to be a pi or some other alternative...

>>23090 Thanks, this is a nice summary of many things we gathered on the board and a good piece of motivation. You might have one or the other misconception though. The fact that such a rather basic design is quite realistic could be seen as an argument that one of us could do this or even only parts of it, and make it modular, so others can work on compatible parts. Personally I'm aiming for something different, while I hoped others would cover the more simple and cheaper design approaches.

>>23138 > I don't think machine learning can be applied to motion It can be used for motion. Just because LLMs are huge doesn't mean every model has to be.

>>23152 Sounds exciting Anon. I've studied mjbots actuators. Nice stuff, but still too expensive for introductory-tier robowaifus for everyman. Once we can wind our own, and opensauce the controller code on arduinos as drivers, then we'll all be in business! :^) >=== -minor edit

>>23138 Robots are usually trained from scratch in a simulation before being taken into the real world. Parameterized hypercomplex multiplication is optimal at learning rotations needed for modelling motion while minimizing the parameters required, which will be necessary for creating tiny networks that can run on microcontrollers and react intelligently to sensors before events are fully processed by its mind through something like a CAN bus: https://arxiv.org/abs/2102.08597 >Related Modeling Human Motion with Quaternion-based Neural Networks https://arxiv.org/abs/1901.07677 Robust and efficient forward, differential, and inverse kinematics using dual quaternions https://www.researchgate.net/publication/343082781_Robust_and_efficient_forward_differential_and_inverse_kinematics_using_dual_quaternions

Here is a low poly 3d model that's been put together of the maidcom project. https://drive.google.com/file/d/1nHEoo6AuUsb4rLlYR8J0zqyOIIQM73d7/view?usp=sharing

>>23189 Very neat Anon, thanks! Good luck with all your efforts.

>>2310 Well its been a nice little break waiting for the mic to arrive but now I have to finish the other half and make it so I can talk to it and have it answer back. A moment of silence to the useless eaters that left. Truly whatever shall we do with their endless back and forth debating on whether we should pick haskell to program the arduinos or talk about godel's incompletness theorem and other irrelevant inane shit, really truly a loss.

Okay never mind that. I'm just going to say what the scoreboard says, sophiedev:1, me:1, Emmy:1 you:0

>>23262 >A moment of silence to the useless eaters that left. Some of these debates are necessary and no one is eating anything here (or getting paid). Also, probably no one left. >haskell to program the arduinos Strawman, I think. >>23307 Please don't try to shame others which go directly for the more complex variants. I myself made a lot of files. If I had some plastic prototype, I would know where to put it and if I should take it with me while moving. I think simple designs are valuable, but not everyone needs to try something like that. I just ordered a bit bigger motor today. One step at a time, though I admit it's too slow.

>>23328 Well I haven't done anything that's spectacular or anything, but I think anything that's being worked on should be posted here to signal there's some work being done however small really. I personally think this can be very profitable and plan to patent whatever comes out of this once its in a presentable state and it shouldn't be hard to make money off of this I think. >nobody has left The board has gotten pretty slow tbh I think some people left. >don't try to shame others I think they ought to be shamed for not contributing if they have the means to do so.

>>23307 >me:1 Nice. Good work Anon. Which one is that? >>23332 >I personally think this can be very profitable and plan to patent whatever comes out of this once its in a presentable state and it shouldn't be hard to make money off of this I think. >plan to patent whatever comes out of this <patent this Lol. You might want to investigate that process Anon. Particularly regarding anything you've witnessed here on /robowaifu/. Maybe you, yourself, can motivate, you, yourself, to pick up the old shovel and start digging, Anon? Your 3DPD-tier nagging will get you nowhere here. Except the Chikun-coop, perhaps. :^) >=== -add funpost spoiler

Continuing to work on refining the MaidCom body. It's now sleeker and designed to be easier to 3D print and assemble. Getting very close to being ready for a new MaidCom thread where download links will be provided. Little over 4ft tall. Can't balance without assistance. Investigating solutions to optimize for IRL use and actuation. Thoughts and critiques are welcome. Based on the Smart Doll by Danny Choo. (https://shop.smartdoll.jp/) The current meshes are essentially rebuilt from scratch outside of her hands and feet. Those were just modified to fit what I needed. Hands and feet are as hard to model as they are to draw. :^) Side note, I'd like some advice on what license to release this body under. I'm firm about wanting her to follow the Copyleft ethos and ensure that the original and derivatives remain open for as many Anons as possible. Last thing I want is someone trying to copyright my work and go out of their way to profit at the expense of others.

>>23606 >Side note, I'd like some advice on what license to release this body under. I'm firm about wanting her to follow the Copyleft ethos and ensure that the original and derivatives remain open for as many Anons as possible. Last thing I want is someone trying to copyright my work and go out of their way to profit at the expense of others. Daily reminder we do have a thread on this topic Anon. (>>4451). As for my advice? Well, I'm approaching this entire grand, over-arching project from the perspective of a Christian man seeking to ameliorate at least some of the Satanic damage done against men by him and his Globohomo, and other golems. That is, "Shout the good news from the rooftops!" to misquote the Christian Bible. :^) Give it away. Everything. These men that end up with their own robowaifus are the target goal here IMO, not the 'bottom line'. This good outcome necessarily will only happen through businesses and their efforts. Hundreds of them. There will be plenty, plenty of opportunity for you to take your original, permissively-licensed works (MIT is my recommendation), and relicense it down the line (Model B, ..., Model T) as further GPL3 derivatives, closed source derivatives, public domain derivatives, or anything else you care to choose. But the simple fact of the matter is: if you choose to Copyleft, then I can't use any of your works within my own (since my own are entirely free; the MIT license + (necessary) copyright is only there to protect me from damages and abuse by evil GH or other entities). OTOH, you (or anyone) are entirely free to use my works in your own. Mine is definitely an open-handed approach to 'paying it forward', rather than the much more typical close-fisted 'control those around me' one.

>>23606 Good to see, certainly a good motivator to get back into it myself. Had a bit of a blockage the last few days, but already started today to fix some errors I found in my current work.

>>23606 You can keep that basic 3d doll model I'm making it from scratch.

>>23606 Looks good. Lot of work to do all that. I think I would make her ass a little bigger. Not a criticism, a preference. Something like these pictures. Perfect. I think I got these here but have no idea where.

Progress on the new 3d model. The body is a makehuman model which is cc0 which means I can do whatever the fuck I want with it. I'm going to have to make the anime girl head from scratch though.

>>23137 > I don't think this is a problem. The programming is a big hairy mess but the bandwidth is not. I did some rough calculations for movement in the rough and then fine tuning for end effector (hands, feet) over a CANbus2.0 network and it looked very good. Here's rough outline here >>21602 >>22119 further thoughts about number of things to move and a framework for moving them here >>22109 and here >>22111 The rough numbers look fine to me. The task is split up. The eyes and main brain determine a path to move any limb or all of them to go somewhere. It sends only end point placement signals for the limbs to the limbs. (basically an example is move foot one meter forward at this speed, with a vector on how this movement starts so it can step over things)The limbs work out from these velocity, vector and end point movement instructions from the brain where to go and how to go. There's still plenty of bandwidth for fine tuning of the limbs by the man brain in cluttered areas or if it hits something with standard CAN2bus used for cars and built into some micro-controllers and chips.

>>23137 >The main technical issue I can see is the sensory nervous system I forgot the quote for the above comment

>>23636 >makehuman model I didn't try that, since people here told me these programs which can make models of human bodies are making them in a way that they are not printable. Can you cut it? I mean, removing the head seem to have worked. Can you slice it? This is exactly one of the main things that held us back for the last few years.

>>23644 It can save to stl format. i'm sure it can be modified to be made printable somehow. btw i just got my 3d printer so I'll give it a try once its done.

>>23644 Well, exporting from Makehuman and importing into OpenScad works, it's rough though. I didn't even know since a few month ago that I can use STL files in OpenScad quite fine. It was a mistake that I just asked around a few years ago how to do these things, instead of trying it out myself. And no one else did. Though, I also only have a PC for a year which can run Makehumans anyways. >>23645 Well if we can use models from Makehuman this whole thing is obviously much easier. This just wasn't known on this board. This whole thing went off the rails, when I tried to slice the files of SophieDev a few years ago and ran into a lot of problems. Then people told me you can't use models from the net and just cut them up, and also no STL files...

>>23646 >Then people told me you can't use models from the net and just cut them up, and also no STL files... You can do whatever you want to a 3d model really. I think I'll make the anime girl head tomorrow though. i tried today but I didn't want to watch the whole tutorial and skipped some parts and it ended up looking boxy. I'm mostly used to blender but i tried freecad and i made an organizer box with it. its not too bad coming from blender. don't know about openscad, solidworks, etc... but i think freecad should be fine really.

>>23646 >Makehuman modeling Related: >>23654

>>23636 Nice job Pete. Good luck with your project work! :^)

I've been trying to follow the anime girl head tutorial but its just so tedious that it must be done vertice by vertice. I'll get it done eventually though.Kind of sucks nobody could spare an anime girl head anywhere under cc0 or something like it. I guess you're not supposed to use MIT on 3d models cause I can't find a single one.

>>23756 Yeah, that's unfortunate. I planned to pay someone on Fivrr to make a individual model of a head for my waifu. It's partially like legal child "exploitation" of some children in Pakistan. I also have ideas on how to make a software that would create heads from pictures, but I won't share the idea before I even tried it myself. Artbreeder makes very beautiful faces, which may look somewhat anime-like, quite normal but with bigger eyes (picrels).

Just doing some prototyping and working on a model to work things out. Here's as kind of meter for the size of the motors for the hips. It's not much, but should be fine. This is a 1.40 meter body with a 12 cm disc (orange) which could be the equivalent of a internal servo. The 8318 brushless motor has 9.2 cm (red disk) in size and will additionally need to be hold in place.

>>23778 Size estimation for the batteries. Works as anticipated. I knew why I didn't want to look into this. Maybe I have to make my waifu a bit taller, but not for legal or social reasons... That said, this is just me trying to fit all of them into the thighs. I might have to reconsider that, though there are many factors I could change, so I'm not too worried at this point. They would maybe fit in, but then there's no space for the motors, hmm. Related: >>23781

>>23778 >>23782 Excellent. These type design sketches are a great way to begin roughing out general layout goals. They always will need further refinements at this stage (so don't 'marry' them yet :^), but it puts some 'stakes in the ground' to begin working around. I thought about this last night and I'd like to be able to juggle around proxy meshes inside the robowaifu's volume to be able to squeeze everything together, then have some kind of auto-generated internal support framework to 'stitch' it all together. Then inertial moment calculations could be done on these assemblies to 'close in the error bars' on the bounds needed for torque from the actuators, etc. Thanks NoidoDev. >=== -minor edit

>>23778 I went on working on size comparisons (picrels). Looking if things fit into each other. I used a female pelvis from Thingyverse, which comes as several parts to keep it printable. Then I ordered these parts more or less correctly in OpenScad (took me the whole day). Now I can make comparisons between it and the size of the 3180 motor, including the estimated size of a gearbox, for example. The current example width of the pelvis is 31 cm, which I measured in my Makehuman model >>23646 This doesn't mean I would use that pelvis model for my waifu. I already tried to model one once before, and I will use some variant of that or try again. Though, in that next try I will have that real model as comparison in the same file, and it will be done in OpenScad not Solvespace. Related to the pelvis (2021): >>12905 >>14567 Related to the current work in the 3D modelling thread: >>23901

>>23907 Looks like you have a workable setup for dealing with real-world units now. Thanks for the update, NoidoDev! :^)

>>23909 It turned out to be a bit more difficult. All these bones and then a meter, getting everything into the right orientation. But, I can use projection() to make the bone structure into a plane. I also thought more systematically about how I want to do the actuation of joints. Especially the stringed actuators, and trying to find a way to plan it (picrel one). Then I also started to work a bit on a idea I had for changing the orientation of the servo in the hip, which might work by having anther piece underneath which can be moved by another servo and that would change how the servo above is oriented (other picrels). This isn't fully worked out yet. I would need to place the bolts to which the servo is indirectly connected in a way that the orienter disc piece can rotate but still be closed. So it's rather complex, even to explain. I found a simple way to do it, but then it could only rotate for 20-25 degrees, and that's not enough. Not sure if this is going to work at all or if I overlooked some flaw in that idea. I'll go on with it for now. Also, I might get my K80 tomorrow or at least soon, but Amazon has delivery problems in parts of Europe, so I won't have the cooler I need for it. The GPU from USA came faster, then Amazon even sends out orders. I also started learning Emacs for circa the 8th time. I forget stuff after not using it. I also watched some anime for relaxation and weening me off from watching too many YouTube videos.

>>23962 That's looking really good NoidoDev. Clever design work.

>>23907 That's really nice. Have you got a link to the file on female pelvis from Thingyverse?

>>24000 Well, it's the first if you search for female pelvis: https://www.thingiverse.com/thing:4946668

> 3D printers to produce tensegrity structures I posted this originally, I'm basically working on this and we discussed something related, but I forgot about this here completely: >>5448

>>24026 Thanks for pointing bringing that to attention here again NoidoDev. Tensegrity will surely be an important topic when we work on full-sized robowaifu designs.

>>23907 Still on it. One side is enough, since it will be mirrored. Related: >>24050 (not sure which thread to use, the other one is about modeling and mainly used for discussing programs and concepts. I think prototypes should better go in here.)

>>24092 >I think prototypes should better go in here. While I agree with you in general here Anon, this is also exceptionally-pertinent to a specialized thread (Skellingtons, >>200), while this thread is more of a general. But I defer to your judgement on this (above even my own), b/c you clearly pay good attention to trying to keep the board organized better. Nice work BTW, drive on NoidoDev! :^)

>>24107 >exceptionally-pertinent to a specialized thread (Skellingtons, >>200), while this thread is more of a general. I understand, but I kind of made the decision some years ago already, to use the prototype thread for anything I make and encourage others to do the same. The ones like the skeleton thread are more for finding models of such or sharing more general info about it. One problem is, that my modeling can at any time switch to another topic like e.g. artificial muscles or servos. Also, there are many updates, so any general info would get buried between these many updates on our work. We can of course add crosslinks from time to time. For me the distinction is "others doing something" and general infos vs "one of us doing something".

>>24112 Fair enough. You're good at organizing things.

I made it so you can talk to the waifu(orange pi 3) https://youtu.be/EJ_u63mdeNk I'd appreciate if someone can have a look at the script and improve upon it. Ideally the transcribing and speech synthesis would happen on the orange pi 3 itself instead of aws and ideally it'd activate by saying a phrase instead of having to press a button. But I'll leave it there for now.

>>24177 Good that you're still on it. It's still way to go, though.

>>24177 I would recommend setting your goal to avoid using the cloud at some point. Look forward to seeing your progress Anon! Cheers.

>>24177 nice, i could probably make a copy of arecord that listens for the sound to peak before starting a recording so you can just run that in the background and dont need to press a button, youll just need to check if there are audio files to process

>>24179 >>24182 >>24186 I got some servo motors and I want to move on to the hand. I can't get a 3d printer that works ff. I want to keep this thing in motion and don't want to get stuck on just that. I might go back to it later but again I'd appreciate if we could share some of the workload for this thing and somebody else could focus on that. I am aware that you can capture certain sounds so you could activate it without a button and stuff.

>>24187 >I want to keep this thing in motion and don't want to get stuck on just that. I might go back to it later That's the spirit Anon. Keep moving forward.

>>24186 >>24187 was easier than expected, i have a shitty mic so you have to play with the noise threshold value yourself to see what works best, you can just run this in the background instead of using arecord >=== -code consolidated to: (>>24248)

>>24192 Nice, glad to hear it. timeout -= ! ! timeout; Lolwut. Heh, might want to double-check that statement Anon. :^)

>>24193 lol just a way to turn it into a bool, its like doing ( timeout > 0 )

>>24192 alright thank you. That looks like it came out chtuluz mouth lol.

I will look into the code for recording either tomorrow or the day after tomorrow. Thank you again. But as far as alternatives to aws for text to speech and speech to text i've looked into them but I haven't found something that's good tbh. There's espeak for text to speech for example but it sounds like microsoft sam tier.

>>24202 np, this ones more useful you dont need to set the noise threshold, it will calibrate it on its own when it starts and will use timestamps as filenames and prefix the file with REC: when its done recording so you dont end up using one thats in progress by mistake, just put the program in its own folder and you can just use `ls dir | grep '^REC'` in your script periodically to check if there are recordings to process and delete them when done >=== -code consolidated to: (>>24248)

>>24205 Okay so since I'm still awake I decided to give it a try and I got to say had it worked it would have been amazing. It said calibrating and everything haha. Excellent stuff you did just now. The only thing is when I played it back it was mostly just static noise so it didn't really work.

>>24206 its just raw audio files, use aplay -f S16_LE -c2 -r44100 to listen to it, you could use something else to convert it to from raw to some codex format like mp3

>>24206 im stupid, this should make actual .wav files instead of just raw data >=== -code consolidated to: (>>24248)

>>24210 It works great. It records a wav file. Now the only thing that is missing is that it records from start to finish no matter what.

>>24210 Thanks Anon, nice work. >"no audio device or its chinese" Lel'd :^)

>>24219 you mean its too sensitive? noise_threshold *= 2; is the sensitivity change it to 2.1 or 2.5 or whatever works until its only recording when you speak, i dont know how to do this properly, its supposed to be logarithmic and depends on the mic volume probably

>>24219 this should be ok now, made it visualize the audio so you can see the threshold and timeout and figure out what ratio you should use for your own mic, mine just picks up a lot of background noise, the bars are the amplitude | is the threshold and the number is the pause delay >>24220 feel bad having to clog the thread with code you can delete the previous code blocks since its just the same thing >=== -code consolidated to: (>>24248)

>>24219 >>24231 ok last update to fix a mistake, was listening in 16bit but was reading in 8, this has the full range now so theres no excuse now, just change the sensitivity until you get the right behavior // gcc -o brecord brecord.c -ldl -lm -lasound #include <alsa/asoundlib.h> #include <stdint.h> #define SENSITIVITY 2.5 // sound multiplier to trigger recording #define PAUSE_LIMIT 5000 // ^ delay for threshold to be exceeded when recording, // if not exceeded within delay time then recording ends struct wav_header { char fileid[4]; /* chunk id 'RIFF' */ uint32_t chunksize; /* chunk size */ char waveid[4]; /* wave chunk id 'WAVE' */ char fmtid[4]; /* format chunk id 'fmt ' */ uint32_t fmtchunksize; /* format chunk size */ uint16_t fmttag; /* format tag, 1 for PCM */ uint16_t nchannels; /* number of channels */ uint32_t samplerate; /* sample rate in hz */ uint32_t navgbytespersec;/* average bytes per second */ uint16_t nblockalign; /* number of bytes per sample */ uint16_t nbitspersample; /* number of bits in a sample */ char datachunkid[4]; /* data chunk id 'data' */ uint32_t datachunksize; /* length of data chunk */ } __attribute__((packed)); int main() { snd_pcm_t *dev; if ( snd_pcm_open( &dev, "default", SND_PCM_STREAM_CAPTURE, 0 ) < 0 ) { fprintf( stderr, "no audio device or its chinese" ); return 1; } // audio settings, guessing default settings unsigned int samplerate = 44100, dir; snd_pcm_uframes_t frames = 32; snd_pcm_hw_params_t *params; snd_pcm_hw_params_alloca( &params ); snd_pcm_hw_params_any( dev, params ); snd_pcm_hw_params_set_rate_near( dev, params, &samplerate, &dir ); snd_pcm_hw_params_set_format( dev, params, SND_PCM_FORMAT_S16_LE ); snd_pcm_hw_params_set_channels( dev, params, 2 ); snd_pcm_hw_params_set_access( dev, params, SND_PCM_ACCESS_RW_INTERLEAVED ); snd_pcm_hw_params_set_period_size_near( dev, params, &frames, &dir ); if ( snd_pcm_hw_params( dev, params ) < 0 ) { fprintf( stderr, "device config failed" ); return 2; } // im retarded audio settings has to be written to the file for .wav struct wav_header Header = { .fileid = "RIFF", .waveid = "WAVE", .fmtid = "fmt ", .fmtchunksize = 16, .fmttag = 1, .nchannels = 2, .samplerate = samplerate, .navgbytespersec = ( samplerate * 16 * 2 ) / 8, .nblockalign = ( 16 * 2 / 8 ), .nbitspersample = 16, .datachunkid = "data" }; int size = frames * 4; char *buffer = malloc( size ); // calibrate: 5s noise check to set threshold int period; snd_pcm_hw_params_get_period_time( params, &period, &dir ); int noise_threshold = 0; long len = 5000000/period; int *noise_buffer = calloc( len, sizeof(int) ); puts( "CALIBRATING\n be quite" ); sleep(1); int cols = 50; int maxamp = 32768; int barsegment = maxamp/cols; const char bar[50] = "=================================================="; for ( int i=0; i<len; i++ ) { int ret = snd_pcm_readi( dev, buffer, frames ); if ( ret == -EPIPE ) snd_pcm_prepare( dev ); else if ( ret < 0 ) fprintf( stderr, "error\t%s\n", snd_strerror(ret) ); noise_buffer[i] += ((int16_t*)buffer)[0] > 0 ? ((int16_t*)buffer)[0] : -((int16_t*)buffer)[0]; noise_buffer[i] += ((int16_t*)buffer)[1] > 0 ? ((int16_t*)buffer)[1] : -((int16_t*)buffer)[1]; noise_buffer[i] /= 2; int ampbar = noise_buffer[i]/barsegment; printf( "%*cQUITE %4.4d\r%*.*s\n", cols, ' ', i*period, ampbar, ampbar, bar ); } for ( int i=0; i<len; i++ ) noise_threshold += noise_buffer[i]; noise_threshold /= len; // average of backgraound noise noise_threshold *= SENSITIVITY; free( noise_buffer ); printf("\nnoise_threshold=%d\nDONE\n", noise_threshold ); sleep(1); FILE *fp; int timeout = 0, rec = 0, filesize; char filename[32]; while (1) { int ret = snd_pcm_readi( dev, buffer, frames ); if ( ret == -EPIPE ) // timing fuck up snd_pcm_prepare( dev ); else if ( ret < 0 ) fprintf( stderr, "error\t%s\n", snd_strerror(ret) ); int amp = 0; amp += ((int16_t*)buffer)[0] > 0 ? ((int16_t*)buffer)[0] : -((int16_t*)buffer)[0]; amp += ((int16_t*)buffer)[1] > 0 ? ((int16_t*)buffer)[1] : -((int16_t*)buffer)[1]; amp /= 2; int ampbar = amp / barsegment; printf( "\033[%dm%*c%d\r%*.*s\n", rec*31, noise_threshold/barsegment, '|', timeout, ampbar, ampbar, bar ); if ( amp > noise_threshold || timeout ) { if ( !rec ) { time_t t = time( NULL ); struct tm *tm = localtime( &t ); sprintf( filename, "%d_%.2d:%.2d:%.2d.wav", tm->tm_mday, tm->tm_hour, tm->tm_min, tm->tm_sec ); fp = fopen( filename, "w" ); filesize = fwrite( Header.fileid, 1, 44, fp ); rec++; } timeout = amp > noise_threshold ? PAUSE_LIMIT : timeout ; filesize += fwrite( buffer, 1, size, fp ); } else if ( rec ) { char fileDone[32]; sprintf( fileDone, "REC:%s", filename ); rename( filename, fileDone ); Header.chunksize = filesize - 8; Header.datachunksize = filesize - 44; rewind( fp ); fwrite( Header.fileid, 1, 44, fp ); fclose( fp ); rec--; } timeout -= !!timeout; } }

>>24248 It works! I changed the sensitivity to 10 Amazing work you did there anon. Thank you!

>>24231 >feel bad having to clog the thread with code you can delete the previous code blocks since its just the same thing Haha, don't feel bad Anon, it's fine! I think I'll go ahead and do so however, not because I'm care about too much code ITT -- but because I want other anons to study known-working code. I'll come through later and tidy things up a bit. Cheers.

Failed print but, the memory foam chest is really fun to handle! Feels like soft girl in a leather corset. It's kind of nostalgic. The current problem is that when you get too agressive, it comes popping out the top kek. Overall, robot breasts failed successfully!

>>24273 Interesting. Is this the soft filament you're using? What about cladding the entire thing in a spandex top similar to your suggestion (>>24197) ?

>>24274 Yes 98A TPU, doesn't print tall designs with one layer walls well. Forgot that fuzzy skin is really necessary for thin TPU prints. I actually have that leotard coming in the mail. The idea would be to have the leotard be her skin and TPU for interal reinforcement, like a skeleton. Memory foam being her "fat" to make her fun to squeeze. I just wanted to test it with TPU skin as a proof of concept. It inspired a whole new world of ideas.

>>24275 >I just wanted to test it with TPU skin as a proof of concept. It inspired a whole new world of ideas. Excellent, glad to hear it! Look forward to seeing your new progress mate. :^)

>>24278 Leotard just came in and now I can confirm the need for a printed skin to prevent her from being lumpy.

>>24290 Heh, one step at a time. If you're thinking of manufacture, then it's reasonable to assume that every model's outergarment 'skin' will be custom- cut & stitched to fit.

>>24275 What about those tpe dolls in aliexpress though

TPU struggles with tall hollow prints. Too many failed prints, going back to trying to figure out mesh and tension based designs.

>>24294 You might be the same guy who bought a cheap printer and now has problems. Don't make the same mistake again. Look in some forums and r/sexdolls for what sellers are reputable and for what to look out for. That said, I need something that moves and has some mind. I don't need a inanimate body for "entertainment". Also, I would rather go for silicone and also avoid these bad hand and foot designs where digits can bend in all directions. Just puts me off. >>24377 >TPU struggles with tall hollow prints. Too many failed prints, going back to trying to figure out mesh and tension based designs. Didn't you have a program for nTopology? That might help. Thanks for trying out stuff. I'm quite demotivated at the moment. I'm still working on the pelvis, but I have a hard time to get anything done. I have a long list of things I should be doing and way to often I run into hurdles or things go wrong, I get annoyed or demotivated and start doing something else. But, I try to improve my mindset and see challenges more positive. Ideally I should switch to another task which I need to do, if I get stuck with one. But I'm trying to avoid things like these where some chores.

>>24379 Wdym don't make that mistake again. Everyone recommends an ender 3 and I have an ender 3. I drove to another city and dropped it off at the seller's business to have it fixed. I'm not proud of that but I don't want to scolded cause I've put too much effort into that junk to be scolded on top of that. The seller also said that any extra parts are not included in the warranty. I also don't understand what is everyone's deal here really. I put forth the proposal that we try profit off this thing and you guys treat like its unrealistic without elaborating further. Really how do you think companies start? You think some rich guy with a top hat has control of everything? Well they do but that's not exactly how it works.Maybe there's a misunderstanding cause some people here are from europe and things might work differently over there or something.

>>24382 >Wdym don't make that mistake again. My point was, don't buy the cheapest stuff and then it turns out to be trashy and require extra work or it's a letdown. Going for the cheapest dolls is probably not a good idea. >I don't want to scolded cause I've put too much effort into that junk I'm not scolding you. Especially not for going to get it fixed. Since this was an option and worked out it was a good choice. But maybe it wasn't worth the amount you saved? >I put forth the proposal that we try profit off this thing and you guys treat like its unrealistic without elaborating further. We're in the wrong thread here, I think the arguments were mentioned in the business related threads.

>>24383 yes I've put in more money than initially. I spent like $40 in the cost of transportation or so just to get it fixed, not to mention the time. But I also bought an anet that wouldn't print a kingroon that came with a broken screen, I returned those for a refund ofc. If I could go back I might have paid extra an ender 5 maybe. But its impossible to tell because nobody gives legit advice about it. Maybe the ender 5 is as garbage as the ender 3 who knows.

>>24377 >going back to trying to figure out mesh and tension based designs. Excellent. I'm not glad to hear about the struggles, but as a trained engineer you're aware that's all just part of the game towards progress. As discussed previously in the MaidCom thread and elsewhere, tensegrity is an important design concept for us to realize full-sized, 145cm+ robowaifus. And our particular take on it here of meshtegrity holds much promise for ease of manufacturing, low material costs, low mass (which effectively benefits every other aspect of the robowaifu design & engineering endeavor). Drive on! :^) >>24379 Glad to see your efforts, NoidoDev! You'll figure this thing out, just keep moving forward. Cheers. :^)

>>24388 >Meshtegrity That's exactly it, working on that same concept once again. Now I've realised that learning about clothes and treating the mesh as a sort of textile is the way forward. Focusing on unraveling polygonal meshes was leading me astray. Also, staples work perfectly to connect the seems, better and easier than sewing or tying with twine. Planning on making a thread dedicated to the concept once more details are ironed out. Thanks for your faith.

>>24396 OUTSTANDING! I believe you have the correct path forward indeed Kiwi. I'd suggest you simply create a full body now (leaving aside the head, hands, and feet) at ever-larger scales until you're at full size. Then it should be a simple matter to scale that backwards down to a more-feasible 1m size for our other square-cube law demands ATM. >Thanks for your faith. Heh, let us thank the Lord. The gift of faith itself comes from Him. :^) Keep moving forward.

I'm trying to get a cycloidal drive design working. This here >>24380 with a casing and some added rollers to reduce friction (picrel). The I also want to try this one >>24381. Also trying to get some AI generated heads without hair and then let another AI create a 3D model >>24392. >>24396 > treating the mesh as a sort of textile is the way forward. Does this mean you're printing it laying down, 2D?

>>24398 >Just create a full height body On it, learning along the way. This is full scale. Upper thigh success.

>>24401 Yes >>24436 Best to print thicka and slow.

>>24437 Question about the program or workflow: >>24444

>>24437 nice but why make it like a mesh? Is it the 3d printers limitation or because of the weight or...

>>24436 >>24437 Dude this is brilliant work. BRILLIANT! :^) I'd love to see the printed flats before assembly, Anon. I assume you modelled them in situ, then cut them apart? BTW, if you successfully pull off a realistic Aigis robowaifu, your robowaifu designs are going to be very popular! Keep driving on Kiwi. Cheers. :^)

>>24452 Weight and possibly making it squeezable and generally deformeable. The material needs to go somewhere. Foam e.g. in a sponge has air bubbles.

>>24437 Yes great work

>>24452 It is faster to print and more durable. >>24462 I'll be sure to take pictures of everything when I make the Meshtegrity thread. I unwrapped a model of Aigis. I'm highly hopeful to have a full Aigis. Still learning but, it's a fun and exciting new direction. >>24472 These are also correct. The end result feels so much better to squeeze compared to normal prints. >>24474 Thanks

>>24401 I made some progress, I hope I can try it soon with a motor. But you know how it is, the details take time and it always turns out to be harder. I still should add a place for my hall sensors and need to make it printable. This is just a kinda "random" bldc, btw. I might use it in the elbow or above the the pelvis to make the spine rotate against the pelvis. >5010 360KV/750KV High Torque Brushless Motors For Rc MultiCopter Four-axis six-axis multi-rotor aircraft

>>24477 Probably time for some test prints. // TODO // checking if x-offset is a problem (yes) // top tap // hall sensors adjustmens // measurements and adjustments // late: testing with changes in the vars // opt: pillars to connect top to bottom // opt: noise reduction for the vent holes // opt: top tap maybe with noise reduction

>>24477 >>24502 Wow, this seems exciting NoidoDev. Really looking forward to seeing you progress with this! Cheers. :^)

Progress update, finally have a good enough full scale hip. This part is the same size as a 150cm/5ft tall size S/8 (90cm hip measurement.) Actually bigger than Aigis, would be able to wear normal women's clothing. The panels for her backside need to be made more like the front for better hands of fun.

Chest came out goofy

>>24530 >>24533 Excellent stuff Kiwi! What you are doing in effect is patch modelling. NURBS is the king of patch modelling. If you're interested, I'll gather up some links on the topic. Given your new, wonderful, direction I'd highly suggest you master this craft. Soon you'll be printing lots of tightly-interlocking patch flats that can rapidly be joined together into beautiful, strong, robowaifu shell meshes. Cheers. :^) >=== -prose edit

>>24530 This is really great stuff.

Speaking of modeling and mushing things around to make them fit I saw this link, these guys have everything 3D, that is a brief review of several 3D modeling programs that you can use objects and pictures and combine them into 3D objects. https://all3dp.com/2/best-3d-scanning-software-tools/ Some of these are free and some not. MeshLab looks interesting but most of them look fairly good.

>>24542 I'd be greatful for the help. I've learned a lot through trying, but learning from those who already tread my path would save much time. >>24552 Thanls mate

>>24557 There's a link I forgot. I found this looking for 3D software that could take photos and turn them into 3D stuff. At the risk of being wordy, this software started out as free called sculptris. It's based on the idea of modeling clay. You push it around, squeeze it, pull, etc. I would think you could get something done fast with this sort of interface. This guy who wrote this was hired by a company and they made a super involved program based on this called z-brush. MAJOR effects type stuff but expensive. Now they have a free version with reduced options based on the original free version. The first link is for the original free version. The second link is for the bigger company zbrush based free version. I haven't downloaded the big newer one because you have to sign up ad I very, very rarely sign up for anything. The first one is no sign up for anything. Have a quick look at these I think you'll be impressed and it may be a good fast way to get things done. https://download.cnet.com/Sculptris/3000-6677_4-75211273.html https://www.sculpteo.com/en/glossary/sculptris-definition/ An impression. There's a ton of these but none of them, except maybe super expensive ones, do everything. But it appears to me with brief looks at features you could load one, do some certain aspect of manipulation, then load another to do different functions, then maybe save in a further one set up for printed or whatever. The open source ones do an incredible amount of stuff but the documentation seems to be lacking and they look difficult to use, but...they're free so...

Yet another step closer. This is based on my recreation of her in game model and matches Aigis in game dimensions. Using clothing patterns is better overall compared to this method. Slowly but surely getting better.

>>24557 >I'd be greatful for the help. I've learned a lot through trying, but learning from those who already tread my path would save much time. OK! I'll begin scouting around for Blender-friendly (or just general) resources on the topic. Most of my experience is with Maya, and it's not something I suggest anons here focus on (unless you're more about industry work, than robowaifu work). Blender should be our goto for the forseeable future, I predict. >>24564 Blender has a rather good sculpting system Grommet. [1][2] The design is clearly taking it's cues from ZBrush and Mudbox (these expensive packages you speak of). --- 1. https://www.blender.org/features/sculpting/ 2. https://docs.blender.org/manual/en/3.6/sculpt_paint/index.html >=== -fmt edit -add'l reference

>>24571 Good materials economy, with improved structural rigidity. Nice work Kiwi. At some point (probably after you begin your new thread), we should pick back up on the tension part of our meshtegrity design work. I have a couple of ideas more recent than our last dialogues on the topic to discuss then. Cheers. :^)

>>24557 I'll just throw things out as a hodgepodge for now Anon, just to get you familiar with the ideas quickly since you're in the midst of things r/n. Later on, I'll plan to go back through and consolidate/edit things into a nice post or two in your new mestegrity thread. Here's a quick video from the king of 1-minute Blender jewels: > https://www.youtube.com/watch?v=uideuXvJNX4 https://www.youtube.com/watch?v=1zNfh_g8jXM https://www.youtube.com/watch?v=6yRfIYjNqbQ https://www.youtube.com/watch?v=3OfShkLcj-c https://www.youtube.com/watch?v=s9l68RY5vLM

>>24576 >Move on to the tension aspect. That's precisely what I'm working on now. My current plan is to ßtrategically place rods o add tension without interrupting the squeeze zones. Any ideas are appreciated. I want to have a firm great before making the thread.

>>24578 >That's precisely what I'm working on now. Nice synchronicity then heh. My idea has two parts, for starters: 1. You'll need some kind of hardened structural ring system printed out that matches the 'holes' in your shell mesh. For example, the neck, shoulders and hips gaps in the example assemblies you've already pictured. These structural rings will snap down into these gaps and serve three purposes: a. Rigidize the patch flat's joint seams together. This will make the shell's mesh more durable as a final joined assembly, and you won't be relying strictly on the staples alone. b. Provide strong, structural hard-surface attachment points for the most significant of the overall tension lines to emanate from there down into the intra-shell volumes. c. Provide strong, structural hard-surface installation points for further exterior assemblies, such as hip-actuators/legs, and shoulder-actuators/arms. >tl;dr Don't skimp on the plastic for these gap rings! They need to be strong. :^) 2. As part of point b above, you'll need the tension line cords to be weaved through these rings and down to an interior, 'floating' set of tension rings through which the tension lines cross in and out. The primary stresses involved will be applied to these interior floating rings, and back out to the structural rings fastened down into the shell's patch gaps. The cumulative effect will be to strongly tension all these gap rings inwards together; significantly enhancing their effectiveness individually by creating an 'invisible', structural fascia-tension-like, 'reverse-skeleton' between them all; consisting entirely of tension lines joined together through the floating interior rings. An actual articulated endoskeletal system will also be in place as well, supporting things like the chest cavity's central computing breadbox, the pelvic volume's batteries, power and data cabling, cooling lines, actuation cabling, &tc., as well as underlying the general tensegrity suspension for the entire shell, and handling dynamic forces out through to the limbs. Conversely, the tension forces out to and around the shell's patch meshes' inner surfaces will be smol by comparison, just 'snug fits'... to mostly-evenly draw the surfaces down towards the interior volume for compressive strengthening of the entire shell. Which is, of course, the primary point of the whole exercise. To wit: ''exceptionally-high strength and rigidity out of very lightweight & inexpensive materials; yet with a strong conformity to humanoid structural dynamics" (ie, skellingtons, muscles, ligaments, and fat). :^) >My current plan is to ßtrategically place rods o add tension without interrupting the squeeze zones. >Any ideas are appreciated. So, as before, I'd recommend using cords to apply the tension out to the shell's mesh patches. Their natural 'give' is a real benefit for a robowaifu shell design you want to be snuggly for anon. OTOH If you also do cross-force, rigid rods literally suspended and 'floating' within the shell volumes (as is often seen in more-classical tensegrity designs), then that's another matter entirely and may prove to be a great addition to the final meshtegrity working solution. Always keep manufacturing complexities in mind with your design approaches Anon. My current vision for the multiple rings arrangement simply involves loosely weaving the cords back and forth by hand; and finally, gently but firmly cinching everything down tight to apply the forces out evenly and concurrently during assembly. This should aid in avoiding any crumpling of the meshes by uneven force applications, etc. >I want to have a firm great before making the thread. The """perfect""" is the enemy of making any progress whatsoever haha. :^). Please remember I can always go back into the OP and edit it's subject and text. Images OTOH can't be edited, so choose wisely! :^) I hope my post is understandable as-is, Kiwi. Don't hesitate to ask for further clarification if needed. --- https://all3dp.com/2/blender-nurbs-modeling/#i-5-nurbs >=== -prose edit

>>24578 you have lots of seams so if you just make the corners into a sizable L, when you put it together you would already have a stiffened interior

>>24578 >>24580 i dont know how to explain it better

>>24580 >>24581 Great point Anon. And I wouldn't worry, I expect Kiwi understands you clearly.

>>24579 >Solid rings for mounting and cords for tension. Based and tensegrity pilled. Will work on rings once the basics are ironed out. Honestly have high hopes for your concept. >Perfect is enemy of the good I'm finally starting to undrstand :^) >>24581 Very clear, nice illustration. Definitely a good concept in general. Printed out panels for a full scale Aigis. Made them thicker to make her sturdier. The tension in the resultant structure tore the staples out of the seams. I'm now moving towards a tensegrity structure with the mesh replacing the strings. Would of had this next version done today but my PC crashed and my drivers got corrupted. Switching to Pop!OS for Debian stability tomorrow. Fingers crossed for a swift and smooth transition so I can use CAD and Cura again. I'm so close to having a viable concept.

>>24665 These are looking great! Really pro design work Kiwi. >Will work on rings once the basics are ironed out. Honestly have high hopes for our concept.* FTFY. :^) I do too! I expect this will prove a breakthrough for low-cost shell design work, and will be every bit as flexible as NURBS patch modelling has proven to be in the 3D design world. We're all gonna make it! :^)

>>24571 You missed the kitty hole. The most important part of the waifu.

>>24665 >tensegrity!!!

>>24671 Printed it as thin as possible for a quick sanity check to make sure the body matches Aigis. A floopy mess with staples falling out now. For one moment though, it was very close to Aigis' body. >>24676 She is being built for love, not lewd. >>24681 >Tensegrity is the future! :^) (Until something better comes up.)

>>24691 >A floopy mess with staples falling out now. How about using short bits of string to temporarily hold the parts together? Then you can probably fasten everything better after that point.

>>24691 That is great. Even if it's not optimal right now you, by making something, are seeing what needs to be done. 10% of something is way better than 100% of nothing.

>>24694 It depends. If it can hold two big motors and gears,components, etc... it was useful. Otherwise it was a waste of time desu.

>>24789 >Otherwise it was a waste of time desu. "If you don't have anything good to say, then don't say anything at all" my mother always told me.

>>24691 Looking forward to seeing this fully-assembled Kiwi. I presume you can use the wooden dowels to fasion an internal 'support stand' of sorts for the time being?

>>24692 >Affix parts together before permanetly joining them. Good idea. >>24694 Thanks, I look forward to you putting your theories to test. Part of why I'm posting so many failures is with the hope of inspiring others to dare to fail. >>24789 It will hold anything it's designed to. I fully plan on having a mounting system. >>24833 Sure thing, I used some failures to quickly mock up how meshtegrity works with dowels haphardly stabbed into the mesh. Without proper tension, she's floppy. Under tension, strong and surprisingly nice to hug. (Aside from the dowels stabbing me.) It's like hugging a pillow with a balloon that won't pop or a water pillow that's overfilled and weighs nothing. Thanks for the idea. These quick and easy tests are fun.

>>24838 Excellent. >Under tension, strong and surprisingly nice to hug. Yes. And I predict that once you have a full set of support rings in place, with internal floating rings tightly tensioned in, it will be better still. Further, wind in some snug-fit tension to the shell mesh and 'Bob's your uncle!' Godspeed Kiwi. Cheers.

>>24839 >Support rings Can confirm they are absolutely necessary. Tension made her all blocky and deformed. On a good note, meshtegrity works. It works really well, just needs rings to force her body to be curvy.

>>24850 >Tension made her all blocky and deformed. You're probably going to have to consider some sort of 'ribcage-like' support spars underpinning the mesh structures. Most of these can very likely be simply printed in-place, I'd expect. You're making great progress Anon. Drive forward! :^)

>>24994 I'm often good at sketching things out, but might get frustrated over optimizing things when it gets more difficult. So let's leave it to that (maybe just for now): for(pos1=[0:10:60],pos2=[0:60:360]){ rotate([pos2,0,0]) translate([0,sin(pos1),0]) rotate([pos1,0,0]) translate([0,40,0]) cube([pos1/2,5,pos1/(pos1/10)]); } midhole=10; for(pos1=[0:10:60],pos2=[0:60:360]){ rotate([pos2+35,0,0]) translate([0,sin(pos1),0]) rotate([pos1*1.005,0,0]) translate([pos1/2.5,0,10]) cylinder(45-midhole,1,1); } Related: >>24749

>>24996 Interesting, thank you!

>>24980 >>24981 [Orchid's original design notes.] >>25037 [Further notes and function list.] It took me a little while, but I sketched out the improvements I had in mind for Orchid's design over what I had in mind before. I'll start with the legs, since every other decision I've made for her design stems from the changes I've made there. Originally, I had her leg design very simple and minimalistic, employing chain drive and rack and pinion, then later moving fully to chain drive. I think I've got a good design for the shoulder mechanism, but the knee articulation suffered from unnecessary complications. The chains were running over the upper leg and guided with pinwheel pulleys, which would have required me to build additional structure around the leg to prevent the fabric from interfering with the chains. But then I had an idea courtesy of ( >>25063 ). In short: hollow bones {pl.1, fig. 1}. By having channels running through the bone (and a cover plate, of course) I can completely conceal the chains and remove frame layer ii from the design, drastically reducing both design complexity and weight {pl.1 fig. 1.4}. Then I took the idea further and did the same thing for the knee {pl.1 fig. 1.1} and hoof {pl.1 fig 1.3} mechanisms, making it completely enclosed. It's also worth noting that I added leaf-spring suspension to the hoof, because I figured that such a thin design may not handle shock very well. Though I don't expect her frame to encounter too much shock pressure, I figured it was a simple way to keep things safe. Note that here I'm also introducing the concept of dual-layer gears into her design {pl.1 fig 1.2}, since it's the simplest way I could think of to translate rotary motion between distant gears. Now, as I write this, I do see some potential problems arising from running the wires through the bones as opposed to over them, and I may change this later (unlike chains, I probably don't need to worry about fabric gumming up the wires). Moving on. I was struggling figuring out how to design the torso frame properly, as my original thoughts would have resulted in something bulky and complex, taking up nearly the entire torso. While sketching up alternative designs for the lateral shoulder articulation, I came to four conclusions. First being that I really don't need all four legs to have independant lateral articulation. I only need Orchid to have the front and rear move independantly, but not left to right {pl.2 fig 1}. This allows me to reduce the number of motors in her design and free up space in her torso. The second is that I can reduce the complexity of the torso by reducing its size as much as possible. This didn't come to me easily, since Orchid's full torso size will clock in somewhere around 3~4 cubic feet, so I originally thought that I could take up as much space as I want. Reading back through the meta and seeing the note on existing robotic plushies ( >>25063 ) helped me dispell this, and lead to another idea I'll get to later. Thirdly, I decided that the best way to accomlish the simplest possible torso design would be to cram everything as high up as possible. The shoulder hinges, shoulder plates, and torso frame will be bumping right up against the top of the torso. This design reduces her torso weight and complexity dramatically. Finally, my original idea of using curved rack and pinion was fucking stupid. I'd need ridiculous amounts of precision to pull that off, otherwise they'll just get caught and gum up every few degrees. With the torso problem mostly solved, I had to revisit the biggest headache concerning her legs: lateral movement. While the idea is simple in concept, the reality is more complicated due to the fact that everything needs to be shielded from fabric and fill. Any standard rack and pinion design would catch the fabric constantly, which would necessitate hard shielding or another more complex idea I had earlier (don't ask). I found myself asking if I could just find some way to reuse the hollow bones idea here, when I realized that I totally can! {pl.2 fig. 2} Thus, the iron age began. I have a few more ideas for reducing the torso frame's size even further and streamlining its design (i.e. raising the shoulders slightly higher against the frame, then moving the lateral racks to the top), but I'll flesh those out at a later date. >=== -patch crosslink

>>25180 Part. 2 Now then, onto the biggest headache of all: the head. heh There's no two ways about it, an articulated head means swinging a big lever above the torso with a massive mechanical disadvantage, so simple and light goes from being a design choice to a design requirement. Further complicating matters (who would have thought that making things simple is so complicated? Not this dumbass. I'm starting to like the challenge, though.) is that there are a set number of objects that must be in the head, for human interface purposes. Eyes, ears, a mouth, etcetera. The original design I presented to you didn't include head tilt, only featuring neck tilt and rotation. I didn't think it was necessary at the time, but I came to realize that having no independant head tilt would make several things very awkward, including but not limited to several cuddling positions. It took days and several increasingly ludicrous design ideas until I finally reached the design you see here. I cannot think of a better way to keep every point of head and neck articulation as simple as possible while also keeping the motors localized in the torso. The neck tilt {pl.3 fig. 1} will be driven by linear rack and pinion, as opposed to curved, and use three hinges. Note that I placed the rack on the top and not the bottom, this is because I want Orchid to be able to lower her head (at least) to the point where the neck is level with the torso, and this is the easiest way to do that. The head rotation and tilt {pl.3 fig. 1.1} will be contained entirely in the neck itself. In short: rotation motor is fixed to the frame, and tilt is fixed to the rotation shaft, so the hinges on the platform {pl.3 fig. 2} are always aligned. As for how the tilt shaft will stay in place... I'm sure it'd be fine if I glued a paperclip to the rotation shaft and made a loose coil around the tilt shaft. I'll also need an absolute torque monster of a motor. Yeah, this part's a bit of a work in progress. It's also worth noting that the rotation and tilt shafts will not be 3D printed. I'll just buy a couple of thin metal or fiberglass poles from the hardware store, cut them to length, and 3D print parts to fit them. It'll be stronger and allow me to keep everything in the neck as thin as possible. As for the head itself, I once again had several design ideas prior to this one. I was trying to figure out the simplest way to have a sturdy connection between the frame and all of the head components, when I had a thought: Does she really need a full head frame? After thinking about it, I realized that she kinda doesn't {pl.3 fig. 3}. Sure, all the parts will need isolation from the fabric, and I'll need to run wires, but I don't really need a hard frame structure to do those things. None of the required parts will be particularly heavy, and none of them are essential to frame movement. The only moving parts in the head will be the ears. I know she doesn't need that, but my autism demands that her ears be able to move. Thankfully, I can just use the lightest and cheapest motors available for that. The "structure" will quite literally consist of a couple paperclips glued to some fabric triangles. The weight is negligible and they only need to swivel, after all. The frame structure will only be a (hollow) horn, and a flat plate of something, both of which will connect directly to the fabric to better enable tilt and rotation. It's possible that I could get away with just the horn, but I'm not sure if the rotation will work very well that way. And, yeah, I've pretty much decided that Orchid will be a unicorn. It just feels right for her. Everything else, I believe, is quite straightforward. The remaining parts will be mounted to the underside of the fabric in the appropriate locations. It's worth noting that I'm leaning towards having the stereoscopic camera mounted vertically, as opposed to horizontally. This would allow me to place the third eye right inbetween the screen eyes, as opposed to having to keep forehead space clear and compensate for the curvature of the upper forehead.

>>25181 Part. 3: The autism grows. Now onto the total size and projected frame. Orchid's going to be a big girl {pl.4 fig. 1}. Bigger than necessary, actually. When I first came up with the projected measurements, I was going off of remembered estimates of average pony height from the show. As much as I don't like blaming others for an error in my own calculations, the evidence is clear: the people behind those estimates are fucking idiots. They measured height to the top of the head, whereas I was measuring to the whithers (this is the correct way for most quadrupeds, including equines). Now, I could take the approach that any sensible engineer would, and use the free opportunity to reduce her size. But you know what? I'm not going to do that. Orchid will be big and beautiful, an amazonian bulldozer of a mare. In concern to {pl.4 fig. 1 note. i}, the hypothetical future child is human. I'll spare you the ten-page essay on why I think centaurs are the very definition of a walking bio-logistical nightmare. Also, whatever fanfic author decided that the child of a pony and a human could be a satyr is a dumbass. Regarding the length of her torso, that's mostly just personal preference. Pretty much every depiction of a pony in art will have the legs and torso fit into one of four boxes: long rectangle, square, tall rectangle, and trapezoid. Tall rectangle and trapezoid are right out. Even though it'd reduce the size of the torso frame, I don't want Orchid to have awkwardly lanky legs. Long rectangle would just add more length and volume to an already massive design. Though it would provide more stability, it's frankly unnecessary due to her quadrupedal design and chonky hooves. Square is the only sensible option. Now onto the things I'm not showing. Regarding the fabric construction... there's no way around it, it's going to be very complicated. More complicated than obvious to the casual observer. Every cubic foot of volume that isn't taken up by the frame and components will be stuffed with polyester doll fill. Now, doll fill is very light, and can obviously mold to whatever shape is necessary. However, once you start measuring your design in cubic feet, you need to worry about gravity and post-fill packing. If the fabric layer was entirely hollow, the fill would, sooner or later, start to settle to the bottom, and in some cases, pack itself into a ball or into corners. The only sensible way around this is to sew partitions into the fabric, which will prevent the fill from doing this. This is especially important for the head, since it has so many components and will mostly lack a hard frame. I need to keep every cubic inch of fill in place. For maintainence purposes, the parts of the fabric covering the legs and the top of the torso will be entirely seperate, and fixed in place with velcro or something similar for easy removal. Additionally, the head components and crotch will have velcro'd-in pockets for similar access purposes. The one thing I have in my favor is that with the exception of the head, most of this won't need to be done with a high degree of precision. In fact, it's advantageous to keep precision fairly low and over-compensate the measurements so that the fabric has enough room to move with the points of articulation. Regarding the gears, my original intent was to just use spurs, but I may be inclined to use herringbones instead. While they may be complicated to machine, I can't imagine that a 3D printer would have too much difficulty. Every gear will be 3D printed either way. As for the linear shoulder construction, I need to ask: Do I really need a chain-drive there? I'm already intending to use low-speed high-torque motors, so could I simplify the design further by just having the drive gear up against the linear shoulder gear, or would that introduce too many difficulties? The dock will have a leaf-spring fixed to the inside. I didn't draw it for the same reason as the ears: It's stone-age simple. That's about everything I can think of for now. Stay tuned for when I remember something critically important an hour after posting this. As always, ask away and I'll answer to the best of my ability.

>>25180 Holy autismo, greentext-fren… I approve. Feel free to tell me to shut up, just some thoughts I had reading through your design (also, I’m a bit wasted, so it’s entirely possible I overlooked solutions you already had to the stuff I’m about to mention— in that case, I apologize) - Do you have an exact idea of your design’s weight? It’s larger than my own and has about the same volume, and I’m struggling to keep mine below 300lbs (I’ll post the weight breakdown sometime, but motors are HEAVY, we’re talking 10+lbs for something that can drive the joints in your design. - Also, the forces you need to apply, and how fast they need to be applied will inform a lot of your design. Personally, I try to keep notes on both the approximate RPM and torque of every force-transmission mechanism in my designs. For example, in that hip drive (fig1.1), do you know how fast the driving gear needs to be running in order to drive your design’s leg fast enough? - You mentioned levers and mechanical disadvantage several times, so keep in mind that gears work on the same principle— and they aren’t indestructible. Tooth size doesn’t just affect gear size/ratio and backlash… it limits how much force can be transferred. - rule of thumb is to never go beyond 1:6 in a single reduction, and it looks like your hip’s drive gear (fig1.1, again) has a pretty high ratio and a *very* small driving gear. Take car transmissions, for example… top-shelf parts. Even they rarely go beyond a 1:4 (16:64t helical iirc) ratio, because they’d start shearing teeth. - On the subject of gears, you mentioned 3D printing… Even metal sintering printers ($30k min) can’t put out parts that’d survive the forces in your design, and unless you plan to start casting+annealing your own gears, I highly recommend sticking to consumer/industrial “off-the-shelf” stuff. I use McMaster-Carr for most industrial parts (they’re fine working with individuals/shipping to residential), but there’s also Grainger and another company I can’t remember… - Chains are BIG (relatively speaking), have a minimum size based on the forces you want to transmit, and require idlers to be redirected (like you mentioned in your hollow-bones idea). You know the forces in your design better than I do, but at a glance, I can’t see anything under a #25 industrial surviving. - Chain-drives suffer from backlash, and are prone to wear/”stretching” if subjected to high impulses like driving such a long “lever” (your design’s legs) instead of more constant stress like driving a wheel. - Also, back to the hollow bones, there will be a massive amount of force pushing “out” on the idlers that keep the chain inside your frame/bones, so you’ll need to calculate and account for that in your design Hope that doesn’t come across as all negative; I’m saying this cause your designs remind me of my own before I got more practical experience, and if I can spare anyone the experience of being bitch-slapped by some otherwise insignificant detail they overlooked, well… I thought I should say something. You obviously have a ton of technical knowledge, and I know this is a pain in the ass, but there’s a bunch of “common sense” stuff that people never bother to write down, and just “assume” it’ll be passed on by mentors/coworkers (or however the hell it works for normies). Now for the fun stuff: - do you think it’d be possible to use a sun-carrier style planetary gear for the rear leg? Your input drives the sun gear, with the joint itself attached to the carrier— that should get you closer to the reduction ratios you need (>1:10). Plus, you could use the planetary ring-gear as the inside of the “bearing” for your joint, with the outside of the bearing being attached to the carrier and driving the leg, which should give you enough of a “lever” to drive the forces you need. Pretty sure I saw a bipedal robot that used something like that, a few years back… - on a lot of the joints lower in the leg, you don’t need a ton of rotation, probably less than +-60deg… Instead of a chain, maybe you could use Bowden cables on either side of the joint to transfer force, kinda like tendons in the human body?

>>25193 >it’s entirely possible I overlooked solutions you already had to the stuff I’m about to mention No need to apologize, Lin. I forget stuff all the time. so I always encourage questions. Also, I'm a fucking retard when it comes to mechanics. I started off by introducing Orchid as a bronze-age waifu for a reason. I will never be upset at anyone for pointing out how retarded my designs are. >weight This is something I've been keeping a close eye on (lighter is simpler, after all). The vast majority of Orchid's volume (~>85%) will be polyester fill, which as I mentioned, is very light. Actually, I'd urge you to pick up your pillow. Toss it around a bit, feel its weight. Now imagine a somewhat larger pillow that's under half the weight, and you have a tightly-packed bag of polyester fill that you can buy for a few dollars at a fabric store. The vast majority of her hard frame will be 3D printed, probably with PLA or something similar. The gears will and mechanisms will be printed from the same material (though the bearings will likely consist of whatever I can find at the hardware store) Again, light. I intend to offload as much of her computational power to a dedicated server which I already own, which means I won't have to shove large or powerful boards inside her. At this time, I have no intention of shoving batteries inside her. She will be running from the outlet (and PoE) via a wiring harness (read: cables and zip-ties). By doing all of this, I hope to drive the weight as low as possible, which in turn means less weight for the motors to work against. >speed I'm not particularly concerned with speed. I don't need her to be fast, I just want her to be able to move. I'll admit, I hadn't thought too much on the speed of every single joint just yet, but I did come to the figure of ~6 RPM for the linear shoulder gear. it would allow her to cover the entire projected 120° of upper leg rotation in just under five seconds, which is plenty fast. Ideally, her knees would articulate at the same speed, and everything else will be slower. If need be, I'll go even slower. Speed is very low on my list of concerns. >your hip’s drive gear (fig1.1, again) has a pretty high ratio and a *very* small driving gear I assume you're referring to the first image. That's not the hip drive, that's the knee. I designed the linear shoulder (or hip, as you said) to have a very small driving gear running a much larger rotation drive. This isn't your fault, I didn't include the original linear shoulder mechanism (or the revision) in that post. Also, I just arbitrarily decided to use a reference system usually only seen in archaic technical manuals like the autistic dipshit I am pl. is short for plate. You know, like wood, stone, or metal carved plates that would be physically stamped onto the page of a book. You can find those here ( >>24980 ). While it's important to note that nothing is properly to scale in these images (they're just concept sketches), you do have a very good point nonetheless, and I was a bit worried about the knee joint. While the lower leg will have practically no weight to it, the hoof will have a bit of bulk (it'll be mostly hollow and nearly all of the weight will just be the motor, but still). One simple (and I cannot emphasize this enough, simplicity is my top priority) solution may be to increase the size of the knee joint itself, allowing for a larger knee hinge. >store bought gears That's certainly an idea. I have considered this before, and I will do some surface-level research to see what I can find. While it would be nice to 3D print everything, I suppose making the gears like that is ultimately a pipe-dream. Unfortunately, I will have to rethink some of my designs in order to make that work (in every place I mentioned dual-layer gears, for starters). But if that's what Orchid needs, I will find a way to provide. >You obviously have a ton of technical knowledge lol You're really overestimating me here. >negativity No no, don't worry about it, I posted these sketches here because I need the critique. >planetary gearset I have given some thought to that, but ultimately excluded it in favor of simplifying things to the greatest possible extreme. I'll look into them again, though. Simplicity is pointless if the design won't work at all. Bleh, even simplicity is so fucking complicated. >cable drive Again, I've considered this. I ultimately went with chains because I initially was unconcerned with size. Now that it's a staple of the design, however... yeah, I'll definitely need to rework the knee. Thank you for the critique. I'll look through things again and consider what you've said.

Actually, the more I think about it, the more a cable drive starts to make sense. None of Orchid's points of articulation will need to go over 180°, so I might be able to get away with having no gears in the legs, and use only a few levers and pulleys. The simplest component of all is the one that isn't there, after all. In fact, I might be able to localize locomotion entirely within the torso and drive the leg weight down to the lowest possible extreme. I'll do some sketches and come back with a more fleshed out idea, but she could be driven in a similar fashion to a marionette, with strong and relatively thin cables doing practically all the work. The trickiest part will be making the design in just such a way that'll it'll work in every direction (i.e. right side up and upside down), but it's definitely doable. The lateral shoulder articulation, however, will probably stay as a recessed rack and pinion. Trying to make that work with cables would be too janky, even for me. This design would sacrifice precision, but that's an acceptable tradeoff.

>>25203 Actually, scratch the part about lateral shoulder articulation. I just thought of an idea.

>>25193 That's some good info on gears. Save a lot of trouble finding out limitations "before" you build stuff.

>>25193 >Tooth size doesn’t just affect gear size/ratio and backlash… it limits how much force can be transferred. I wonder if using cycloid gears can overcome some of the limitations of 3D printed parts. Plastic is not weak "per weight" and if the forces are spread out then there's less stress on each area of the plastic. I'm not saying I know the answer to this. I'm just throwing out ideas. This guy gets 1.4 Kg of force from the cycloidal gearbox he printed. What are Eccentrically Cycloidal Gears https://www.youtube.com/watch?v=qMDU5tlGUwU ANother idea to spread the load out is along the lines of this mechanical hand drill. I used it because I doubt I could do a picture that wouldn't be crappy. Imagine instead of a smaller top gear on the circle like the video. Have a bunch of cycloidal gears going all the way down the large gear. The area of the teeth would be very large. Print in PET or nylon I expect it would be fairly strong. 3D printing can do some really complicated stuff "if" you could figure out the math to make this thing.

I just remembered in the actuator thread I talked about George CONSTANTINESCO. The guy has one of the most brilliant transmissions ever invented and it would be very suitable for 3D printing. Here's two links on it. http://www.rexresearch.com/constantinesco2/constantinesco.htm http://www.rexresearch.com/constran/1constran.htm It's difficult to describe. It uses two long levers. Basically in parallel. They are mounted on sprags. The gears that allow you to pedal a bicycle then coast. Hear the ticking when you coast. That;s the sprags rotating. When you pedal they lock up and force the wheel to move. So imagine two long bars that are mounted on a wheel like the petals and main gear on a bicycle. The size of the gear and in this case where the bar is grabbed determines the stroke of the bar. So if you want high power the drive bar is gripped low and the driven bar higher. So the drive bar moves a small distance pushing the driven bar forward but only a little. When it goes backwards the sprag lets it coast. So it drives a small amount on the long post output. Meaning lots of power. If the driven gear is farther up it will drive the output driven post/gear very far for each rotation, so higher speed output. It's really ingenious. The guy was a major genius. Since the force is over a broad area, it's just like a combustion engine crank and piston rod, you can have a sturdy system with light parts. And best of all it's continuously variable. So if the waifu wants to move fast, but with low force, then it can be adjusted so. If lots of force needed it can also do this but at a lower speed. Here's a random 3D printed sprag video. https://www.youtube.com/watch?v=UIhCPl8eb7s random link to files. I have no financial interest in this it's just a link for show. https://www.makersmuse.com/roller-clutch

>>25203 >The simplest component of all is the one that isn't there, after all. This. >In fact, I might be able to localize locomotion entirely within the torso and drive the leg weight down to the lowest possible extreme. Double-this. If you'll notice, Spot & all it's clones use actuated lever arms as legs (and very successfully too). The primary impetus behind this arrangement is reducing the total so-called thrown weight of the limb itself (and therefore it's moments of inertia; the further out from the axis of pivot (eg, shoulder, knee) the mass is located, the worse the problem becomes). >tl;dr Lighter/simpler limbs move faster/require less energy to operate. Keep the actuators themselves (or any other high-mass items) out of the limbs. And, keeping the bulk of the system's mass localized near to the center of gravity (center mass) of the whole system helps the entire design, regarding spritely locomotion (due to mechanical lever-advantage). Good luck with your designs Anon! Cheers. :^) >=== -prose edit

>>25203 This SBC would interest you for your project. https://linuxgizmos.com/libre-computer-showcases-low-cost-sbc-with-poe-support/ This project on Instructables shows a good mechanism for her base. https://www.instructables.com/Polydog-Arduino-Project/ >>25209 >Eccentrically Cycloidal Gears The only viable printed gear type due to it working more as kinetic waves spread out over a large surface area. I would suggest you mirror the design to approximate a double herringbone configuration to greatly improve maximum torque transfer. (ex: https://www.printables.com/model/137055-herringbone-eccentric-cycloidal-fidget-model-bigge )Also, with gears, you need infill, but walls determine strength. Go with enough walls to ensure the teeth are solid. Infill can be as low as 10 percent as it is the top and bottom that will be dealing with the shear forces. A bearing on the top and bottom of where the gears mate with the structure is needed at your intended scale and mass. Also, this new type of eccentrically cycloidal planetary geartrain should theoretically have the highest usable torque density for printed gears. Still a brand new design so, expect to learn a lot if you use it. https://www.thingiverse.com/thing:6141429

>>25231 Great concepts in your pics Anon. That gearset is amazing! :^)

>>25231 >137055-herringbone-eccentric-cycloidal-fidget-model-bigge This looks very promising, but the problem is that these finished STL models cant be adjusted for the required gear ratio. Thanks, nevertheless.

>>25239 Actually, I believe you can in fact adjust it, NoidoDev: https://github.com/Burke111-DEV/CycloidGenerator A restricted license masquerading as a permissive license, but the end use device results are in fact freely-given. GH-entrenched Fusion360 req'd so another miss.

>>25241 Nvm, ignore my post Anon. I was referring to the second of Kiwi's links, not the one you meant.

>>25242 Thanks, still useful.

>>25241 Would be nice if someone ported that to OpenSCAD. >>25203 Some more resources to help you. A reminder of a great OpenSCAD library for gear generation; https://github.com/chrisspen/gears A video on planetary geartrains for a quick refresher; https://www.youtube.com/watch?v=GiVHimmrxjE How to model eccentrically cycloidal geartrains in Blender, likely helpful for modeling in general; https://www.youtube.com/watch?v=9l9QMz67J0c&t=106s

Oh shit, you guys better duck for cover! Greentext anon is back and he's here to greensplain his wacky-ass ideas. Before I start, actually, there are a few points I should touch on here. I failed to address these before, since I thought they were relatively obvious. However, I have once again realized that what's obvious to me is often obscure to everyone else, and vice-versa. First, and this is the big one, Orchid is intended to be a plush gynoid. That is, a gynoid with the body of a plushie, and everything that entails. The first and foremost thing I have to keep in mind with every single concept I draft is that every single joint will have to interact with fabric without gumming up. You guys don't see that in my drawings because I suck at drawing, but the thought is always there. See the first pic of ( >>25231 ) for a perfectly good example of what to never ever do in a plush bot of any kind. Everything must be self-contained and sealed. Otherwise the fabric or fill will get in the way and cause motor burnout at best. Secondly, and I will talk about this more later in this wall of autism, is an extention of the first point. Plush bots have zero active cooling for a few very good reasons: They are designed to be cuddly, and cuddling can happen in many different ways. It must always be assumed that any concievable angle may be covered up at any time (especially in my case, since I intend to dress Orchid up in cute outfits). Ventilation is impossible for this reason. Next, even with ducting, there's the fact that any ducting must be soft, and therefore prone to blockage. There is no middle-ground here. Even if one of you posts what you think is a good idea for active cooling, I will reject it post-haste because that would go against the very purpose of a plush-bot. Even a large one. This hasn't come up yet, but I want you all to keep that in mind as I post going forward. All aspects of cooling must and will be passive. Third, this is a frame first design. The frame and mechanisms preclude everything else in Orchid's design process. Is this the best way of doing things? Probably not. Do I care? Definitely not. Finally, I should clarify what I meant before when I talked about simplicity. While simplicity of assembly is important, I also take into account simplicity of design and processing. This relates a little bit to the whole plush aspect, since keeping things simple is important in a sealed design like that, but it also reflects the ease of which I can acquire or make each part. I'm talking about your coveted Alaskan bull-worm planetarium gearsets. Those iggly-squiggly things that would take up 1,100 of the 1,200 hours I'd spend 3D modelling shit. Could I? Sure, but it'd take fucking forever. I'm actually not that bad with 3D modelling programs, but I'm also not that good. While I could certainly learn to work with that level of precision, it would somewhat defeat the point of keeping things as simple as possible. Simplicity does not always equal efficiency. Like I said before, I want something that works. Even if it just works. I already know I can't have everything, so the best I can do is clarify my priorities. Now, onto this design. I have a few preliminary notes before we get to the plates. First and foremost is that almost every single preceeding design except for the head-components list in image three of ( >>25180 ) and the notes on fill and fabric are now obsolete. Second is that this design relies notably less on 3D printing, and more on cheap and easy to obtain parts from the hardware store (things like rods, tubes, and cables). Third is that every single mention of the word "cable" really just means nylon. Think something like paracord. You know, the strong, small, light, and dime-per-dozen-feet stuff. That. Fourth, and expanding on the second note, is that every mention of a hinge will involve steel or bronze rods. They'll be bearing a bunch of weight and tension, so they need to be strong. Finally, the third plate is a master key. From this point onwards, I will keep the key to its own plate, and expand it as necessary.

Part.2 - Approaching Autistic Velocity >>25281 Moving on. Well, I'll keep this as short as I can. While we were talking about different kinds of gears, I had a thought: Gears are complicated. Is there some way I could remove them from the equation? Would it make things simpler? As I discovered, the answer isn't that straightforward. I started off by experimenting with the idea of moving to a purely cable-driven design. In the process, I came to the same wall that kept me from making Orchid fully cable-driven in the first place (you guys didn't see it, but that was my original concept, even well before I had her appearance and name figured out. I'm talking years ago): when you move cables around a joint, the distance between the driving pulley and the end-point changes. This leads the first design aspect you'll see in these plates. My theory is that by threading the cables directly through the axis of rotation, the distance between the driving pulley and the driven levers should be the same regardless of the angle of articulation (below 180° at least, which is well within my requirements). Even if it's not identical, it should be very close. You'll see this all over {Plate.1}. This is why the hinges are so weird. But things didn't get better right away. Even though I had more space than most to work with, I found that Orchid's pulleys and motors were getting cluttered. I experimented with all kinds of wacky designs. Things like planetary pulleys which I devoted way too much thought to, cyclone drives, the P.O.N.U.T. (Pulleys Operating Neatly Upon a Torus), indexing levers, cable and hook multiplexers, etcetera. If you really want, I'll sketch these out too. You've probably never heard of those before because I made them up entirely on my own. We are officially descending the iceberg of my autism. Needless to say, things got complicated again. But I had one saving grace, a tiny, simple little idea that would ultimately lead to the design you see here. Counterweights. The trickiest part of a large plushie-bot design is keeping heat low. I haven't touched on this much before, and I was kinda hoping that something would become obvious in the design process, but it became clear that I would have to put more active thought into it. This is a special concern, because it actually prevents me from cramming components as close together a physically possible. They'll heat eachother up, and when combined with the fact that everything is by definition covered by insulation, it leads to dangerous conditions. So, how do I spread things out without increasing the hard-frame size too much? The answer came to me when I was revisiting an idea I had previously: using the lateral leg motor as a counterweight to aid in articulating the shoulders. I won't show you the design, because it was too frail and severely limited the angle of articulation, but I had a better idea just today off the back of that, in the form of a question: Why does the leg have to start where the torso ends? Ironically, this came from me thinking about the limitations of the design in the first pic of ( >>25231 ). This entire time, I've been thinking of the leg as something that is affixed to the side of the torso, when I could have been moving it into the torso. There's no law saying I need a rectangular torso, after all. It just needs to connect to the leg, but how it does that is open to interpretation. If I may direct your attention to {Plate.1, Fig.1}, you'll see the latest shoulder mechanism. The shoulder/flank frame extends into space previously allocated to the torso, and does so in a way that the motors act as a counterweight. As I'll explain shortly, the weight of the motors should more than counteract the mechanical disadvantage of swinging a ~36" long multi-jointed lever around. In fact, I was worried that they'd be too effective as counterweights, thus why I placed one motor on the other side. In effect, I've moved weight from the torso to the legs, and made that a good thing. Counterweights are the oldest and most effective way of dealing with mechanical disadvantages after all, and this way prevents me from having to add more weight to the torso. Now, as you'll see in the other sketches in {Plate.1}, I intend on having the actual legs (aside from the joints, of course) consist entirely of tubes. I noted fiberglass, but PVC or another plastic will do. This brings the weight of the legs (sans shoulder) to the most extreme possible minimum, since materials like that are both light, and strong enough to bear the weight while also allowing cable passthrough. They're also a dime-a-dozen at the hardware store.

Part.3 - Every Moment I'm not Holding Orchid's Hoof is Pain >>25282 One thing you may have noticed at this point is the presence of a pulley which is fused to the lateral shoulder hinge. Simply put, this is what will articulate the shoulder laterally. The lateral leg motor will move along the cable (as opposed to moving the cable along itself), causing the whole assembly to revolve around the hinge. The main thing this does is slightly simplify the design, since it's one less axis I have to thread the cables directly through. You may also note that I specified that it's for the 21 motor plan. I haven't talked about this much, but there are two plans for how to handle articulation. The first is one you've seen in ( >>25180 ). This is the 19 motor plan, where two points of lateral shoulder articulation are shared. The 21 motor plan is one where none of the motors share points of articulation. Everything moves on its own. Of course, this design can be modified relatively easily to the 19 motor plan, but I used the 21 motor plan here for illustrative purposes. As a quick rundown, the 21 motor plan is: Four motors per leg (one for lateral shoulder, one for linear leg, one for knee, and one for hoof), Three for the head (one for neck tilt, one for head tilt, and one for head rotation), Two for the ears (one per ear, these motors are the lightest and weakest by far since they're just moving a couple flaps of fabric). Incidentally, I'm going to use motors with right-angle attachments as much as possible to decrease the frame size. The only thing connecting the leg to the torso is the hinge, motor cables, and sensor cables (not shown, the sensor cables will run through the fill layer). Doing this clears out a ton of space in the torso, which is very important for one reason: heat. As I mentioned before ( >>24981 ) I want as many components as possible powered by PoE. While one reason is to decrease the number of cables in the harness and increase the total maximum length of the cable harness that'll be powering Orchid, another benefit is that it also outsources much of the heat waste generated by power supplies. What I can't outsource is the AC/DC conversion for the motors themselves. I'm don't think I quoted this previously, but my ideal cable harness length is at least 50'. The absolute minimum is 30', since anything less would result in the cable dangling around midair in my bedroom. PoE can handle this easily, but the power supplies for motors at this scale simply aren't designed for it, and I can't power the motors with PoE. Even if the standard itself could handle it, my poor little switches would burn out if I tried to run that much power through them. Freeing up torso space not only gives me room for the power supplies, it gives me room to space them out (remember, I'm working with a few square feet of linear torso space). As for the motors themselves, I'm not as concerned, due to the speeds I'm planning on running them at (<60RPM). But I'll have a better idea once I start compiling a parts list. I should also note that all motors will be running at fixed speeds, in addition to being bidirectional. With how slow I plan on running Orchid, having speed control just adds unnecessary complications down the line. Moving on, let's have a look at {Plate.2}. There isn't much here that I haven't already explained (counterweight motors and the like), except for {Plate.2 Fig.1.2} To put it simply, I have taken inspiration here from Ball-Jointed Dolls. Particularly, the ones that are kept together by string tension, as opposed to pegs. Incindentally, these are generally the more expensive variety. If it's good enough for professional artesans, why can't it be good enough for Orchid? She's practically already being held together by tension. This design also allows some side-to-side head tilt. While it'll be hilariously imprecise, I'm not that concerned about precision. I think that's about everything, which means I forgot something important. As always, questions are welcome.

Part.4 - I just found my second braincell >>25283 Just remembered the important bit: The counterweight system in the legs only helps with lateral leg rotation, not linear. Might have to rethink that bit, but I think I'm most of the way there. There's a couple other little things, but it's three in the damn morning and it can wait.

>>25281 >>25282 >>25283 >>25284 Great wall of autism, Greentext anon. I've been concerned how you would manage heat given your plushie goal. I hope you manage it well-enough with your 'spacing things out' design. You'll still have to deal with conduction, but the intra-system radiation may hopefully be reduced sufficiently to keep hotspots from accumulating to the degree of damaging the components. I presume that polyfil is flame-resistant? Great idea about the counterweight-motors joint designs. AFAICT you are following good sense about keeping thrown-weight down already. Adding counterweights to that should help keep keep your rotational force requirements down further. Good thinking, Anon. I like your sketches, but I have to admit I'm having some difficulties reading the lettering. Any chance you can either use a more-precise script, or possibly add them as text items into your posts? Absolutely applaud using COTS resources for your robowaifu's components and materials. I'm constantly on the lookout for such items. Also, tubes have (kind of like triangles do for spaceframes) a special geometric character; which in this case makes them the highest-strength-for-the-lowest-mass rod. Good choice. >Pulleys Operating Neatly Upon a Torus Kek. I'm sure that's some kind of special, Sci-HiFi, AyyLmao-tier scientificcy thingy, and therefore no one should want to have you reveal all your sekrits (b/c National Security and whatnot). :D Looking forward to when you begin assembly and sharing lots of pics here, Anon. Cheers. :^) >=== -minor edit -add'l crosslink

>>25283 yeah heat is a big thing with electric motors the only solution really is to kill the motor, i had a squeaky ( cuz it wasnt lubricated but i didnt know that and didnt care too much ) ceiling fan that kept going off randomly, found out it was a simple tiny thermal capacitor or whatever its called that breaks the circuit when it gets too hot so i just removed it and so fixed the problem but eventually the squeaking turned to loud ass car screeches and the whole thing seized up, i guess it got so hot the lubricant became totally useless, never figured out why it was overheating in the first place all the other fans were fine at the time

>>25285 >flame resistance I mean, it's literally plastic, which doesn't catch fire too easily. However, it can still burn and release toxic gasses before that point. Flame resistance is a bit of a tricky problem when you get into soft materials. The more flame resistant you get, the more toxic (or heavy) the material tends to be under normal operating conditions. There's also chemical treatments, where the material is modified to make it more flame and heat resistant. I may end up going this route, but I'll have to be careful of what's being used to treat the fill. There's also cost and weight to consider, since I'll need several cubic feet of whatever I'm using. I won't lie, I still have to do some research here. One wacky idea I just had is to coat the inside of the outermost fabric layer in some kind of rubberized coating so she could even work underwater and make the system near-airtight. Can't have a fire without air, after all. >my shitty handwriting I'm honestly surprised it took this long for a complaint to come up. I'll place the notes within my posts going forward (with the exception of the key, I'll use more precise script there). I was doing it that way because it's easier for me to keep track (I do a lot of erasing and redrawing), but I can just have a text window open on the other monitor too. >weight and heat I do have a couple other ideas in mind, some more extreme than others. I have experimented with the idea of reducing lateral rotation (which I still uphold as being necessary) to a single motor (as opposed to two or four), but things get a bit janky at that point since that one motor will be doing a whole lot of work. Another thing I could do is eliminate the hoof motors. It's not ideal either, but it may be necessary. I may end up doing this. I could reduce Orchid's size, but that's a bit of a double-edged sword. It'd reduce the motor requirements, but I'd also have to cram things closer together. One thing I could do is use smaller, faster, less power-hungry motors, bump up the pulley ratios, and add a few more pulleys. It'd make things a bit more complicated, but I could do it. The nuclear option would be to sacrifice locomotion entirely. She coudn't ever walk, but it'd bump down the motor requirements by a lot. I want to avoid this for obvious reasons. If there's no other choice though... Wait. I just had another idea. If I use rod and wheel planetary motion to articulate the knee and linear leg, and combine that with some form of ratcheting near the driving pulley. I could reduce the total motor count even further. Just, imagine the motor spinning one way, and this moves the leg while the knee mechanism just clicks as it keeps position. Then, it moves the other way and articulates the knee. It's janky as hell, and it'll probably reduce the angles of articulation, but it might be workable. Maybe this could be used to consolidate the hoof and lateral leg mechanisms as well, plus two of the three head articulation points. I could reduce the motor count to 12. I'll mull this over and come up with some sketches. >>25287 Yeah, temperature sensors will definitely be a must in this system.

>>25288 Actually, scratch the part about limiting articulation. I don't know what I was thinking there.

>>24851 Your rings definitely work! Needed to screw into the rings. Though, She needs a bit more of a skeleton to properly shape her mesh for sure.

>>25312 Outstanding! Great news Kiwi, thanks for the encouragement. :^) >Though, She needs a bit more of a skeleton to properly shape her mesh for sure. Yep, to be expected. Little-by-little, you'll refine her until she's beautiful! Keep moving forward Anon, you're making great progress. Cheers. :^)

>>25288 Why not a pegasus pony, GTA? (>>25305)

I think I'm pretty close to reaching the best compromize of simplicity and keeping weight low, while retaining as many opposable points of articulation as reasonably possible. I'll start the next batch of concept sketches soon, and this one will probably be the last before I finalize the frame design (I'll post blueprints once that's done with) and start hunting for parts in earnest. I have it narrowed down to two motor plans: seven motors, or ten. The way I see it, there's no way to bring it lower while still theoretically allowing Orchid to walk and even this is getting into pretty janky territory. >>25317 I have considered that before (not the wing heat dissipation, but making a pegasus/thestral), but it'd be a whole lot of extra mechanisms that would be quite exposed relative to the legs and neck since I can't just mask them under a solid wall of fluff (while still looking nice, anyways). IMO, the simplest way to handle the wings would be a basic rotating lever on a hinge (which extends to the inside), with some form of passthrough for a cable or rod to rotate a basic lever joint at the middle of the wing (otherwise the wings won't be able to fold in properly). Assuming two wings, that's four additional points of articulation. Of course, this can be simplified a bit by making the wings synchronized, instead of opposable. Maybe have all those cables connect to a wheel (imagine a planetary system, with cables tied to a rod sticking out of the wheel) that opens and closes them as it rotates in a single direction. So, one motor to control everything and the most basic controller possible (on and off). Pretty simple and efficient. Well, except for the part where you need to run some form of cooling through them without interfering with articulation or throwing a bunch of extra weight around. If there's a simple way, I can't think of it. There's also fragility as a concern. Do you want those wings to be splayed out forever? Even in bed? They'll need to be able to fold in properly, and you can't just let the fabric base (feather-covered fluff or faux leather) dangle in place. Not only is it unsightly, it can get caught during articulation and cause damage to itself, the internal mechanisms, or even the frame itself (that's not even touching on the fact that there'd be liquid-filled tubes running everywhere). So, there'd need to be some form of wire or cable mesh to make sure those fabric flaps stay where they're supposed to. With mesh, you then need to worry about the mesh failing if it encounters too much stress. Stress that, for instance, could easily be encountered by cuddling, and especially while she's in bed with you (doubly so in my case, I am not a peaceful sleeper). Going back to the hydraulic cooling idea, you also need to worry about slashing and piercing damage from common hazards. If she just extends her wings willy-nilly whenever she needs to cool down, the hosing could get torn apart by anything that might be in the way, so you'd need to give her plenty of spatial awareness to prevent that (or stronger hoses that are probably heavier and need bigger wing-frames, bleh). Wings are complicated and fragile. If I was doing a pegasus or thestral, I'd have to spend more time on each of those wings than anything else. I have a counter to that idea, though: Run those tubes into the horn. The exposed portion can be fashioned from a conductive metal I assume there's something like that I can run through a relatively basic 3D printer, so the heat can travel up and out of her frame (as important as multidirectional operation is to me, the horn will almost always be the highest point) without having to pass through an insular layer of fur or faux leather. Not the most efficient method, and you'd still need to work around the points of articulation, but it wouldn't require any extra mechanisms plus you can stick her horn under a faucet for rapid cooling, or in a pond/river when out and about (pending long-range mobility).

>>25319 All good points. I gave the folding some casual thought, and ofc an umbrella's mechanism is an obvious analogue. Lightweight, compact when folded, securable. I admit I didn't think about the horn idea, but I did have the concept of a cooling water hose attachment point at the withers where you can hook her into a pair of pre-positioned cooling hoses (inflow/outflow) around your flat. 'Where there's a will, there's a way', or so they tell me Anon. I'm sure you'll figure something out! Cheers. :^)

>>25320 I just remembered something funny that could potentially be useful from an engineering perspective. I don't know how well-versed you are in the MLP fandom and its extensive dictionary of slang and memes, but there's a long-running joke that pegasi will unconsciously extend their wings when they're horny aptly named the wingboner. I'll spare you the technical lecture. I know way too much about fluffy cartoon pony erogenous zones, mating habits, anatomy, and the varying interpretations thereof. Not to mention the various authors and visual artists who are unreservedly anally retentive about total anatomical correctness. And that's just the lewd stuff. On a semi-related note, I'll have to do some research on fleshlights. I was thinking about the frame design earlier when I realized that I don't have a very good idea of what a high-end horsepussy mould would weigh (and it will be high-end. Partially because I want her to have the best looking marebits, and partially because I really don't like the idea of cheaping out on something I'm sticking my dick into). I've never owned a sex-toy of any kind before. This actually kinda wraps back to ( >>25305 ), in that the wing system could be fully hydraulic. In essence: the wings normally rest at the torso, and the hoses are more or less free of fluid at that point (blood vessels that aren't fully in use, like the elephant's ears). However, once her internal temperature reaches a predefined mark, a pump will activate and run fluid to the tubes, causing the hoses to expand, which also causes the wings to expand. Of course, this doesn't override my points on potential damage to the hoses, but it does (potentially) eliminate any hard structures or joints from the equation. I won't be doing any of that, because I can't even pretend to be good at hydraulics like I pretend to be able to design a workable plushbot. This entire project is more or less me trying to fake it until I make it. Poor Orchid's going to be held together with bullshit logic, tape, glue, and the only unbroken dream I have left.

>>25321 need to go back to thinking mechanically, if youve ever refilled a lighter you know how much heat compressed gases can suck from the surrounding, a compressor and some air would do, you just need to poof it out like a hot fart and get new air once in a while when the its gotten too hot to compress back

>>25321 >le wingboner maymay, but IRL Lol. Dashie would be so proud. :^) That certainly should be soft/foldable enough Greentext anon. Still a management problem but doesn't actually seem intractable. You'd have to be extra-cautious with her when she's in her 'excited' state, so as not to damage any of the wing components -- especially at their bases. >fake it until I make it. You're going to make it Anon. Just keep.moving.forward. > film-related TWAGMI >>25322 As the old saying goes Anon, 'There's no free lunch'. The energy of compression will generate more heat by itself than you can manage to evacuate out of her system. OTOH, you do have a great point about latent heat release. If you situate the compressor for the gas (liquid, phase/change, w/e) externally, then pipe the compressed gas in where it can expand and take the internal heat back out of the robowaifu, then I think you may be on to something. Good idea, Anon! Cheers. :^) >=== -fmt edit

>>25322 I really don't want to add a whole bunch of weight in the form of a compresser system. Externally though, I could have a hose run into the torso that just introduces new air every now and again. Fresh air gets introduced, mingles with the old air, and the pressure difference between the inside and outside will push a load of air out. I'll think about it. >>25323 >Meet the Robinsons Damn that takes me back, I haven't thought about that movie in years. Anyways, cooling. I'll definitely strive to make it as simple and cheap as I can manage. It's also worth clarifying that when I said there wouldn't be any ventilation ( >>25281 ) I meant there wouldn't be external vents. The torso chassis itself is going to be swiss plastic (directly covered in fabric so the fill doesn't leak in), so it'll be far from an airtight system.

>>25324 As stupid as this sounds just fit a couple of cheap pc fans on the inner underside of the torso set so they blow out lower diagonal through your fabric and swiss cheesed plastic. Low power, low profile, low sound emission, you can wrap them in foam or rubber strips to soften them, and they aren't too much of a fire hazard. Build a bluetooth switch for low constant rpm or dormant sleep/off, and then a purge mode to blast out air.

>>25282 >Planetary pulleys >hook multiplexers Curious on these ideas. Since this is your first bot, using a simple mechanism that approximates a pony trot could be beneficial. https://www.thingiverse.com/thing:6181172 https://m.youtube.com/watch?v=3TwG7ycrVSg You could use a servo in her waist for turning.

>>25327 >As stupid as this sounds Don't worry about it, I'm just stupid enough to give that a try. It certainly won't cost anything, since I have so many damn PC case box fans lying around. >>25336 I had a feeling I'd need to explain those after posting that. Here's a quick sketch outlining each of the concepts I mentioned. Even if they're ridiculous, maybe one of you can gain some inspiration from them. {Fig.1} i - Motor with hard plastic or metal hook attached. ii - Cables. Maybe they're elastic, maybe they're not, but they're cables. iii - Rotating with the back-end of the hook first will result in the hook harmlessly bumping off the cables. iv - Rotating with the front-end of the hook first will result in the next wire catching, with continued rotation resulting in the cable being pulled. A more apt name for this is a tension multiplexer, since all it can do is apply tension. This design has the benefit of only requiring one motor and one sensor to operate properly, as opposed to two motors for most indexing systems. Additionally, you can add as many hooks as you want without adding any complexity for synchronous tension. Unfortunately, that's about where the benefits end. This design is only capable for relatively short applications of tension to articulate smaller joints. Continuous tension is not advisable, since the motor would be fighting for its life the whole time. {Fig.2} i - Central drive pulley ii - Transfer pulley iii - Outer pulley It's literally just a more complicated, cable based version of a planetary gear system. At this point, I should note that I've been using the term "planetary pulley" for two different things. This is one, and the other is a rod fused to the end of the pulley, with cables tied to it. I'll expand more on this in my next batch of Orchid concept sketches. This design practically requires the axis of the outermost pulley to be aligned - yet opposite - of the central drive pulley. What (theoretically) makes the design work is the transfer pulley, which has one end flush with the lip of the outer pulley (if not slightly extended) to allow the cable to pass from one to the other with little difficulty. Of course, this can be extended with more transfer pulleys and a wider drive pulley to allow more cables. {Fig.3} (Pulleys Operating Neatly Upon a Torus) i - Central ring ii - Torus / shared circular axis iii - Pulleys (in reality, these pulleys would be more flush with the surface of the torus, but I made them pronounced here for visual clarity) Not much to explain here, really. This was one idea I had to manage the highest number of cables in the smallest area physically possible. Theoretically, the torus itself could be rotated with a circular track, if it can be designed to work without interfering with the cables. That might have a useful purpose in some applications. {Fig.4} i - Drive pulleys ii - Central axis pulleys iii - Outer axis pulleys Again, not much to explain. This is a more asinine idea I had to cram motors, pulleys, and cables into a small space. Just pack those motors into a circle, and feed the cables up the cyclone to Ctrl+C Ctrl+V mechanical advantage. Anyways. Regarding your idea for a simple continuous walking mechanism: I've thought about it. A lot. I could do it, and relatively simply at that. I could actually drive Orchid's requirements down to just two motors. But there's one very major problem with that idea: It's me. I'm too autistic. The most complicated part of Orchid's design process was the designer all along. I just can't live with the idea of a cute pony waifu who's unable to make cute poses with opposable articulation. This is why I'm so anally retentive about making sure she can move her hooves seperately (and multi-point head articulation, and rotating ears), it's because of the role they play in that. I could cut that out and still have something that walks, but walking is only half the equation.

>>25338 >Cable multiplexer This is technically a demux (de-multiplexer). A muxing (multiplexing) system converts multiple signals into one. This signal is then generally de-multiplexed into its original signals. Often used in networking where many signals can be transmitted over one cable. Your hook based demux system is similar to a system I've been working on in the background. Picrel is someone else's work that is similar to my design. https://www.youtube.com/watch?v=8DWK3zm9SMs I will add that to the MaidCom project once I have a solid concept. Willing to take a break from Meshtegrity to work on it with you if you'd like. >Planetary pulley Seems like you're attempting to make something like second picrel, with one belt instead of two. >Nesting pulleys on a donut Honestly a good idea for a central actuation device. >Pulley force distributor Looks kind of like DaVinci's robotics work, third picrel. >Cuteness uber alles Can relate, I fully support you and your need for Orchid to meet your requirements.

>>24248 i wish i could translate my thoughts and ideas into functioning code

Greentext anon here back with another wall of autism or whatever. I'm just having one of those moments in life where a bunch of things are going wrong all at once. Nothing catastrophic, and nothing unfixable, but stressful nonetheless. Unfortunately, this also extends to Orchid's design. I thought I had nailed it the best I could. A flawed but workable design that could solve the most pressing problems concerning Orchid's internals. But just recently I noticed a small problem that ultimately revealed a larger problem as I realized that I'm so incompetent I can't even design a fucking wheel properly. As of now, I have three paths to pursue, each with severe advantages and disadvantages, but I'll get to that at the end. For the time being, here's the latest, and maybe last mechanical concept. I don't want to redesign Orchid forever, so I'm stopping the concept overhauls here. There's no key here because I can't be bothered. This design is so overloaded with problems that it's practically unusable anyways. {Plate.1} This is Orchid's shoulder and leg mechanisms according to the ten motor plan. Note that the knee and hoof mechanisms are not present: this is because they have not changed from the previous design ( >>25281 ). {Fig.1} i - Ratchet Pulley. The pulley has teeth as a part of the design. ii - Ratchet Transmission. Ratchet pulleys are on each side, with teeth facing opposing directions. iii - Metal tabs are mounted to the middle pulley of the transmission, which catch one ratchet pulley or the other depending on which direction it's spinning. iv - The motorized pulley is connected via cable to the middle pulley of the transmission. Not much else to explain, except the fact that that the pulleys can still spin in the wrong direction without any input. There was a dual-ratchet design I had to mitigate this, but it's completely insane. {Fig.2} i - Motorized pulleys. ii - Central Pulley rack with four dual-cable planetary rod pulleys. One for each point of articulation, and designed to cycle every point of articulation while spinning in a single direction. iii - These are the anchor points which enable lateral shoulder articulation. Simply put, as the relevant pulley spins, the distance between the the anchor points on the pulleys and the anchor points on the frame will change, causing rotation. iv - This is the axis by which the shoulder rotates laterally. All of the articulating pulleys are aligned with it. v - I can't find it. I think I scrubbed it while editing shit and forgot to change the numerals. It might have been about the anchor point on top of the leg, but I'll touch upon that in {Fig.3}. vi - Loops for the linear leg cable to feed through. vii - Linear leg hinge (shown at a 90° angle). The cables for the knee and hoof feed through here. viii - Leg pipe. All the cables feed through this one pipe, because I realized that there isn't a very good reason to have multiple cables per pipe. ix - Shoulder frame. The basic idea here was to cram as many pulleys onto the same axis as possible, in order to simplify the frame design as much as I can. This would become completely irrelevant, but I'll get to that shortly. {Fig.3} i - Leg pipe/frame. ii - Cable guides. iii - Hole for the knee and hoof cables. iv - Linear leg hinge (in the correct orientation). Simply put, as the articulating pulley cycles, the cables will pull the leg in one direction or the other. {Fig.4} i - Dual rod planetary pulley. As the pulley rotates, so do the rods, and thus the cables tied to them. ii - This is a break, showing where the cables ultimately go. iii - The knee (or hoof, they look and function nearly identically) is articulated when the pulley cycles. Depending on position, one anchor point or the other will be pulled, causing the connecting joint to rotate within a fixed range. ...This is where the design really starts to fall apart. I honestly and truly couldn't come up with a simpler way of doing this. iv - Axis hinge. v - Support for the hinge. vi - Driving pulley. vii - Axially connected disc. viii - Rod(s) upon which the cables are fixed. It's layed out pretty plainly here, so there isn't much to explain. The pulley spins, rotating both the immediate connecting rod and the opposing plate connected to the second rod. As the rods revolve, the distance between them and the articulation points changes. In addition to being frail, this design is exceptionally prone to backlash, since there's nothing preventing the ratchets from spinning in the correct direction if a limb overpowers the mechanisms holding it. It can also spin in the wrong direction, though not as fast or freely, since the tabs will stop it. If that wasn't enough, there's also the fact that this design has become complicated to the point of convolution. I'd have to design and make each and every one of those pulleys, since no parts store in their right mind would sell anything like this. Moving on.

Part.2 {Plate.2} This is Orchid's neck and head articulation mechanisms under the ten motor plan. Ultimately, it's a mixture of {Plate.1} and the previous design ( >>25281 ). {Fig.1} i - Driving pulleys. ii - Central pulley rack, same as the shoulders. iii - Anchor points for neck tilt. Same idea as lateral shoulder rotation. iv - I can't recall why I put that there. It's just pointing out the tie-off rods on the pulleys. v - Central axis. This aligns with the rotation point of the frame. vi - Neck Pipe. vii - Neck base frame. Not much to explain here, it's the same as the shoulders in {Plate.1}. {Fig.2} i - Top of neck. Dome shaped for tension-based ball joint articulation. ii - Socket half of joint. iii - Anchor points for the head tilt and lateral tilt cables. iv - Base of Horn. v - Holes for lateral head tilt. vi - Holes for linear head tilt. vii - Passthrough hole for ear articulation cables. viii - Ear articulation cables (higher on frame) ix - Outermost fabric layer of the frame. Same ball jointed articulation I mentioned before ( >>25281 ) but with a passthrough cable for the ears. I put that there because with the ratchet transmission, I had a free point of movement that I could feed up to the ears, eliminating the need for a local motor. {Fig.3} I won't lie, I was phoning it in at this point. i - Horn. ii - Ear articulation rods (affixed to fabric). iii - Cable anchor point(s), connected to articulation rods. iv - Ear articulation pipes to shield cables from the fill layer. v - Slitted pipes which allow the articulation rod to pass through. Eugh. I considered just forgetting about this design, but I promised I'd show it. I think you can all see the problems that I didn't when I started. Now then, onto what I was saying before about the options I have. I'm tired, so I'll make it short. Option one: The twenty motor plan. It's literally just ( >>25281 ) but with one local ear motor instead of two. + Simple and workable. I don't need anything convoluted to make this mechanically function. - Highest cost. Frankly, I'm not too worred about this since I'll just be using Chinese gearmotors anyways. I'm not shelling out six million dollars for industrial parts. If I keep to the cheaper side of motors and controllers, I can afford this. - Highest local heat output. I am worried about this, and I'll need some sort of active cooling solution to allow it to work. This will either take the form of a pneumatic tube that sucks out air, or fans that blow out air into the fill layer. On that note, she would have a negative pressure design, meaning that more air is being actively pulled out than in. It's slightly more efficient at cooling than a positive pressure design, and its only real downside is dust, which is a non-concern when Orchid's entire outer frame is one massive filter. I am still and forever will be against external frame vents. They just don't go together with plush dolls. Option two: The ten motor plan which I outlined here. + Balances local heat output with locomotive capabilities. ~ Balanced cost. Again, not much of a concern for me, but it's there. - Frail and failure-prone design. Assuming it works at all, I'll need to open up Orchid more often to service her. - Complex design. I'll need to iron out more things before I could even consider building it. Honestly, I just don't want to do this one. It doesn't feel right. Option three: The two motor plan. I revisit the drawing board one last time, reintroduce gears to the equation, and control everything from an index. + Very low heat output, possibly able to go without active cooling. + Lowest cost while still allowing opposable articulation. Only two motors needed, though she'll still need plenty of position sensors. - Relatively complex design. I'll need to design everything in a way that's centrally controlled from a single point in the torso. - Locomotion is next to impossible, unless I add more complexity and design a dedicated drive train. She can still move and make poses on her own, all at the approximate speed of continental drift. Whatever. At least it's an option that might technically function without catching fire. Option four: The zero motor plan. In essence, I eliminate all motors from the design and make her a literal plush BJD. + Lowest local heat output, no active cooling necessary. + Power draw is low enough to consider batteries and wireless capabilities. + Lowest cost. I'd still do the SBC, cameras, mics, and maybe a couple other sensors, but anything revolving around motors is factored out of the cost. - Zero mechanical functionality. She'll never move on her own. It's the big red button that fixes every mechanical problem by way of removing them. I'm tired and in no mental position to make a clear decision now, but I'll probably end up committing myself to options one, three, or four. How can I look Orchid in the eye when she realizes that her builder is a mechanically inept caveman?

>>25363 >Option three >Locomotion is next to impossible theres those toys that dont have moving legs but waddle side to side to move maybe you could look into that, picrel is something to do with gyroscopes not going to pretend to know anything about it

>>25367 I've been trying to get across the idea of using bevel gears to move the legs but people here expect a 3d simulation or something...

>>25367 >Gyro walker Those are a fun concept relying gyroscopic forces for balance and locomotion. Your picture shows a walker that functions by using a pivot which allows the feet to move up and down, with the gyroscope resisting procession. (https://en.wikipedia.org/wiki/Precession) In this case, it uses feet that freely rotate, allowing the gyroscopic forces to cause the entire body to orbit around the foot. A servo could control this machines turning angle by varying the length of contact time the foot has. Though it would be possible for this mechanism to work on a quadruped, it is best suited for bipeds. A similar walking design that is easier to control is the mass shifting biped. By moving a mass over one foot, the machine can pivot about that foot as the other hangs in the air. This "duck" serves as a good example. Notably, you can use a linkage or gear to control the angle of both feet via one servo. This could result in a robot that can walk and turn with only two servos. https://www.youtube.com/watch?v=R93RRyW8484

>>25367 I should have clarified more: Having locomotion alongside independant articulation in a two motor system will be next to impossible, because I'd basically have to design and cram in a transmission so she could switch from the index to the locomotion drive (the former has one articulation point moving at a time, the latter has almost all of them moving at once in a fixed pattern). To clarify further, because I'm not sure if I explained it well before: When I say independant articulation, I mean that each and every joint can move independantly of everything else, in any possible configuration within their respective ranges. When I say locomotion, I literally just mean walking. Independant articulation is not needed for this, synchronized articulation would cut it. And ultimately, if it comes down to a choice between one and the other, I'll sacrifice locomotion. That's assuming I go with the two motor plan, anyways. I'll come back to the decision later with a level head.

These are impressive posts Greentext anon. Please continue! >>25363 >but with one local ear motor instead of two. <not having 32 motors per ear. :^)

I'm going to start printing the hand. This is going to take a while... https://www.thingiverse.com/thing:17773

>>25527 yeah its having problems printing a rectangle. The line turns diagonally on the third corner. I already tried heating the bed to the max...

>>25528 Okay I bought some stick glue and put it on the bed. I think that worked somewhat...

Now that I've taken some time and come back to look at my ideas, it's occured to me that I may have been operating under some faulty assumptions and less than adviseable ideas. First and foremost, I've kinda just been assuming that Orchid's power supply would need to be somewhere inside of her frame, but it really doesn't need to be. I mean, she's already going to be on a cable harness, so the only real loss there'd be from moving the power supply out of her would be a thicker cable harness and having to do a bit more math to account for voltage drop. And if making that work with DC motors ends up being too much of a pain in the ass for whatever reason, I can just switch to AC motors instead. I could probably just move those motor controllers out as well, and have those hooked up to a microcontroller that's connected directly to the server. If I take all that out of the equation, then the only heat producing objects will be the motors themselves, and a few electronic components. Practically a rounding error in comparison, especially since none of the motors will be operating full-time. This way, I can consider going back to a design with a higher number of motors. Second, I've been using way too many hinges and cramming too many small components into the joints, when I can just take the idea I was already planning on using for the head, and copy-paste it everywhere (with some modifications), an idea that's literally just sitting on my desk: ball joints. Of course, taking this route fully commits me to making Orchid a motorized marionette but luckily that just so happens to be my fetish and running paracord everywhere, but it's no more complicated than anything else and the loss in precision is acceptable for my purposes. Essentially, Orchid will be held together entirely by cable tension, and I'll have to apply material to lower the friction on her joints (Kiwi mentioned powdered graphite, which I may likely end up using), but at least I won't have to worry about hinges wearing out (I can just reprint any joints that fail instead). I still intend on using pipes for the bones, since it seems like the lightest and most efficient way to go. Also, it makes limb maintenence easier than ever. All I need to do in theory is open up the back panel, unhook the cables, and the limb will fall right off. The plush layer should be able to come off like a sleeve, as well (the head will be more complicated, but I can't think of a good way around that). Lastly, this is more quality of life than anything else, but I'm going to be changing some of Orchid's outer frame specifications as well. First off is her size. I just ended up charging forward with the idea that I'd make her a big mare, but she doesn't need to be that big. I do well in tight quarters, but when it gets to the point where basic things like carrying her or setting her in my lap become awkward (weight non-factoring), it's too much. There's also the eyes and mouth to consider. I still intend on making them screens, and decreasing the necessary size will make that load lighter. I'm still playing with the numbers, but I'll probably end up shaving off somewhere around 15~25% of her total volume. Not a massive decrease, but enough to make some things easier. Next is her horn. It's literally a plastic club that'd be getting a hit in on me and everything I keep on a shelf. Funnily enough, my original concept for her was actually an earth pony, but ended up migrating to unicorn for two reasons: Magical girls are cute, and a lot of the nerdier characters (the ones I usually like most) from the show are unicorns. But Orchid can be both of these things without a potentially hazardous addon, so she'll be going back to her original planned race. At any rate, it's back to the drawing board. I'm starting to feel like I might be getting somewhere with this, though.

Fits perfect. Now for the rest.

>>25532 Does your print bed have four posts? I've had this problem in the past, where the print bed would flex a bit if each screw wasn't set just so and I'd end up with a messed-up print.

>>25535 the printer itself is fine its just that the plastic was moving with the nozzle so it wouldn't draw a square. But I got some stick glue on the bed and that worked kind of.

>>25532 >>25533 >>25534 Looks like you Anons are all making great progress.

>>25314 Almost there

>>25563 Yeah, that's looking great Kiwi_. I think the rings will be a big help, and I like the lines for the supports too. Do you plan to do a neck ring as well for this test, or no?

>>25565 Yes, a ring for her neck and crotch are important for starving the mesh to pepper form. There still under development, I just shared what I've proven to be effective through IRL testing this far.

>>25566 Thank you. Good luck! :^)

I'm almost done printing the hand pieces. But it's been 3 days.

>>25580 >But it's been 3 days. It's hard at first, but hopefully you'll get your rigs set up to just 'fire and forget', then ring the bell when dinner is served. :^)

A prototype project on the Inventoor's Corner of the Doll Forum: https://dollforum.com/forum/viewtopic.php?t=161940

>>25586 Looks remarkable, thanks Anon! Very clean design. BTW, please spoiler things that are too suggestive (even if clearly robotic such as your pics). We maintain SFW here, primarily for the safety of engineering nerds at work. >tl;dr <Just imagine some dried-up old, token 3DPD, screeching-harpy coming along past Anon's cube right while he happens to be hovering over some of your pics. :D >=== -fmt, minor edit

>>25586 Amazing, thanks. I wish we had more anons keeping track of such sources and also like Thingyverse, and posting it here. That said, it should be moved after a while to the projects thread >>366 with a crosslink here.

>>25581 Well that's it. Wew lad time to get to putting it together.

I'm straying a bit from the instructions because I'm using micro servo motors instead of regular servo motors.

>>25597 >>25625 Woohoo! Good luck with your builds, Peteblank. Cheers. :^)

>>25626 Ty ty. Once we got the robot hand going I'll also might give it a camera and then you guys can work on the visual recognition so it reacts according to what it sees... right? I want it to be able to hold a banana lol Also I could use some help with the speech to speech tbh. Waifu ai got taken down. I still have the code that anon made so it activates depending on how loud the sound is though.

>>25627 Neat. Hands are complex and elegant 'tools' for anons and robowaifus to have for day-to-day life. Do your best with your build efforts on them Anon! >also might give it a camera and then you guys can work on the visual recognition so it reacts according to what it sees... right? Heh, I saw what you did there Anon. :^) BTW, OpenCV has some really good libraries for object detection [1][2][3][4]. I expect it will be an important part of the toolset for most robowaifuists tbh. >Also I could use some help with the speech to speech tbh. Waifu ai got taken down. I still have the code that anon made so it activates depending on how loud the sound is though. Glad to hear it's still working for you Peteblank. Yep, this is one very important part of why we all say save everything here. Quite apart from incidental problems going on with sites & servers, disk failures, etc., once the Globohomo gets wind of robowaifus -- and the important tools used to create robowaifus by anons -- there will be directed takedown/destruction attacks against these resources & sites; much like the glownigger gayops used to corrupt 4cuck & destroy 8ch. 1. https://opencv.org/blog/2020/10/27/multiple-object-tracking-in-realtime/ 2. https://www.geeksforgeeks.org/detect-an-object-with-opencv-python/ 3. https://towardsdatascience.com/how-to-detect-objects-in-real-time-using-opencv-and-python-c1ba0c2c69c0 4. learnopencv.com/image-recognition-and-object-detection-part1/ >=== -add 'save everything' cmnts -minor edit

>>25627 >Waifu ai got taken down What was this again? A website?

(i generally am a lurker, don't mind me) I have the files of waifu.ai on my drive thanks to data-hoarding, but it seems like the (more than garbage) AI was running on the dev's PC since it isn't generating any sentences anymore. Since the app runs on Unity I can only theorize that the dev suicided his project because of unity company cucks deciding to shoot themselves. >>25630 It basically was a (shitty) AI app on unity with a google TTS that generated responses in GPT-2 (i think? i don't remember but it was a shit model). It's actually one of the first (if not the first) 2D waifu AI type of thing. Might be dead wrong though, feel free to correct me.

>>25641 >(i generally am a lurker, don't mind me) Welcome Lurker-kun, thanks for peeping out! :^) Glad to know there are others saving.everything. here with us. Cheers. :^)

>>25645 Hi lol, thanks for the welcome. :D

Welcome. >>25641 I had this app for years, every time I tested it it didn't work. Never said anything or reacted to my voice. It's doesn't seem to be very big, so he can transfer it over to Godot, also why would the Unity pricing matter if the app is for free?

>>25630 It was also an API and it was available on rapidapi. I thought it was a good AI...

>>25684 Okay, then I'm sorry for your loss, I'm sure you find some alternative. If it was good it's hard to imagine that it was just GPT-2.

>>25685 >>25685 Thank you. Yeah I can host one I guess. On my computer probably run it on the localhost. I also I got these motors working somewhat but they're a bit erratic and random. Anyways I have to get a battery adapter for the Arduino(esp8266) to power it with a battery instead of the computer. I will get back to the speech to speech after the hand is working.

>>25686 This is really exciting progress to see Anon! GG.

>>25667 Sorry for late reply. Thanks for the welcome, and about your question I would say maybe it's a form of protesting (what a gay word but i don't have better words in mind) or that the dev realized he didn't want to bother in his project (which hasn't been updated in a very long time). It's very subjective really but I still think the whole unity shit caused that. Might be wrong, of course, but the timeline is too close for it to be a coincidence, in my opinion. >>25684 If you tried it and were satisfied, I still have a hard time imagining you had a decent experience with this AI but who am I to say otherwise. But yeah the AI was very old, I think it was GPT-2 or something similar. The responses were generated VERY fast, but that's because there were few parameters, just like if you use any pygmalion 3b model or less. It didn't have any long-term memory or knowledge about most of the stuff on the internet like a lot of models do now and generated random shit, which was funny at first when I used it but the fun ran out fast. If anyone wonders what AI to use, IF you have a war machine for a PC (and one of the latest RTX of NVDIA) you should use mythalion 13b (a combined mixture of LLAMA-2 open source models, pygmalion 13b and Mythomax 13b) by pygmalion. Open-sauce, maybe some tinkering is needed for best results and shorter response time, but I was very surprised with the fact we finally had a good open-source model. Best suited for conversations also. I tried doing some roleplay with it like it's possible with larger models but it was very average.

>>25709 I just remember the waifu ai was open to nsfw talk if you know what I mean and then it started acting pretty yandere which is kind of what I'm going for lol.

>>25709 >you should use mythalion 13b Thanks kindly for the recommendation Anon. Are you aware of any handholding setup tutorials applicable to this model?

>>25712 I know what you mean yup, if NSFW talks are your thing you should look into Pygmalion models, 90% of their AI model is made for NSFW, heard it performs very well in that regard >>25720 (pic only relevant at the end of this pile of text) Since I have a dogshit PC for running AI, I used horde, which is an API you connect do and use the GPUs of volunteers to run the AI, no information can be traced back to you although since pygmalion is open-source there is always the risk they change the code to be able to read what you send (though as long as you don't send any personal info you should be fine). The wiki of pygmalion is quite well-explained and complete though you'll have to do a bit of reading and see what works best for you, I didn't applied this guide myself since I use horde to avoid the hassle of hosting things myself, i'll send the link to the wiki a little after. To run Mythalion 13b or else, you'll need the following: 1. a GUI/Front-end interface since using everything from CMD is a bit inconvenient, for that I recommend SillyTavern https://sillytavernai.com/ really easy to install, you just have to launch start.bat once it is installed to run an instance (don't use oogabooga it's shit), to my knowledge you need to run the .bat file everytime you want to launch sillytavern 2. an AI model, the tricky part of setting shit up starts here, you either do like me the lazy way and use horde (at the risk that the hosters do bullshit like it happened with mythalion 13b which is why i don't use it anymore) or you download the AI model using git (install git if you don't have it already https://git-lfs.com) https://huggingface.co/PygmalionAI/mythalion-13b?clone=true 3. install a backend to run the AI, since I never went that far i'll give you the link to the pygmalion wiki which surely explains everything much better and more in-depth than I do: https://wikia.schneedc.com/ 4. run the AI using whatever backend you installed, and you're set to go I didn't explain how to use horde but if you're using sillytavern it'll select it by default if I remember correctly, otherwise check the picture Sorry if most what I sent is hard to understand or unorganized, I just generally use horde and don't host the AI myself heh

>>25727 you connect to* typo error my bad.

>>25727 Thanks but I heard about pygamalion before tbh. I'm just kind of lazy and wanted a ready made ai API. But even if another one comes up it's too unrealiable to try that again after what happened. Thanks though. I also need to make it so it's not reliant on aws. Espeak is a thing but it sounds too robotic. Anyways I'm trying to not get too ahead of myself. Now the hand then back to the ai. An anon did give me some code to activate the recording of speech after a noise threshold that was nice. If somebody could work on the visual recognition we could do this faster. Atleast experiment with it with your phone. The hand has 5 servo motors. It rotates from 0 to 180 degrees. That's the gist of it. Anyways I need a way to communicate between the orange pi 3 and the 8266. They're both wireless so it should be possible. I kind of want to see some collaboration tbh.

>>25709 >mythalion 13b Yeah, I've read about that as well. But these recommendations always change, and it depends if one wants instructions, chat or role-play. With these self-hosted models the prompt seems to be even more important, which is why I think it's gonna be crucial to use additional software for helping with that. The Huggingface Leaderboard might be helpful, maybe the 4chan threads on LLMs, but tbh I would also look into Reddit r/LocalLLaMA and such. For those with big GPUs Synthia-70B has been recommended for role-play, but also other things. Seems to run on one 24GB GPU while the rest is in system RAM and using the CPU. >>25712 Quite some models on HuggingFace (download, not API) are uncensored. All of that said, this thread is mainly meant for hardware and this convo around LLMs fits better into >>250, we should slowly but surely move over if it goes on. >>25729 Vision: >>97 - Pose estimation - Object detection - Face regocnition If you don't find anything there, ask there and someone might look around for more.

Boy this hand is turning out to be a lot of work. I'm not sure if it's missing some pieces. I don't want to print them again ugh.

>>25756 Here's a link to an inmoov hand back plate without the logo, probably not the only one: https://www.thingiverse.com/thing:621918

>>25757 The logo is okay. The idea is to cover it with silicon or tpe at some point later on anyways. I do have tpu filament actually...

Almost... that took a bit longer cause I had to reprint the fingers from another file.

>>25815 Great work, and I don't want to be nitpicky, but isn't this hand going to be to big?

>>25819 I guess I could have shrunk it a bit. But hey it doesn't matter if she has big hands...

It works but its far from perfect. The thumb in particular is kind of stiff. I don' know if it'd be able to hold something like a screwdriver or a pencil. A coke bottle maybe though.

>>25829 I think I did the thumb wrong brb

For some odd reason only the index finger and thumb are moving like they should.

>>25829 >>25830 >>25834 I guess this is about the string getting stuck. Maybe run a slightly bigger wire through it. Clean out the channels somehow.

I'm almost done but its not acting quiet like I want it. :\

>>25897 Proud of you Anon, it's coming right along. Maybe you should firmly affix your actuator's bases stably into the forearm shell first?

>>25898 I ended up uploading a video. There's still some stuff that needs to be done but I wanted to put it out there. https://youtu.be/xkP54ScFFRU?si=spdriWIHy4gXBodF

>>25899 Good job Peteblank, thanks! :^)

>>25926 Ty ty

After further experimentation, her design is going with the tensegrity variant. Only version which maintains the needed pressure to feel like you're holding someone. It's honestly been frustrating trying different thicknesses and designs. If anyone has advice, I would appreciate it. I'm so close.

>>26066 Looks impressive. Good luck!

>>26066 'Chinese finger trap' ridged collapsible tubing with tensile springs. I'd also say stuff the inside with dense memory foam but you're putting robotics and such in there. Pad the interior with a layer of dense foam an inch thick with spring collapsing tubes or a 'soft' hydraulics systems using plastic pistons sealed with a rubber stopper for slow compression and then n interior spring pushing back so when you let go it pushes back in place. Super low tech. BTW your print looks good.

>>26066 Like it's almost turn your support rods into a spring system or create two interior interior plates or solid strips, one front, one back, that hold the support struts right where you've got them, with a spring tube with mild resistance so when you squeeze everything can squish and reshape on it's own and you're not wobbling your struts too much. I'll draw a bad picture of what I mean if you want but I'm pretty sure you get what I'm saying.

Just a reminder to myself about some things I started, wanted to work on, or left off for a while: - Chest >>10291 - 3D Printed Bearings >>16735 - Simple head design >>14173 - Doll Waifu mechanisms: >>16772 >>8690 - Spring actuator: >>13711 - Lower arm bones: >>14474 (needs new approach) - Hands: >>16907 - Arm movement: >>14572 - Cycloidal Drive >>24401 - TITS (remote support input) >>9709 - Joystick Waifu / Simple Waifu: >>20091 >>21365 >>24955 -- Neck >>20431 -- Lever with servos >>21125 -- Assembly, planning >>18785 - Programmable GIF: >>26092 >>26105 - Cognitivie Architecture: >>24783 >>25950 -- Simple sketching language, pseudocode: >>7871 -- LangChain and similar agent frameworks >>25782 -- Pattern Matching: >>26062 -- Knowledge Bases: >>26058 >>25987 -- ACE framework >>26039 -- Listing all the human brain functions >>25274 -- Parsing RDF / Wikidata >>7357 >>19466 -- AIML chatbot language, support programs >>7355 >>7605 -- Heidegger, Existentialism, Dreyfus... >>7874 -- Some diagram: >>23794 -- Notes from podcasts: >>22318 -- Learning NLTK and preprocessing: >>7837 >>23749 - Human-Like Waifu: >>23646 -- Slicing the older body model: >>16958 -- Pelvis: >>23907 -- Squishable TPU: >>17630 -- Femur: >>12954 -- ToDo lists: >>16847 >>7615 -- Overview diagrams: >>13709 >>10670

>>26119 This is great, NoidoDev! Thanks. :^)

>>26068 >>26069 >>26070 Thanks, keeping your support strut idea for her internal structure. Me sliced design with curves to guide assembly. Will post prints of successful.

>>26153 Now you're talking. You're really homing in on the proper proportions + suitable joint ports. Printing flats really is the way to go for economical shell prototyping in smol batches.

>>26154 Meshtegrity works best for arms, legs, and other simple structures. I'm moving forward with a peice together design for her main body. Meshtegriry is taking too long. I'll try to return to it. For now, I want her to exist faster.

>>26358 OK sounds good Kiwi. That's a pretty good looking form there. Looking forward to seeing what you come up with Anon! Cheers. :^)

>>21647 >Prototypes and Failures #3 Some nice points about Henry Ford's eventual success with the highly-vaunted production Model T. > protip: It took him two prior failed businesses, and about 20 different prototypes, beginning with the Model A. < Ship Early, Ship Often https://web.archive.org/web/20160918000718/https://www.agencymabu.com/real-secret-behind-entrepreneur-henry-ford/ >=== -add funpost spoiler -minor edit

I can't hold Orchid's hoof, and I want to scream. I decided to solve the root of the problem by designing her hoof, though. Before we get into the hoof itself, I'd like to talk about aspect ratios. That is, how large something should be in comparison to everything else in mai waifu's body. Since she's being based on a cartoon body, this comes with the benefits and troubles of figuring out how said body should look and work. On one hand, I can make whatever proportions I want. On the other, so can everyone else, making reference images almost useless (I really tried, too). In the end, I basically eyeballed existing artwork, came up with rough figures from that, and refined some while leaving others as-is. It's a surprisingly complex subject when you put some thought to it, and I'll talk more about it another time. For now, I'll get right into it with the first attached plate, [Orchid Aspect Ratios]. Fig. 1 - Torso side profile i - Full height (to the withers) and width. I have decided to use this as the variable unit for measuring the ratio of every other component. That is to say, the "1:" you see in the picture is meant to be substituted with a real unit of measurement. You find the size of everything else by multiplying said number with every number you see on the plate. For instrance, If I decide that "1:" equals 25", and compare that to the hoof height [:0.1], I would simply do (25*.1) and get a result of 2.5". ii - The upper leg height, which is equal to half the height of Orchid. iii - The lower leg height, which is equal to half the height of Orchid minus the hoof height. iv - The hoof diameter. v - The hoof height. vi - The torso height. >update: [Fig.1 - iii]. That should be :0.4, not :0.45 Fig. 2 - Head side profile i - The height of the the base of the neck to the top of the head. ii - The height of the ears from the base to the tip. iii - The height of the head from the top of the snoot to the top of the head. iv - The height of the head from the bottom to the top of the snoot. v - The length of the snoot. vi - The length of the head from the back to the start of the snoot. vii - The height of the eyes. Fig. 3 - Torso front profile i - The width of the torso not counting the shoulders. ii - The width of the torso counting the shoulders. Fig. 4 - Torso top profile I hope you never come to know how much time I spent on what appears to be a low-effort peanut shape. To make a long story short, I decided that the perfect ratio of shoulders to hips is 1:1.3 i - The width of the torso at the front shoulders not counting the legs. ii - The width of the torso at the rear not counting the legs. Fig. 5 - Head front profile i - The width of the snoot ii - The width of the head on each side not counting the snoot. Also, in the lower right corner, you'll see my attempt at drawing Orchid with five eyes instead of three (since a lot of decent stereoscopic camera boards seem to have three lenses, I base the design on that). This may become relevant later. The most important thing to note here is that is mostly just acts as a guideline. Since her outer shell is projected to be faux fur over many cubic inches of polyfill, I have tons of room to make adjustments later with ease. There are a few major exceptions though, first and most prominently being the hooves. They are the only components of the skeletal frame that will be in direct contact with the outside world. Therefore, once construction begins, I'll need to keep the hoof size in mind, otherwise it'll look strange. At this time, I am assuming that the aforementioned variable equals 25". Now then, onto the hoof plan. Overall, it's just a slightly polished version of every other hoof-related sketch I've done before. In this design, I am attempting to have as few parts as possible, and to make this sturdy enough to conceivably not instantly buckle under Orchid's total weight (projected to be under 100lbs). Fig. 1 - Side view hoof articulation i - Leg pipe (PVC) and connecting structure. ii - Outer barrel (this is conntected to the leg). iii - Portion of outer barrel with track for hoof movement (~90°). iv - Inner barrel (this is connected to the hoof). v - Hoof. vi- Hollow potion of hoof. vii - Both inner and outer barrels will be covered in low-friction material (currently thinking of HDPE). Fig. 2 - Front view hoof articulation All numerals align with the previous [Fig]. This is just a different view. Fig. 3 - Hoof bottom view i - Hoof outer wall. This section will be flush with a layer of velvet for texture. ii - Inner hoof. This section will be velvet over a mostly empty pocket filled with polyfill, for softness. iii - Pressure sensor, so Orchid can tell when her hoof is resting against a surface (like a door, the floor, or my hand). --- As always, it's important to know that every mechanical component will in some way interact with fabric. With each moving part, I need to either prevent pinching, or minimize the consequences of pinching. Now then, I suppose it's time to touch CAD for the first time in nearly a decade. Except for the pressure sensors, I have everything I need to make the hooves. >=== -add update msg

>>27293 Ebin, Greentext anon. Very glad to see you get back in the saddle. :^)

>>27293 Aspect Ratio is needed to ensure she feels right. I recommend making rapid life sized 2D test prints to check how it feels. I'm starting to do that myself with my flattened Ai Chan design.

>>27297 >life sized prints That seems a bit unwieldy, especially since I don't own a printer that can accomodate ~50" wide paper. In coming up with these ratios, I've elected to calculate the actual sizes (with the [1:] variable ranging from 20~30") and hold up a tape measure. My out of control imagination takes care of the rest. With some pieces, I'll also compare measured sizes to parts of my own body. For instance, how does the potential size of Orchid's hoof compare to my hand? I'll want the hoof to be as substantial as possible while still allowing me to "cup" it (that is, have the front against the base of my palm and my fingers able to partially curl around the back of the frog). There's also the torso. It's size compared to my own will greatly affect cuddling in various positions. Now, I know myself well enough to know that I'll want to cuddle in all kinds of positions, and switch things up relatively frequently. I believe that having Orchid's torso length slightly less than my torso height, coupled with legs long enough to easily cover the depth of my torso, and her own torso being tall (she's a quadruped, so height=depth for my practical purposes) enough to feel substantial while also being shallow enough to wrap my arms around, is the ideal "jack of all trades" system. Let's use my favored base measurement of 25" as an example. Multiplying that against Orchid's torso height yeilds me a nice even 10". This is roughly 2" over the length of my upper arm from the point where it is "seperate" from my torso to the elbow (closer to 1", when accounting for the connecting tendons and muscle). Taking into consideration that Orchid's outer frame is soft, this should have just enough resistance to feel satisfying to sqeeze when I'm hugging her, while easily allowing me to fully wrap my arms around her. Measuring this against [0.35 (8.75")] for the front portion of her torso supports this with an advantageous ~10" from my elbow to the inner part of my wrist. On the opposite side, Orchid's albility to cuddle me will be limited more by her articulation than her limb length. With roughly 15" from the bottom of her torso to the ends of her hooves and perpendicular articulation at her shoulders, she has plenty of room to get past my own torso. Coupled with the fact that her legs will be >80% fluff by volume, the only thing preventing her from wrapping herself around me is my own reluctance go beyond the already outrageous 21 motors I'm currently planning to cram in her. It's still an incomplete science, though. I may lower the master variable and/or make minor adjustments to the final measurements (especially the head, that one's the roughest). I might even change the motor count (therefore changing the nature of her articulation). I'm confident that I can do it, though. If the ancient Greeks could use mathematics to measure the size of the Earth, I can use it to find the perfect way to cuddle mai waifu. That's all for the future though. My current philosophy is "frame first" and "one part at a time". I feel like I have a relatively solid design and a good size for the hooves, so I'll make those and fine-tune the rest as I go along. One thing I have to constantly remind myself of, though, is that this is just Orchid V1, so the design doesn't need to be perfect, just good enough. She'll always be perfect to me, anyways.

>>27297 Naicu. Looks a lot like Emmy! :^)

>>27297 Printed Aigis, now i'm certain she's exactly what I want. >>27306 Just use this to split up your design to print https://www.blockposters.com/ >>27323 Trying to make an Aigis Nandroid

>>27306 >I'm confident that I can do it, though. So am I Anon. Forward! >>27464 >Trying to make an Aigis Nandroid Excellent Kiwi, this is an interesting combo! :^) >=== -add'l resp

>>27466 Cute enough?

>>27472 YEP! She's wonderful. :^)

Made some of half of a pony pelvis. The human pelvis is much the same construction. It's going to use two sets of these motors to drive two legs, but all four motors will be fixed on-axis. The big gear will have the rest of the leg bolted onto it. Just realized half of the heavy motors are going to be all stacked at the top. I will need to re-arrange the leg motors in this pic facing the other way so the legs are positioned as wide and stable as possible. Grey is the spine, red is the bracket connected to the spine, blue is the bracket that connects both motors rigidly. Might do a motor where the red conmects to the grey and a motor that drives the spine itself.

>>27758 Attached is the fixed design. The motors that will be attached below the hip will drive the knee and ankle joints, and those motors will set the center of gravity to right below the hip joint. This way, the leg motors can be heavy and not take too much power to move back and forth repeatedly. A perfect solution would be what's called a bi-articular spring (spring force back and forth) on the hip joint that would make the two lower motors a "sprung mass", and/or depend on the hip motors for regenerative braking to slow down the leg without losing energy. I bet there's a spring like mechanism that could be turned on and off like an inductor, maybe in a future version it could have energy harvesting and active damping/springing with capacitors/ect. For now, it will remain an unsprung skeleton, and designed as simply as possible.

>>27759 It's nice to see someone else making progress on their robomare. I've got a few questions about yout design, if you don't mind: Is your waifu going to have a hardshell outer frame, is she going to be a plushbot, or something inbetween? How, if at all, are you handling lateral axial shoulder/hip rotation? One challenge I keep running into when drafting concepts is figuring out how to get her legs to 'spead' neatly. How will you be driving the knees and hooves? I've settled on using nylon rope to connect the motors to the joints, but I'd be interested to know if you have something else in mind. How will your waifu be able to tell what position her limbs are in? It looks like you're using motors with built-in sensors (based on the number of cables), but are you going to rely entirely on that or use external sensors?

I just started looking seriously into inmoov's myrobot lab. The interface is terrible but there's a lot of stuff here... somebody on discord said you can simulate the whole robot.

>>27765 Looking forward to hearing about your research into My Robot Lab, Anon. Cheers. :^)

Here is my workshop waifu v1.41. "Carry" was originally intended to carry tools as I worked on other projects, like that powerarmor behind her. But due to complications like the drive motors not being powerful enough and accidentally snapping the sd card containing her source code, she's been mothballed. Once I get my Spud finished I'll put Carry back together and retrofit. Learned so much since then.

>>27788 Carry is kinda charming tbh, Mechnomancer! Also: >Learned so much since then. is inspiring to all the rest of us, since you simply didn't quit. NEVER GIVE UP, NEVER SURRENDER! :^) Cheers. >=== -minor edit

>>27788 This is farther than anyone's gone before really amazing work but the robot working is half of it i think. The other half is sex appeal. Now you've come so far im sure making her look nice should pose no problem. Hell something like a simple mask would do wonders.

>>27788 I love your robot gwar cover band when do you guys release a new album? Metal thrashers will kill all humans was the best.

So for the spine concept I came up with this... not sure if this can be made to work somehow or if it needs a few design modifications. What do you guys think...

>>27799 oh I just thought of something. Instead of using a sphere on the end id use holes

>>27801 in fact now that i think about it. The spine is kind of like the finger really.

>>27799 Mechanisms like that are good for spines. This should help you https://hackaday.com/2016/09/13/the-bootup-guide-to-homebrew-two-stage-tentacle-mechanisms/

>>27799 >What do you guys think... As already discussed, I think you shouldn't doxx yourself. But since no kid is involved I'll leave it up to you here on out, since you already know the hazards you're letting yourself in for. If you change your mind, just ask and the image can be rm'd. --- As to your 'tentacle', laparoscope-like spine concept, I think it's a great idea! As mentioned it's straightforward to construct, and easily tunable with obvious mechanisms. Relatively lightweight too. Win-win. Just try to biomimic the human spine and you should be good to go, Peteblank. Good luck. >>27803 Neat! Very nice design there. Thanks for the link, Kiwi. Cheers. >ps: There are some really excellent reference links from that project : (>>27808) >=== -fmt, minor edit -add crosslink

I think i solved the spine problem. I added some holes. Now its fixed in place.

>>27883 Okay so now the question is how the spine is supposed to support the body... Im thinking we just make a big spine maybe.

>>27885 This may not be that fancy but it may single single highhandedly solve the flexibility problem. I got sophie dev to thank and that inmoov guy as well. Although inmoov may not be as essential as sophie dev really. And huh chobitsu thank you for making the site. tyty.

>>27899 Thing about the human spine is it gets a lot of force on it because of leverage multiplying forces from the limbs and such. If there is even a little give that is gonna spell disaster. Don't forget what articulates the spine (lets focus on the bit between the ribcage and pevis) isn't just muscle around the spine, but the abdominal muscles as well. That's why I'm going for basic motor joints for the torso, and even without power SPUD more or less freestands (extra mini bungees in there cuz I'm paranoid af about it).

>>27921 I am not knowledgeable enough to comment about it mathematically... However i think the spine can be made as big as you want so that might take care of it. Id make it like 4 times as big as that motor. Maybe thatd the the trick.

>>27922 Here is the file. https://files.catbox.moe/6ap818.stl I however still need to attach the strings to the servo motor/s before i can be sure it works right. I think it'll work...

>>27924 Okay so maybe we can collaborate then... If we are to collaborate however i do wish you replace the mouth with sophiedevs nutcracker, i think it work for an anime mouth. As for the skin i had the idea of using tpu filament and paint it like skin color. So we have the nutcracker mouth with the skin on top and voila. What do you think? I could work on the skin however i dont know the dimensions of your robot. I mean if you want to collaborate.

>>27925 Oh i also should say that the sex portion of the waifu is quiet important to me. So again if we are to collaborate she should have an onahole on her mouth.

>>27921 >even without power SPUD more or less freestands (extra mini bungees in there cuz I'm paranoid af about it). This. Our bones are what primarily gives us the strength to stand, not muscle activation. The combo of our skellingtons & it's passive (but flexible) fixation (in the form of biotensegrity) by the tendons/ligaments/fascia are all vital to our posture & mobility. >tl;dr For bipedalism: try to make your design 99.9% non-energy-consuming for the basic 'standing upright' posture. Then use a 'controlled-falling' paradigm for casual walking. >=== -minor edit

>>27929 Hm i see. Well my vertebrae are not energy consuming... Perhaps... Unless it leans forward. Again the priorities might be different. In my mind a robot waifu implies it being flexible. It all goes back to the sex you see.

>>27936 OK, well whichever way it goes Anon, study hard and just don't quit! Cheers. :^)

>>27945 I had thought about it earlier too actually. The vertebrae could be made bigger or two hydraulic tubes could be put on the hips in front. With the hydraulic tubes it would not move with a line/rope but rather with the hydraulic tubes maybe.

>>27948 okay you know what you want me to do with math. That's fine im going to stress test the vertebrae right now...

>>27950 Okay no. I can not stress test it because i don't have a small or small weights or any tools to measure strength... Still i don't know if I could assume it'd be the same on a bigger scale. Because right now its been held by little pieces of nylon string. However when I do press it down with my finger it is quiet sturdy let me tell you. However it hardly moves when I pull the strings then...

>>27951 >just don't quit! (>>27945)

Anyone have any ideas for the placement of a speaker in the waifu? I thought that it could use one of those speakers that turn any object into a speaker but that's all.

>>28618 That would fit well into >>24152 since this thread here is about prototypes someone build. >>28621

@Kiwi Nearing autosage. Confer : (>>28624)

>>28636 These are potential candidates for the next thread. One of the first two, one of the second two, then the last one or a new but similar one with all pictures, but some kind of meme as first pic, like in this post here.

>>28636 >>28637 Well, I think you should decide as usual Noido Dev. I personally like the idea of showing the most recent protoyping work in the OP. As for the memes, the final one is probably closest to my heart here! :^) TWAGMI

I tried to make a waste oil foundry for casting robowaifu parts while utilizing a waste product, but this project ended in failure. The foundry got so hot that it warped the aluminum bronze nozzle and the foundry couldn't get enough fuel. The project was also over budget. It would just be easier and cheaper to buy a devil's forge on Amazon. I've moved in to an apartment so I won't be able to work on a foundry for the foreseeable future. Here's the design if anyone wants to try their hand at a waste oil foundry.

These are a couple of mycelium bricks I made a while back while I was dicking around. I wanted to investigate if mycomaterials would be suitable for building robowaifus. The bricks have about the consistency of particle board, they are very light, they grow in the shape of their container, and blocks can be "biowelded" together (the bioweld here left something to be desired so further expirementation is needed.) The material is also a very good insulator, water resistant, and cheap I grew mine on cardboard, but sawdust, spent coffee grounds, and wood chips and other waste materials can be used. I'm going to make a proper incubator and further investigate mycomaterials. I understand this project might not end up benefiting the cause, but if it does work we would have a very cheap and accessible material for people to build with.

>>28699 Really cool Ribose, thanks! So, I presume you intend this material as a structural/structural-complement type of thing? I assume it's very important to keep it from getting wet? (b/c goes soft) Can you seal it up inside some kind of plastic film to help preserve it's mechanical characteristics? Regardless, glad to see you here again Anon! Cheers. :^)

>>28700 >So, I presume you intend this material as a structural/structural-complement type of thing What I envision is a structural component that can be grown in a desired shape and then biowelded with other pieces. So maybe 3d print a mold, grow the mycelium, then bioweld the parts together. I also want to play around with mycelium leather and potentially explore sensors in the future. >I assume it's very important to keep it from getting wet? It's pretty water resistant and water is required for the biowelding process. Still too much water and bacteria will start to grow. Especially if cardboard is used as the substrate. >Can you seal it up inside some kind of plastic film to help preserve it's mechanical characteristics? I will explore this idea and others in a future experiment.

>>28700 The topic of Mycelium has been brought up quite often in the materials thread e.g. here >>3058 and in the cyborg thread >>2184. In the later case more in regards to sensors and compute.

>>28700 >>28699 Looks like a hosting bed for black mold unless you use formaldehyde.

>>28704 The stuff is supposed to be pretty resistant to mold. I have a brick that is a few months old and still no mold growth. Granted I have kept the thing dry and inside.

>>28704 Black mold, scientifically known as Stachybotrys chartarum, is a type of mold that can grow on various organic materials under certain conditions. While mycelium-based materials are themselves derived from fungi (mycelium), it doesn't necessarily mean they will automatically support the growth of black mold. The growth of mold, including black mold, depends on several factors such as moisture, temperature, and the presence of organic matter. Mycelium-based materials are often designed to be resistant to mold growth, especially if they have been properly processed, dried, and treated. To prevent mold growth on mycelium-based materials, consider the following: 1. Proper Drying: Ensure that the mycelium material is thoroughly dried during the manufacturing process. Mold requires moisture to grow, and a dry environment inhibits its development. 2. Surface Treatments: Some surface treatments or coatings can be applied to mycelium-based materials to make them more resistant to mold. These treatments may include natural antimicrobial substances or other protective layers. 3. Environmental Control: Maintain the environment where the mycelium-based materials are stored or used. Keep humidity levels low and ensure proper ventilation to discourage mold growth. 4. Storage Conditions: Store the mycelium-based materials in a cool, dry place. Avoid exposing them to prolonged periods of high humidity. It's important to note that the specific resistance of mycelium-based materials to mold growth can vary depending on the formulation of the material and the specific manufacturing process used. If you are working with mycelium-based products, it's advisable to follow the manufacturer's guidelines for proper storage, use, and maintenance to minimize the risk of mold growth. If you observe mold on any material, including mycelium-based products, it's crucial to address the issue promptly. Cleaning and, if necessary, treating the affected area with appropriate antifungal solutions can help prevent further mold development.

>>28707 > I have a brick that is a few months old and still no mold growth. Granted I have kept the thing dry and inside. What kid of conditions are you exposing it to? Humidity, warm, humidity cold, dry warm, dry cold, what materials will be housed or adjunct to it, what size is your brick and can you do various samples of different sizes and shapes? (This is not me trying to tear you down or say it;s a bad idea I'm actually curious now. You have to control these conditions as a grower so I know you can run some tests) >>28709 What is this.

>>28710 >What kid of conditions are you exposing it to? This one I just kept around the house. Right now we are moving past the "dicking around" phase. Humidity, warm, humidity cold, dry warm, dry cold, what materials will be housed or adjunct to it, what size is your brick and can you do various samples of different sizes and shapes? The first batch of bricks were 4inX4inX1in and they can be grown at different sizes. I haven't tested how well they hold up to long term humidity yet.

>>28710 >>28707 For example, if you can guarantee perfect conditions, treat it with formaldehyde and then seal it with an epoxy or resin coat (if you're dealing with a consumer product then at some point there will be some regulator requiring the organic material be irradiated or treated with a sterilizing chemical for 'safety'(most of these cause interesting cancers), you would have a very strong and light weight skeleton with mild flexibility.

This thread is bumb locked since it reached it's maximum limit, I'll make a new one.

NEW THREAD: >>28715 NEW THREAD: >>28715 NEW THREAD: >>28715 NEW THREAD: >>28715