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.