>>15630 GitLab: https://gitlab.com/m9610/maidcom

Look forward to seeing all the great work on MaidCom, Kiwi!

>>15630 >Welcome to the /robowaifu/ board's project. Let me start out by saying I'm looking forward to working with you as a team-member on this project. I'm sure you're going to be a great leader for it! >Together, we will engineer a modular robot that will serve and provide companionship to their Anon faithfully. Modularity will be a huge boon to everyone here. It's more difficult to pull off correctly, but the rewards for it will be more than worth the effort I'm sure. Yes, I think companionship is a gigantic need in the world for men today, so yeah. < Faithfully Literally priceless. Onward! :^) >This robot will begin with a basic maid robot then move forward towards more capable robots with functionality approaching Chii/2B/Dorothy. Sound reasoning and wisdom IMO. Start small, grow big. Add functionality little-by-little. Test everything along the way. Keep the goal in mind--see the forest and not just the trees. Always take the hard road when faced with a dilemma. We follow all these keys and we will find good success I believe. >First goal is to have a meter tall robot which functions as a mobile server bearing an appearance that approximates her owners waifu. By 'server' you don't mean computers right? Rather more like the common term 'waitress'? I'm confident I already know the answer, but I just wanted that to clarified for everyone up front. Good for headpats! > >This should be completed by December 2022 with further major updates happening yearly until Anons can build a PersoCom class robot with relative ease and affordability. Great. I consider that pushing it for the deadline, but it would be glorious to have a board robowaifu up and going somewhere by Christmas! And yearly-releases thereafter is also a nice goal too. Cheers Kiwi, we're on the way with MaidCom. Long may she live!! :^)

>>15649 Looking forward to working you too, hope Gobi comes back and others join. >Server I legitimately meant she'd function as a mobile server. You could store media and other digital files on her. This would help to broaden her appeal. She's cute and functional, the Com of MaidCom means both companion and computer. Here's the body so far. I made a VRoid model then converted to .glb to inport it into Blender then exported STL files so others can tinker with them. The files are hosted on the projects GitLab. Further refined versions will be uploaded as progress is made.

Here's various designs for her leg mechanism. Which do you prefer? The teams opinions matter.

>>15664 >Which do you prefer? Well for starters, I'd say having a rigidized space-frame as a base for attaching the entire assembly securely to the hip's pivot is vital. You've apparently already accommodated this in 3 of your 4 design sketches (the crest triangle) so yeah, good to go there. >(fastest to build) Obviously, design iteration turnaround speed, at this very early prototyping phase, is critical to a good outcome for us all. That alone is reason enough to go with that rev IMO. >Ascento Your reverse-Ascento is a good design if we have powerful actuators available, as it increases the throw-rate of the distal ankle point. This means faster actuation rates (likely at the cost of faster energy consumption rates too). >Parallel Conversely, the parallel design choice is a smoother operation mechanism, and is probably a good compromise over the previous choice IMO.

>>15672 >Space-frame I'll work on incorporating the concept. Thanks for your input, I'm going to wait a bit to see if there's any other thoughts before moving forward. If no one else says anything, I'll go with the faster and cheaper method of springs.

>>15674 >I'll work on incorporating the concept. Excellent. Look forward to your designs ITT Anon. BTW, daily reminder that we are working for you. This is just friendly advice, I'd strongly suggest you let your own instincts be your chief guidance. I'm simply pointing out that fast iteration is always a benefit during a creative flow is all. I'm sure we'll find the right answers, Kiwi. Cheers.

>>15683 I'd still like feedback and ideas from the team though, it's starting to feel like it's just me and you. What are your thoughts on her computer system? I was thinking of tearing down old Chromebooks and running ROS on them then using an Arduino to interface with her motors and sensors. I figure this would be the easiest and cheapest way of doing things. Being easily built by the average Anon is one of the most important goals. Since you're on software, do you think this is the best route to run her software?

>>15688 >I'd still like feedback and ideas from the team though, it's starting to feel like it's just me and you. Then let us move forward with redoubled vigor! :^) As I mentioned to AllieDev, we'll see dramatically increased interest across the Internet once we have physical prototypes up and running. >What are your thoughts on her computer system? I was thinking of tearing down old Chromebooks and running ROS on them then using an Arduino to interface with her motors and sensors. I like the idea, fundamentally. It's certainly an expedient for quick production. There are still an abundance of old computers around. The Globohomo hasn't successfully destroyed them all quite yet thanks to hobbyist-minded nerds & hoarders. This is all to our favor ofc. As you're well aware weight is always an issue for us, so it would be nice if we had a standardized way to accommodate both breaking down a wide variety of old machines (rm'ing their cases, screens, battery compartments, etc., etc.), and installing the components in a roughly universal 'rack' inside the robowaifu. As to ROS, it's as good as other Linux variant revs atm, and far better than most for our needs. In the end however, we'll be needing something unpozzed to the greatest degree feasible. I suspect that will turn out being our own custom-written board software running on OpenBSD. But again, ROS is a good choice, especially at this very early phase. >I figure this would be the easiest and cheapest way of doing things. Being easily built by the average Anon is one of the most important goals. I absolutely applaud you in this goal, and strongly commend it to every single other anon on the board. We must find ways to simplify our robowaifu kits and make them approachable for the untrained man. And keeping our designs inexpensive also? Tip-top of the stack Mate! :^) >Since you're on software, do you think this is the best route to run her software? Again, sure. Ubuntu has good support and ROS has a fairly vibrant ecosystem. But to reiterate: both platforms are pozzed af and aren't tenable for us in the long run. Our un-pozzed robowaifus will prove far too "toxic & problematic" for the Globohomos to freely allow into their little safespace infobubbles. But we can address this revision years from now as greatly-increased resources allow us to. Let's use ROS now for our benefit as-is. >=== -minor grammar edit -add 'designs inexpensive' cmnt -minor prose edits -add 'toxic & problematic' cmnt

>>15691 Are you good at design? I've been racking my brain trying to make good legs but, I'm much better at the internals of a robot then her outer part.

>>15706 >good at design? Define 'good' haha. Sure, I'll be happy to give it a shot Kiwi. You're the leader of the project, so feel free to reject anything I may kludge together, I don't wear my emotions on my sleeve about such things. If my stuff is utter shite then hopefully other, actually-skilled, anons here will step up and help us out with this need right? :^) -idea: Why not just steal'borrow' Roll's character design? I think she's both suitable for your initial MaidCom goals AFAICT, and she's also popular enough. Neoteny is a potential issue, but we're already treading those treacherous waters anyway with a 1 meter tall robowaifu. Her leg designs in particular seem like they will support both your & AllieDev's quite similar concepts for a pair of wide, roller-based legs+feet. We could conceivably adapt this basic shell design with some type of modular engineered approach that supports most everyone's varied robowaifu designs moving forward. Twist-lock component connectors or something maybe? Hand connects to a wrist component, which connects to a forearm, elbow, shoulder, etc., for an example. Just use a Legos/K'Nex style mentality for connector interfaces, but types that take our much more rigorous structural demands into account. I leave that to you and the other ME/Industrial engineers. >I'm much better at the internals of a robot That's a far more complex and difficult endeavor than the outer shell character design work IMO, so great! Glad you are here with us to tackle that area. I'm sure your skills & efforts will be helpful to many different projects across the /robowaifu/ board, Kiwi. Cheers. >=== -minor grammar edit -prose edit

>>15707 >Just make Roll That makes sense, I'll do that. Thus far all my designs look like Boston Dynamic but skeletal. >Far more complex in my opinion It's all perspective, but thanks for your encouragement. I hope to have software work for us soon.

>>15711 >That makes sense, I'll do that. OK, sounds good. Just let me know if you need me to help with something specific here. >Thus far all my designs look like Boston Dynamic but skeletal. Haha, you could do far worse Kiwi! :^) >but thanks for your encouragement. Y/w Anon. It's exciting to see the project moving forward from our initial discussions so rapidly.

How's things coming along Kiwi? Seems like it's been a couple weeks or so since we've heard from you. Any updates on the character redesign? Just let us know if there's anything you need from us. Cheers.

>>15802 Been iterating on drive designs. I've simplified it down to a tail with a swivel drive. I'm hopeful a cheap easily built drive system will encourage adoption and others to build their own.

>>15822 >Been iterating on drive designs. Glad to hear Kiwi! >I've simplified it down to a tail with a swivel drive. Seems like a good concept, in general. MeidoDev seemed to be heading towards something similar as well. I like the idea that there's a sort of 'tripod' support base from which to locomote. With some internal stability mechanisms, we should be able to go far with it! :^) Also, >kemonomimicatgrill meidos, what's not to like!? >I'm hopeful a cheap easily built drive system will encourage adoption and others to build their own. I'm certainly pleased to hear you put things thus. This approach is going to be vital IMO. SophieDev and I had a couple of conversations about both the Wright Brothers & Henry Ford, and their initial efforts in their fields. I consider our current frontiersman work with robowaifus to be somewhat similar today, with one major difference: We're trying to give it all away! The closer we manage to come to your ideal, the better & broader the adoption with be. Let the robowaifu revolution commence soon! :^) Cheers.

>>15823 MeidoDev was onto something with trying to extrapolate the basic concept of an RC car into a waifu. His designs lacked rigidity and he wanted the drive mechanisms in her crotch from what I can tell, which would have made her topple over. I'm glad to have his reference, as fundamentally flawed as it was. Glad to hear you're on board with the current direction of the project partner. I'm currently thinking of switching to a simple DC motor as I think the use of steppers scares others off given the lack of interest in the project.

>>15830 >MeidoDev was onto something with trying to extrapolate the basic concept of an RC car into a waifu. >I'm glad to have his reference I agree! He has a good basic concept, and perhaps once we've achieved a working base prototype for the MaidCom project designs, he will find some valuable research material for his own? >Glad to hear you're on board with the current direction of the project partner. Heh, it's easy. You're plainly thinking ahead here. :^) >I'm currently thinking of switching to a simple DC motor [vs] steppers Certainly the cost reduction is beneficial, and I imagine that as far as drive systems go, we can devise electronics drivers + code that can satisfy the need effectively. We're engineers and designers. Dreamers, too! Our jobs are to take the differing, often conflicting, goals and fashion an amalgam that satisfies many constraints at once. This is a tricky business in general, and partly why our goals necessarily involve art, as well as science. I do and have urge everyone here to focus on artistry as well as the technical, maths, and sciences aspects of our varying projects. Truly a New Renaissance realm, is /robowaifu/ development! That Leo da Vinci guy would be proud of our audacity, I think... :^) Speaking of interest, we have a new team member Kiwi (>>15818). Maybe you can give him a welcome to the team and perhaps figure out together what name he would like to use here? Sounds like he might in fact be interested in the very RC cars-aspect of a MaidCom that you brought up. >=== -minor spelling edit

Some interesting designs to help inspire Meta Ronin and Madtrickster in their designs for MaidCom

>>15883 Good ideas. What about the Fuchikoma/Tachikoma wheeled-leg designs as an inspiration base Kiwi? Somewhat similar to our Wheelchair Waifu concepts in that it's an independent support & locomotion base (which the robowaifu can rise up from). But a) without the yuge sidewheels, and b) using it's legs can actually climb stairs too.

>>15897 Great suggestion Chobitsu! That design is truly fantastic in terms of stability and versatility.

>>15900 Glad you agree. It's also is a mobile 'wagon' of sorts, that can support a metric fun-ton of logistical supplies (batteries, batteries, batteries) and probably move at high-speed on an open smooth surface like roadways/sidewalks -- just like in my Chinese cartoons! :^)

>>15901 They can also store police in the butt! (Atleast in my Japanese cartoons! :^]) On a more serious note, a large backpack/butt is the one aspect of the design which should not be incorporated. Hoping to see Meta Ronin's and Madtrickster's concept art soon. I finally got my resin printer set up so I'll start printing concepts and tests tomorrow.

>>15902 >a large backpack/butt is the one aspect of the design which should not be incorporated. Fair enough, it certainly diminishes the 'unification' aesthetic of the thing as a robowaifu/mobility combo. Besides, there's plenty of other volume along the structural rails of the thing to support storage of batteries. >and probably move at high-speed on an open smooth surface like roadways/sidewalks BTW, if you decide this is a legitimate area to R&D, then I'd suggest we start out things simply by simply re-purposing scooter wheel/brake assemblies. After all, why ''re-invent the wheel'? :^)

>>15903 I've actually been looking into skateboard wheels with built in brushless motors. They have incredible torque for the price and are very easy to use. Just a tad pricey for prototypes. I like your thinking, it's good to remember that there are many parts we can repurpose.

>>15905 >I've actually been looking into skateboard wheels with built in brushless motors. They have incredible torque for the price and are very easy to use. Nice. Just keep the need for good braking in mind. We don't want our dear robowaifus to slip & topple down the stairs!

>>15906 I actually was really only thinking about electric breaking/using the detent torque of her drive for breaking. Active breaking external to the motor is a good idea for safety, I'll start considering it.

>>15908 >Active breaking external to the motor is a good idea for safety, I'll start considering it. Just a straightforward bicycle disc brake should be both lightweight, cheap, and sufficient, I'd say. Assuming we can locate ones small enough to work with skateboard wheels ofc.

Friday update for the project thus far: Team: Chobitsu and RobowaifuDev are on software. Meta Ronin and Madtrickster are on concept and design. To help solidify our projects goals, here's a list of topics that we will decide upon related to her design: What rods will we use for her internal frame? 3D printing an entire waifu would be arduous and time consuming. A basic frame based on internal rods connected via 3D printed parts would be faster to build and easier to repair. Though I am open to other opinions on her internal frame. Thus far I've been using 1/4 inch dowels. If no alternative is found, that will be the default. Will she wear clothes? Her design could be more skeletal and thus easier to build and repair if we rely on clothes to cover her. Functioning as an aesthetic and protective "skin". If she wears clothes, what size will she be? How will she be stored? (Aside from on the bed :^) How should she be transported? A large box? Within flight luggage? Should she be able to be folded, perhaps a transformation as suggested by Chobitsu? Should she be easily separated into various pieces? What physical capabilities are most essential? She will be capable of basic locomotion via a swerve drive (a rotary servo which positions her drive motor) with balancing wheels embedded in her soles. Beyond this absolute minimal configuration, what motions must she be capable of? (She will be upgradable, for now we are building a core for her Anon to work from.) Design and concepts are needed at this stage. If there are other aspects that you'd like discussed, please be vocal. Your thoughts are valued.

>>15972 Thanks for making this update Kywy. Glad to see you organizing things for us all. >A basic frame based on internal rods connected via 3D printed parts would be faster to build and easier to repair. This. I consider it a fundamental approach, at least until someone can do big injection molding operations for robowaifu shells. >Though I am open to other opinions on her internal frame. In the RW Foundations concepts, we sort of have this divided out into 2 parts: RW Bones, and RW Shell. The former is related to your frame questions, and the latter is kind of related to your 'clothes' question below. Personally, I currently see them as pretty inextricably-intertwined as a unified set for a final form of a robowaifu (at least for now). -What rods will we use for her internal frame? Well, as I see things we could use a) aluminum tubing b) wooden doweling c) plastic extruded tubing d) 3D-printed rods e) ??? Probably a mixture of types as we go along with development tbh. Certainly Aluminum tubing is durable, corrosion-resistant, reasonably inexpensive, and reasonably abundant. Given it's higher cost than simple wooden doweling, it's probably better to leave it for more sensitive/more durable zones like the robowaifu's upper chest/breadbox volume as an internal space-frame. Maybe the pelvic complex? Obviously wooden doweling is very abundant and quite inexpensive. It's a great choice by and large but obviously won't endure as well as aluminum, isn't as strong (generally), and is quite sensitive to moisture. Probably the bulk of a robowaifu's internal space-frame should be of this material. Plastic is available in an amazingly diverse array of forms and types, including widely-differing extruded tubing. I'd say the two most likely types are the standard PVC plumbing, etc., pipes, and drinking straws bundled together as Strawnon suggested. Plastic tubing is probably a second choice I'd say compared to the wooden dowels. Printing isn't the best choice IMO ATM. In the future with factory-type operations going, then the extreme customizability of such items is an inevitable appeal, possibly a deciding factor. But again, that's some years off. -Will she wear clothes? >"...and thus easier to build and repair if we rely on clothes to cover her." We could actually use something easily replaced such a literal paper (say card-stock), kind of in the same vein as Papercraft Anon suggested back in the day. If we ever need to get inside, we can simply cut that paper shell away, do our work, and then reapply new paper. One other idea along this line: we can spray-paint a primer onto the paper, then when it's dried apply thin layers of silicone on top of it. Not only would this be more pleasing to the touch, but would also form a nice protective seal around things. >"...Functioning as an aesthetic and protective "skin"." I think SophieDev demonstrated quite aptly the value of this approach. Sophie wears her clothes quite well. >"If she wears clothes, what size will she be?" Well we're dealing with a 1M tall robowaifu, so obviously child's sizes. IIRC they are based on age in years. So, a girl's size 5 or 6 maybe? Big costume stores probably stock girl-sized meido outfits I'd imagine. :^) Things will obviously be easier for us (in numerous ways, if more expensive) once we can into woman-sized robowaifus. However that's likely to be years from now once improvements in actuators, materials, and software and our designs are realized. So let's just make due in the meantime. -How will she be stored? I think simply designing her so she can curl up into a fetal position, and then use one of the easily-obtained big plastic tubs available at a big-box hardware store? A 'transformer' concept is a very nice idea, but the technical complexities involved probably rule it out anytime soon IMO. But who knows in the future? For now though, I'd suggest just going with the big tubs as storage containers. -What physical capabilities are most essential? Smiling, talking, and dexterous hands. Being able to locomote in some fashion. Those are the big ones IMO. Now having the full-force, sky-hifi-syfy visions of extremely personable and human-like robowaifus just like in my Chinese cartoons is the ultimate dream and the ultimate goal...we have to start small and grow big. Start simple and grow complex. The way of the Inventor. As we discussed, and as you've named the project, her Meido abilities will eventually be highly important. But for now simply being able to interact in an engaging way with Anon is a great & important start. And it's also probably quite within our reach within say a year or two. So IMO, simply filling my short-list given just above should be our motion priorities for now. It will be up to you to decide our actual directions however. Cheers. >=== -minor fmt edit -minor grammar edit -add 'pelvic complex' cmnt

>>15983 I don't think these tubes made out of thin chromed metal consist of aluminum. Also, it might be cheaper than wood, depended on the place of purchase.

>>15988 Good points Anon. Let's add Thin steel/tin tubing to the list of possible choices, I'd say.

>>15983 Thank you for your design input Chobitsu. >Metal tubing Definitily worth looking into, nice idea. >Papercraft Anon That was me, it's a lot more frustrating to work with then you'd expect. Also will crumble if worked with, even if coated/laminated. Have not tried layering silicone on it but, human clothes would be much simpler. Sophie does indeed demonstrate the value in wearing clothes. Given your input, current changes would be that she will wear clothes, womans xs, being a tad under 5 feet tall so that dresses don't look too weird on her. We'll figure out how to make that work. She'll be able to stand up/lay down, crouch/sit, and fold into a fetal position for transportation/storage. Hands will be a project once we get there. Still hoping to hear from other members of this project.

>>16013 >Thank you for your design input Chobitsu. Y/w Kywy. Looking forward to all the great things to come with MaidCom! >Metal tubing I'd suggest we use it sparingly, and in specifically-directed kind of way. A couple of basic points to note IMO: -The 'breadbox' (the RF/thermal/impact resistant protective container for computers/electronics in the chest) needs to be crush-resistant. An aluminum-tubing space frame (say 1/2" - 3/4" dia.) surrounding a copper-mesh 'box' (incl. it's cooling lines, wiring, etc) would go a long way to providing all the protections needed, at relatively low-mass. -Similarly, the pelvic-complex should also be a very sturdy space-frame. Not only does it need to the centroid-axis of the robowaifu's mass but it needs to stand up to *ahem* vigorous snu-snu. Wood is probably not the best choice here IMO. >Papercraft Anon >That was me LOL. I had no idea. I think we can use something else that's 'easily replaceable' then. Plastic sheets of some variety then? >...but, human clothes would be much simpler. Sophie does indeed demonstrate the value in wearing clothes. I don't really consider this either/or myself. There would be benefits in combining them. Sophie, while a wonderful robowaifu, is constrained currently to her display 'stand'. MaidCom will need to actively locomote and is likely to have lots of limb-motions. An external shell would help in several ways here, for instance keeping clothing from getting snagged down inside her joints. >Given your input, current changes would be that >she will wear clothes, womans xs, being a tad under 5 feet tall so that dresses don't look too weird on her. We'll figure out how to make that work. That will help, but will significantly increase our difficulties/delays. The laws of physics don't care about our design agendas haha. :^) >She'll be able to stand up/lay down, crouch/sit, and fold into a fetal position for transportation/storage. Sounds good, Anon. >Hands will be a project once we get there. Fair enough. Fortunately this has been a focus of a few anons around the Internet, so much of our design groundwork has already been laid for us.

>>15972 Head and eye movement are most essential for me. Moving objects by hand is second most important. Third is facial expression, and fourth, mobility. I'd like her to be poseable like a doll in the first prototype. Sitting up and stuff on her own isn't too important to me since I can't afford that many servos at the time being. I don't have much space in my closet so she'd have to be able to have her knees to her chest to go in there but that's not a big issue since I don't plan on storing her. It can take months to receive parts by mail where I live and the delays continue to get longer so I'd probably substitute the rods with 3D printed tubing rather than order parts hoping they're right and buying a hacksaw I only use once. >>16013 My robowaifu's model is designed to be 150 cm (4'11") and isn't designed to have realistic proportions. Given her underbust is only 46 cm, half the size of a woman, there really aren't any clothes on the market that will fit her so I've been planning to get her custom-made ones and throw a lab coat over her plastic shell in the meantime. I think adaptability of the design will be important so it can be reconfigured to different shapes and sizes. Smaller robowaifus will be much more practical to build. The dolls dancingdoll_rz makes are 60 cm (pic related) but creating hands at this scale is going to be a challenge, hence why I'm building a lifesize robowaifu. MaSiRo has fully working hands and she's 140 cm. Something to keep in mind though, by 2028 we'll likely have AI that can design robots through user feedback like DALL-E 2 and test millions of different designs to find the simplest and most efficient one. It might be possible then to do things we think are impossible now like 1:3 scale hands.

>>16025 >Metal protecting her controller and pelvis I definitely agree with metal protecting her main electronics. I think a more flexible option like silicone is better. Flexible enough to confrorm to various situaions rather then breaking. Metal could harm her Anon when showing their affection. >Plastic sheets I was researching prop production and, vacuum forming plastic sheets does appear to be the best way to produce large durable parts quickly. >Fabric snagged in joints Definitely important to design around. >>16034 >Facial movements Will be an option when we get to the point of developing her face. >Object manipulation Will be a very interesting point of development, long term goals do include her becoming more capable of maid duties as she improves over time. >Not having access to many servos I think designing her to have optional powered and unpowered options for every part is an important design goal. This will let people have a MaidCom with variable functionality dependant on what her Anon can afford/desires of her. From talking doll to fully functial maid. >Adaptablilty I made some quick sketches for a loose idea of a inner skeleton with mounting points for plates. This way she'd be a skeleton with various dimensions based on rod her rods lengths to meet her Anons ideals, then she would have custom plates to define her outer appaerance. This would add considerable comlexity to her development but, make her far more universal in potential applications. Third pic is an illustration of a robot girl that has clear panels to help communicate the idea. Welcome to the project RobowaifuDev! Care to share your dsign? Would be great to have you join Meta Ronin and Madtrickster in the design team. >=== -edit greeting

>>16034 >It can take months to receive parts by mail where I live and the delays continue to get longer so I'd probably substitute the rods with 3D printed tubing rather than order parts hoping they're right and buying a hacksaw I only use once. 3D printed tubing? Why? You can just outright buy pneumatic tubing by the meter. If you mean pistons then you can't go wrong with metal ones. 3D printed ones would not do too well with the focused pressure of a robowaifu's torso weight. >hence why I'm building a lifesize robowaifu. I am also making Pandora lifesized. She's more of a redesign and a bit taller than yours. Had come across some open source hand designs that looked very neat. Were a hell of a lot more complicated than the prosthetics floating around in recent months. >>16035 >Metal could harm her Anon when showing their affection. Just don't fist android girls. Duh. That's always been the rule. /s

>>16037 >This sticker may be needed :^)

>>16034 >dancingdoll_rz I had no idea his doll was such a cute. Thanks for posting her pic RobowaifuDev! I wonder if he knows about /robowaifu/ or no? > It might be possible then to do things we think are impossible now like 1:3 scale hands. What a time to be alive! :^) >>16035 >I think a more flexible option like silicone is better. Flexible enough to confrorm to various situaions rather then breaking. It's actually a rather complex issue tbh. As AllieDev points out, there are forces to account for. In fact, it's literally the nexus of several different types of stress, tension, torsion, and levered-compressions. The hips have to connect there. The spine has to connect there. She has to be able to bend over, stand up, twist, lean this way and that (often having to move around at the same time). Whenever she picks things up, that action at the distal end of her arms creates a thrown-weight force multiplier that must be directly counteracted right at her pelvis (and being re-transmitted out through the hip joints and down into the entire leg complexes). That's just with her normal day-to-day robowaifu ops! And add into that mix concerns over that one guy, the /clang/ers gonna clang Anon, and it will be remarkable that we can find a working solution for this one area that doesn't cost an arm an a leg with high-tensile compression-fused high-tech alloys. God's design of the woman's pelvic complex takes all this stuff into account -- and she has to bear children through there to boot! Truly astounding IMO. He's the Designer of the designers, the Engineer of the engineers. :^) >...vacuum forming plastic sheets does appear to be the best way to produce large durable parts quickly. Now you're talking, Kywy. (>>2654, >>5763, >>8736, >>9211, >>9233 term-related) >when we get to the point of developing her face. This domain happens to be a great interest for me personally BTW. >Third pic A cute!

>>16047 >Complex kinematic chains from hand to pelvis to ground I'm used to working with heavy metal robots bolted to the floor. An ultra light mobile waifu has fundamentally different physical properties that we must account for. As a failed med student (I suffer from severe vasovogal responses when presented with human blood stimuli, too squeamish to be a doctor.) I think relying on the designs the lord has blessed us with would be ideal. The human skeleton works by suspending bones in fascia, ligaments, and muscle. Whereby constant tension from this connective tissue provides the whole body with integrity via distributing loads across the connective tissues and bones. Allowing us to connect the kinematics of lifting something with our hands all the way to the ground, without relying on heavy rigid linkages that could individually handle the load. (2nd picrel illustrates a model of how this works in us.) Obviously, we are far too complex to be recreated wholly but, I can design a simplification based on the teams designs. /clang/ing can still be accomplished with this method too :^) I've attached some other pics to help inspire the design team. As a note, they do not need to worry too much about her internal designs, we'll figure that out after choosing her external design.

>>16057 >med student I know that was difficult, great effort Kywy. Personally I hope you can help many more people via MaidCom and our other robowaifus than you would have on that path of life. >"Never give up, never surrender!" :^) >An ultra light mobile waifu has fundamentally different physical properties that we must account for. >I think relying on the designs the lord has blessed us with would be ideal. I'm quite interested in medicine myself, and I'm a firm believer that biomimicry at the very least should be a foundational inspiration source for us all. Many great men of the past & present see it that way as well. While we're not "fearfully and wonderfully" knitting together robowaifus from the ground up with molecular-biology; yet in many ways we are afforded numerous advantages from the gifts of our prior human history of science, maths, engineering, beauty & design that have gone before us. 'Ultra light mobile waifus', being an actual possibility for instance. Not only do we not have to deal with the mass of approximately 70% water by volume, we also don't have nearly the degree of challenges with maintaining homeostasis and a million and one other things the Creator has to. And having an ultra-light robowaifu to work with brings brings metric boatloads of engineering benefits to the table, which all of us can capitalize on! >The human skeleton works by suspending bones in fascia, ligaments, and muscle. Whereby constant tension from this connective tissue provides the whole body with integrity via distributing loads across the connective tissues and bones. POTD. Excellent understanding and succinct writing too, Anon. I've personally suspected all along that some form of tensegrity would likely be the way for us to go. So many super-sized architectural and civil-engineering structures use it to great benefit, and the idea that 'if we can only find ways to design with it's approaches in a reasonably-compact volume for a robowaifu' is a readily-apparent one IMO. Your 2nd picrel suggests that we can. Sauces on these or other recommendations you have on this discipline Anon? We'll still need to further reinforce a few 'things' here and there to be able address the needs of high-impact clanging. >I can design a simplification based on the teams designs. I think that's neat. I would be pretty baffled by the effort I think. But, as AllieDev mentions we all have our parts to play. Drive on Kywy! :^) Cheers. >P.S. >I think the T-Rex feet are probably a good inspiration, foot-wise. Having a couple of levered 'toes' inside the outer shell of Roll's wide feet, with wheels attached to them fore and aft, would be a great design for sets of dynamically-adjusting hidden skates. >=== -minor grammar edit -minor fmt edit -minor prose edit

>>16059 Glad to have you onboard with the tensegrity idea. for further reading that can benefit us all: http://www.tensegrityinbiology.co.uk/biotensegrity/ https://www.anatomytrains.com/fascia/tensegrity/ https://tensegrityworld.com/ http://www.tensegriteit.nl/e-simple.html For a quick TLDR; by having strings connecting floating elements in tension, all forces must balance. If it doesn't, the system will collapse. An ideal tensegrity system (as demonstrated by both picrels) is designed to prevent that ollapse, often with redundant strings and/or incorporating elasticity in those elements. For a great demonstration, this tensegrity table (picrel 1) functions nearly identically to the tensegrity structure which allows the abdominals and latissimus dorsi to move the chest relative to the pelvis. The chest is balanced on the lower spinal column via a complex network of connective tissues and sinovial fluids, which acts basically the same way the center string of the table does. One of the out strings would be the abdominals with the other two outer strings representing the lats. The table would pivot in any of 360 degrees if you varried the tension of the three outer strings. The same way varying tension within our abs and lats causes our chests to pivot about our pelvis. Adding two more points to the table would give a complete tensegral model of the chest by accounting for the obliques that control our side to side chest movements. One could easily model such a system to move the chest of waifu using only 3 motors to control the tension of 6 points, similarly to a stewart platform. (See 3rd picrel)

>>16060 (For clarities sake, the lats move the chest in a twisting motion. The two strings acting as the lats would actually need to be crossed or, even more accurately, terminate in the center of the lower structure. My example is a gross oversimplification for demonstration purposes.) >=== -minor clarification edit

my update for April 1. In regard to the Maidobot program: a. Do we have a written list of required functions for the Maidobot? Some ideas I suppose i. Must be mobile (need not climb stairs, but should be able to navigate somewhat rough and uneven terrain) ii. Must be able to converse (Chatbot software + vocal recognition/voice emulation) iii. Must be able to Navigate (either through visual processing and/or internal modeling of the external environment) iv. Must be able to grasp, hold, manipulate objects with some degree of confidence and finesse (egg test) v. must be able to process commands and translate them into actionable procedures b. I made a few very rough pencil sketches that I will base more detailed designs on. I will share one concept that stands out: i. summary: moe-sized (<100cm) bot with ~70cm horizontal clearance. (Imagine something shaped like a bell) ii. the innovation: an airtight rubberized "skirt" with weighted hem. A turbine emitting downward from the torso creates positive pressure inflating the skirt providing lift, similar to "hovercraft". This increases movement speed and stability and decreases weight and friction with the ground (this feature is optional but maybe be useful for speedy movement or navigation where wheels fail or are impractical) iii. main mode of locomotion: Angled Wheels mounted "inside" each foot (similar to early Megaman/Reploid style boots), a slightly smaller stabilizing wheel is angled in the opposite direction from the "inside" edge of the boot but placed in the back for stability. The larger wheels are motor powered, the smaller wheels are passive and unpowered. Brakes are not yet a consideration as mass, and therefore total momentum should be negligible. iv. Dedicated smartphone dock, app on mobile device will emulate eyes and be the "brains". Auxillary pre/post-processing may be part of the chassis but will not initiate action on their own. v. Avoiding uncanny valley, will not have wig or "hair" but something in a similar shape of a high quality polymer or metal alloy. Visually pleasing in shape, hue, lustre and form. Enough to add a "feminine" quality. vi. Face: simple, heart-shape, small mouth. All ornamental, nothing functional or capable of movement. May be rigid or soft. Again, high quality to avoid cheap "toy" impressions. vii. Bendable waist (able to "bow" at 90 angle or more without tipping) viii. Gyroscopic stabilizers, placed on sides of "hips/thighs" oriented vertically. Weight in the lower 1/2 of body is ideal and may be mitigated by the positive air pressure under "skirt". ix. Reinforced shoulders: paying special attention to this aspect will ensure Maido's ability to manipulate and deliver objects of nominal weight (large bottle of "soda" or whatever you can imagine) x. Hands: multiple solutions are possible everything from "claw" to soft robotics. Ideally a hybrid of power/finesse that can pass the "egg test". That is the end of my report. I will submit more detailed diagrams and begin researching what parts are already commercially available versus what may need to be fabricated. Thank you for coming to my Ted Talk I'll catch up on the progress in this thread and respond with my thoughts in the next 24-48 hours. >=== -mv update to MaidCom post

>>16060 >Glad to have you onboard with the tensegrity idea. for further reading that can benefit us all: Thanks! I've been going through it slowly over the weekend. Rather than waiting until I've digested everything, I'll go ahead and give you the acknowledgement that yes, I'm very much supportive of the intent to benefit from (bio)tensegrity concepts as design inspirations. I first learned about them here on the board itself back in the day, and it instantly rang true for me then. >Light+Strong+Cheap <LOL, what's not to love!? :^) One of the reasons that Fuller, et al's geodesics work is that they use triangles. This is the foundation (and basically the only foundation) for space-frames; roughly by definition. The rigidized, co-planar nature of triangles is literally why space-frames work at all. So, my current thinking (again, not having gone through much of the material yet) is: Why don't we turn tensegrity 'inside-out'? That is, we could fashion an outer honeycomb shell composed of (possibly non-uniform, for aesthetic's sake) hexagon mesh(es), having very thin/light skin affixed over the hex frames (probably as a continuous film or sheet). On the interior surface of the hexagon frames could be tiny eyerings protruding at triangularly-chosen hex vertices. These rings would serve as tension mount-points to string tension cabling through (thin elastomeric nylon cording, for example). By utilizing clever arrangements of tension force lines (and turnbuckle-like devices such as a snap-on, two-ended linear brake for the cording to 'lock-in' the tension) we can rigidize the entire lightweight assembly from the inside. This should be lightweight, strong, cheap, easily-manufacturable, and offer literally hundreds of internal mount-points from which to attach additional (even multi-terminated, 'fan-like') cabling to drive limb articulations from a central 'power house' (such as your servo multiplexer). These articulation forces would be actuated via bidirectional (two-spool, conversely-wound), servo-attached spooling. Throw in a few strategically-placed (ie, near joints), spring-loaded, swivel-pulleys w/ attached, flexible guidetubes for the articulating cords, and Bob's your Uncle. :^) The articulation of both directions would also be naturally cross-tensioned (due to the bidirectional-spooling) and therefore capable of being high-precision controllable -- even under dynamic internal/external force loads! Both the forces of rigidization and the forces of articulation would be distributed roughly evenly across the shell's/internal framing's compression elements, in true tensegrity fashion (at least across a submodule component, such as an arm or leg, etc). During assembly, the tension-cabling can be 'knitted' along the inside of a limb from one end to the other, the shell halves fitted together, and the cords can then be firmly tensioned via the open end of the limb's 'tube'. The linear brakes can be snapped onto the opposing cords, and the cord ends can be trimmed in place. Actually, the 'linear' brake system probably should in fact be a ring in it's form. Several (say 8) tension cables can be fed out through it's radially-arranged eyeholes (subsequent to the 'knitting' step), tensioned firmly (down into little 'clutch' divots directly adjoining each hole), then the matching brake ring snapped down into/onto the first ring to secure the entire assembly together rigidly. This would also have the big benefit of leaving a clear 'port' located inside the limb's end for articulation cording, wiring, etc. to freely pass through. Additionally, perhaps some form of annular/radial sets of tiny turnbuckles might be incorporated to make later re-tensioning maintenance a breeze. Make sense Kywy? (>>12941, articulation-related) >=== -expand cmnt w/ 'linear brake' add'n -add 'rigidization', 'compression' cmnt -add pulley/guide cmnt -minor grammar edit -minor fmt edit -expand cmnt w/ 'honeycomb' -expand cmnt w/ 'driven-spooling' -add 'cross-tensioned' cmnt -add articulation crosslink -expand cmnt w/ 'spring-loaded' -expand cmnt w/ 'multi-terminated' -expand cmnt w/ 'attached, flexible' -expand cmnt w/ 'high-precision controllable' -expand cmnt w/ 'triangularly-chosen hex vertices' -expand cmnt w/ 'possibly non-uniform' -expand cmnt w/ 'internal/external force loads' -add 'tension-cabling can be 'knitted' cmnt -add 'ring brake' cmnts -add 'tiny turnbuckles' cmnt >lol, plainly a) I'm on a roll, and b) I should've waited a little longer before initially posting this haha. <tfw literally years of thoughts & ideas all come together during that one post :^)

>>16035 The model is far from done yet and only intended for 3D at the moment. I don't really know enough about mechanical engineering to come up with a usable design for a robot. >>16037 3D printed tubing is quite strong so long as you print it horizontally. If you print it vertically then it snaps in half under load. It just seems like a hassle to order parts when stores are always out of stock, overpriced or charge a kidney for shipping. Just driving to the post office costs me $20 in gas. For someone living near the city it might be better to buy but I'd rather print everything I can and reinforce parts with bolts in the Z axis where extra strength is needed. Ameca seems to have pretty advanced hands. I've been wondering how they're made. Do you have links to the hand designs you found? I've been thinking of going with Brunel from Open Bionics since it seems the simplest to implement a decently functional hand.

>>16077 I'm working on design documentation for MaidCom. https://docs.google.com/document/d/1KQqnWr3eTPegnPigpTv6FZQIpPWRYkVHtT_zz2wUuVY/edit Will allow access from others that demonstrate they are members of the project. >>16081 Very fascinating ideas, I'm considering how to incorporate your ideas. Will reply with more depth later. >>16089 Cool design, please do keep refining it. In consideration of how long this project is taking, we will now have hard deadlines. Starting with exterior designs needing to be submitted by Wednesday with Friday being the extended date if some progress can be demonstrated by Wednesday and the Anon requires further time.

>>16089 I had not known your situation makes gathering resources so difficult. Do you not live near a Dollar Tree or home improvement store? I try to design around what is readily available for Anons. Knowing what you have available will help in designing with your constraints in mind when possible. 3D printable rods were always part of this either way.

>>16081 Still thinking of your design suggestions and was wondering if there is some hexagon mesh material that's prefabbed? Like a plastic role of hexagonal mesh? >>16077 For confirmation, was it you that just requested editing access?

>>16096 yes, I did

>>16097 Access granted

>>16091 >Very fascinating ideas, I'm considering how to incorporate your ideas. Will reply with more depth later. >>16096 >Still thinking of your design suggestions and was wondering if there is some hexagon mesh material that's prefabbed? Like a plastic role of hexagonal mesh? I'm not specifically aware of any yet, no. OTOH Kywy, it seems an obvious need AFAICT and I imagine that a few men have already recognized/devised solutions for this specific manufacturing challenge before now. I consider it likely that some type of aerospace/automotive/boating concerns surely have devised a honeycomb roll material -- possibly even as an aftermarket product -- before now? Just remember that in a top-flight engineering approach to the laminate, the compression elements need to be rigid (even if the substance comprising the hexagon vertices doesn't.) The whole thing should be both durable and lightweight ofc. In the meantime, something that's simply corrugated and reasonably durable (for example automobile 'sunscreens' or even just laminated, corrugated cardboard) could suffice for the initial prototyping design 'sketches'. And sewing needles with sturdy thread should be able to stand in for the internal cord weaving too, I'd suspect. Anyway, glad you like the concepts Anon. As I joked about, turns out that one post was kind of a crystallization of years of thought towards our needs. It's not the only possible approach, but it offers a way forward for at least a dozen different issues we all share here on /robowaifu/. I hope it's of practical value and some sketches of your take on it would be of tremendous help too. :^) >=== -various prose & grammar edits

>>16089 WOW, she's gonna be awesome Anon! You're truly a man of many talents. Looking forward to seeing where you go with your waifu RobowaifuDev. >Just driving to the post office costs me $20 in gas. Living the dream tbh. I applaud your life choices Anon. May they reward you manyfold in the future.

>>16104 I've done some resaerch and have found many hexagonal meshes. Here's a basic internal design. Designs are due for everyone, hoping to see a few, I value everyones ideas.

>>16108 >I've done some resaerch and have found many hexagonal meshes. Great! Glad to hear it. I have a pretty clear idea in my mind what I myself would want to use. If you have a list for us, I'll go through them all and see if it's in there. I'll know it the moment I see it. >Here's a basic internal design. Excellent! I can really see the 'floating chest' with that diagram much better than I could with the little table image (and even that I could see it from you good descriptions and the anatomy graphic). Looks like tensegrity is back on the menu boys! :^)

Any updates from the design team?

What's going on with everyone in the design team? Meta Ronin, Madtrickster, and RobowaifuDev, how are your design efforts going? Is there a way I could help you in designing her external design? We are kind here, any progress is appreciated and any help needed will be provided by the rest of the team to the best of our collective capability.

>>16114 Yes, sometime this weekend. I work fulltime through the week so weekends are when I have any time to really settle in and work out any ideas in detail.

>>16111 I'll have a look at things this weekend Kywy. Probably post something ITT on Sunday/Monday.

>>16120 >>16121 Thanks for the updates. All members, please reply with the day of the week you can work on waifus so we can work out a schedule for the project.

>>16123 Usually I have weekends free and sometimes a weekday. >>16118 Here's an idea for the shell that has been floating in my head for months but I have no idea how feasible it is and I'm spread too thin across my projects to focus on design. Pretty much everything I've been working on is to create a foundation for conversational AI. I could use some feedback on what particular features are desired most in MaidCom, since each of these takes a few weeks to a few months to implement. Some things I've already started: >adjustable personality and voice >finetuning with reinforcement learning and human feedback >situational awareness (starting with the time and date and how long a response took) >user-defined commands, tasks and events via natural language (such as telling her to check Arxiv once a day via a user-defined API and report anything interesting the next time you chat) >guided sampling (language models often generate nonsense due to having no particular goal; reinforcement learning greatly improves this but the actual problem is in the generated tokens being inferred solely from the context which is missing the user's intention) >discerning when something is not known and stating that, rather than making things up And some ones I want to work towards in the future: >long-term memory >using Monte Carlo tree search to spend extra time generating responses to find a much better one (and using this to further improve the model) >speech recognition (expanding adjustable voices into an augmented cycle GAN model that goes from audio to text back to audio again to expand the variety of voices that can be generated and recognized, as well as save memory) >learning from mistakes (guided sampling and a long-term memory will go a long way here) >learning to discern useful features through interacting, such as the user's preferences, mood and intentions >ability to respond to and learn from images, audio and video >web search >singing >automating tasks by generating python scripts >answering programming questions and other technical topics >logical reasoning from first principles (requires a good long-term memory with few retrieval failures) >introspection (analysing the language model and memory to correct inconsistencies and deepen understanding) >curiosity-driven play in games (as a foundation for simulation training) >learning to walk and manipulate objects in a simulation to achieve a goal in natural language

>>16132 POTD. Sauce on pic Anon? BTW, I mean to take all your requirements, advice, and theoretical postions to heart in the RW Foundations project RobowaifuDev (>>14409), whether you ever participate directly in it with us or not. I hope at the least you'll offer your blessings to us in that endeavor. You have amassed a tremendous degree of knowledge, wisdom, and insight into this entire sub-arena so highly pertinent to robowaifu development. We'd all be fools not to capitalize on your efforts here. >tl;dr I commend every.single.anon. here to pay close attention to what this anon has to say. He's been a part of /robowaifu/ from it's very beginning. He's studious, consistent, creative, and extremely intelligent. If we ever manage to have intelligent conversations with our robowaifus on inexpensive systems that don't connect up to the Globohomo Big-Tech/Gov's systems, it will be RobowaifuDev who's pioneering that frontier for us first-and-foremost. >=== -minor prose edit

>>16132 >AI Your conversational AI work is exactly on point. Learning from mistakes and maintaining long-term memory are the most valuable areas to focus on for future development. Those will allow her to grow and adapt to her Anon at a basic level. My personal suggestion would be to give her a meta editor, a subconscious that updates a dynamic database with new variables and values as needed. For example, her Anon could tell her that every Tuesday he has a meeting around 2 P.M. The meta editor would find the Tuesday entry of her database then append in: Meeting == 2 P.M. Then when her Anon asks when his Tuesday meeting is, she will respond that it's at 2 P.M. If her Anon then told her that his Tuesday meetings were now at 1 P.M. the meta editor would change the value assigned to the Meeting variable. Would be cute to store this table as "Memories.CSV". What are your thoughts on this approach? >Design Absolutely adore your design Anon. I appreciate that you clearly thought of how she could be fabricated. those small panels are a clever way to cut down on printing time. I've alluded to such being a design goal and I'm glad you figured out how to make the concept work on a practical and aesthetic level. >Broom Chucks Topkek Looking forward to Meta Ronins contribution and potentially Madtricksters as well. Though, your design is frankly already almost exactly what I was hoping for.

Haven't read read the design doc yet (google's asking for a login and I ain't logging in to that shit on main). Here are my general questions: 1. Who is on board with the project? 2. Have you settled on a desired feature set/user experience for the first deadline (Dec 2022)? 3. Are you willing to use external collaboaration tools/chatrooms like matrix? (not counting the Gdoc you already have)

>>16149 1. Team Lead: Kywy Design: Meta Ronin, RobowaifuDev, and Madtrickster Software: Chobitsu and RobowaifuDev 2. Yes, by Dec 2022 she will be capable of following her Anon and carrying out basic conversations. These conversations will include the ability to give her simple commands such as moving to a desired location. Of course, we would like her to be far more capable by then. Having the capacity to grasp objects and accomplish basic tasks based on audio/visual/hands-on training. Such as being trained to fetch her Anon a drink from a clearly labeled area. 3. Sure, though I'm completely unfamiliar with matrix and this platform would need to be usable by all members.

>>16149 An amendment to my response on your third point; Chobitsu is uncomfortable with using matrix for valid reasons. We already have plenty of room to chat it out on the board and there's no reason for secrecy. As for accessing the Google Doc, I'd like to host a copy of it here in a stickied thread that Chobitsu would update when necessary if he would agree to it. This project is meant to be a united effort open to us all so, having a version that is readable here would be good.

>>16123 >All members, please reply with the day of the week you can work on waifus so we can work out a schedule for the project. I'm obsessive about this during this current period of my life Kywy. I work on robowaifus and robowaifu-accessories basically all day, erry day., 6 days a week at least. >tl;dr ATM, any day's fine for me. I would observe that we have had historical upticks in traffic for years on Sundays, roughly 12-24h GMT. >=== -add 'Hank Hill' ref

>>16111 >>16121 Kywy, I know I said I'd have something by Monday, but it's not looking like I'll hit that. Mind giving me till next Sunday/Monday?

I'm here and presently working on this. Flying back east tomorrow for a few weeks but I will be in touch since I predict at least some down time. I like the organization that is taking place. Focus focus focus! Taking concrete steps is how we obtain results.

This is a prototype for a more detailed sketch with exact dimensions. In this example 1 grid = 2.0 cm. This example represents a 100cm form factor but here it is only about 80cm. Considerations in this sketch are: - head to body radio - does size of head accommodate 20 x 8 cm mobile device for "eye" emulation, master controller app, I/O considerations - frame with specialized (and interchangeable) hard points arranged in hexagonal symmetry with one additional (7th) hard point on the negative Z axis for backpack/power supply/toolkit module - universal "snap-lock" type mechanism (yet to be designed) for fixing modules to hard point. "modules" include neck, arms (2), legs (2), 6th (between legs), 7th (back). The idea is the snaplock is a ball type fixture that inserts, twists and snaps or screws into place and may also be removed as easily but not inadvertently during function. I will work on designing this feature. - removable "boot". Maido/Maidfu can recline, sit, lie down, etc. without boot, at the owner's wish. - Boot is Roll/Reploid style with some exxageration, powered by two angled wheels with two passive support wheels angled opposite "inside" and "rear" for balance (4 points of contact with the ground) Boots may be braced together if the additional stability is required. - joints must have ports or "room" for routing power and control wires/cables I will refine this design and provide more exact specifications next revision I will *design* concept for hardpoint snap-lock system I will *brainstorm* - modular joints (replace one type of hand/arm with another) - power delivery methods (for both arms/hands and leg wheels) - incorporating tensegrity into frame via cables for additional stability - specialized servos to provide force where needed but allowing for flexibility and "give" where needed. Strongly considering solenoid applications. I would like to make use of available servos and solenoids but arrange and apply them in novel ways to meet these requirements. This concludes my update for this week. Will have more next week, however I have family events all weekend so this may delay my update until Monday or Tuesday of the following week.

>>16158 >>16159 Thank you for your update. I'll extend the deadline until May 16th. If there is any way I can help as an engineer, please do ask. >>16161 >>16163 Thanks for your update Meta Ronin. Glad to see the high level of thought put into your design work. I've been brainstorming connectors and look forward to comparing our designs, the ball part has struck some inspiration. The removable drive boots are likely to make it into the final design as they're good for balance, acting as training wheels until active balancing is worked on. I'm curious on how you'll integrate your ideas on an engineering level, I'll endeavor to distill my ideas into clearer designs to share by Wednesday. I hope my ideas will help you hone yours when you get a chance to think between/after your family events. I hope your family events are jovial and blessed. (picrel is a cute OC reploid that vaguely encapulates elements from both designs submitted thus far.)

>>16139 /robowaifu/ :^) The design was inspired by @61laboratory, Aigis, Cocona Kosaka, Ameca and InMoov. I'll reply to the thread in a bit. >>16142 >Learning from mistakes and maintaining long-term memory are the most valuable areas to focus on for future development. Those will allow her to grow and adapt to her Anon at a basic level. Agreed. Something else that could be tried too is imitation learning. I grew up playing with the Daisy chatbot that starts off knowing no words at all but gradually learns to form more and more complex sentences by imitating the user and making corrections from user feedback. I was obsessed with that program as a kid because it was the closest thing to having my own Chii. >My personal suggestion would be to give her a meta editor The memories will be editable but editing them directly will only be for debugging. Remembering the new time for a meeting should be simple as telling her. I'm strongly against the idea of changing memories. The most relevant memories should always rise to the surface. Outdated rarely-accessed information will gradually sink away but still be accessible with very specific queries, such as "what time was my meeting before it changed to 1 PM?" She should remember anon had a meeting at 2 PM but it was changed later to 1 PM and perhaps use this new information for other things such as starting dinner an hour early. And if anon needs his full schedule or a report of anything stored in her memories, then she can generate it and return a CSV file if desired. Also memories have dependencies so tinkering with them will likely cause undefined behaviour. If she remembers anon likes having his favourite food with rice and his favourite food is chicken but he changes his favourite food later to pizza, then he's going to have humorous situations like her serving pizza with rice. By only adding new memories though she can resolve this by knowing that memory was true when his favourite food was chicken and that he probably still likes chicken with rice but his new favourite food now is pizza. This is why I'm working on situational awareness because the time of events is really important.

>>16165 There's a misunderstanding, I meant the meta editor would be an internal editor for her definitions database. Her Anon wouldn't edit it directly, the editor would instead pick up on contextual clues from her conversations to edit the database as needed. From the way you're talking, it seems that AI could do something similar without need of external database. I have experience in manufacturing and programmed a database using Jupyter Notebook so that users could alter the values for variables without direct access to the programs which referenced those variables. I thought something similar could work with a convoluted network of AI instead of human input. Kind of similar to how a human mind functions with many discrete subconscious processes that update our active and long term memories based on the input of other processes. I'm not particularly familiar with AI, though I understand psychology from my med student days and databases so that's where my frame of reference comes from. If you believe a single AI would do the job better then separate specialized AI working in parallel, I'll trust your judgement. You've demonstrated your knowledge and a mindfulness for context beyond what I would consider. I'm looking forward to seeing where your personality AI will go. Though, I must add that current plans include running a version of her software as an application for Android phones and GNU/Linux computers. Please do share your thoughts on the matter. You and Chobitsu are working on the software and it's important that hardware matches.

>>16164 >I'll extend the deadline until May 16th Thanks! >If there is any way I can help as an engineer, please do ask. At first I figured it was the compression element force-line distributions across the shell, with such small hexes (compared to the notably larger-hex arrangement in my mental image). But then I realized that the forces will still be distributed effectively -- regardless of scale -- as long as the 'edges' are in fact (nearly) incompressible. The "neighboring hexes' linear-angle offsets" also becomes more finicky w/ a small hex scale (it is necessary to maintain an (concave, interior-relative) angle there, as co-linear edges would simply collapse under the inward tensions [think: the strength of arches vs. lintels]). But still doable, design-engineering wise. Now it's more of a manufacture-engineering question with such a small-hex mesh. My original intent had been to use 'knitting needle'-like probes to thread the tension cords into the interior-oriented eyehole guides from the outside in. This should be automatable w/o too much investment (our concerns), or doable by-hand for Joe Anon with his kit (hobbyist's concerns). This becomes a much more challenging proposition (particularly by-hand) with a small-hex mesh vs. a large-hex mesh. So, the weaving process looks to be more expensive in overall effort than I originally conceived. OTOH, having a readily-available hexagon-mesh material is a yuge benefit obvs. So, it's a bit of a mixed bag in my head ATM. :^) >=== -minor sp, grmr, & fmt edit -add 'linear-angle offsets' cmnt -add 'arches vs. lintels' cmnt -add 'across the shell' cmnt -add 'interior-oriented eyehole' cmnt -add 'challenging proposition' cmnt -clarify large-vs-small hex distinctions

>>16167 Hole sizes vary tremendously, I could devise a machine to sow together something like this with a few months of time and enough resources. I've been thinking of using molds based on some open source mannequin to form a mesh then sow cords onto that mesh to maintain the form through tension. Those meshes would then be sown together to form her body with servos strategically placed to actuate her via tugging her cords. At least, this is my understanding of your idea and how I would go about manufacturing it. Final result being similar to second picrel.

>>16170 Second pic didn't show up, here it is.

>>16170 >>16171 Yes, that's much more like it (particularly the 2nd picrel). My conception is of hexes composed of rigid (3D-printed, to begin with) rods, arranged into varying-sized hexagons (again, to accommodate aesthetic designs better), and 'conjoined' by tri-socket 'vertices' composed of slightly compressible (say ~2%-5%, nominal load) material. The hexes would nominally be, say, 2cm-10cm in scale (depending on criticality of local-neighborhood stress & transfer forces [ie, tighter arrangements near to joints, etc.]). This would be a very lightweight construction approach for what would effectively be an exoskeleton-frame design. A very thin & lightweight skin can be adhered (post-assembly+weaving) over the exo-shell frame. As in your 2nd picrel, the system would maintain it's shape under no loads (but gravity). The tensegrity-weaving comes into play thereafter as a 'force-multiplier' effect to greatly increase the rigidity of the forms for only minor increase in masses. A tensegrity-based exo-shell would also fare much better against fast or slow strain effects (internal or external), as the forces get distributed roughly-evenly across the sub-component (ie, a chest, arm, or leg) frames. Make sense Kywy? >=== -add '2cm - 8cm' cmnt -add 'exo-shell' cmnts -add 'local-region stress forces' cmnt -minor fmt edit -add 'fast or slow strain effects' cmnt

>>16172 3D printing the meshes actually makes a lot of sense. A PETG and TPU hybrid material would be perfect but, for now PETG would be ideal based on current low cost consumer options. I'm drawing up a design for basic elements of this design for 3D printing/molding, will post those soon. From what you're describing, we could model her forms, then use variational surface cutting to print her mesh flat and sow them into form. https://www.cs.cmu.edu/~kmcrane/Projects/VariationalCuts/

>>16173 >From what you're describing, we could model her forms, then use variational surface cutting to print her mesh flat and sow them into form. Brilliant. I'd suggest proceeding with design explorations in this direction. Should it prove successful, I'd say we've advanced the state of the art in low-cost, lightweight, robotics (indeed many applications) exo-shell manufacturing. What a time to be alive! :^)

>>16174 Here's a quick drawing of my idea for her meshes nexus points.

>>16175 That's it. You've practically seen inside my head Anon. Now, there will need to be a slight inward angle to all 3 'legs' of the nexus (the arch-based forces, right?). This will naturally occur as the hex-meshes are formed around, and sewn into place. On the interior (concave) side of the central axis of the nexus is the mount-point for the tensegrity eyeholes (protruding inwards, down along the inverse-'normal' of that point). Tension forces applied (roughly) inwards here at this focus point will distribute forces pretty evenly into it's 'pyramid-edge' rods, and radiating outwards from that nexus as compression forces. Thence to the neighboring nexuses, etc., etc. Sew cleverly-arranged, opposing, force-lines back and forth across the interior volume, snug everything down tight, and Voilà! You've just created an 'inside-out' tensegrity structure, Anon. :^) BTW, I don't think these eyeholes need be on every nexus (in fact probably not), and also don't need to be printed in-place. Rather they can be affixed into the assembled mesh post-facto (though prior to the forming/sewing steps). They may possibly be made of actual small metallic rings (or some other strong material resistant to fracture), mounted or screwed in. Possibly just use the cheap, brass or steel, wood-screw eyeholes readily-available at a hardware store? Again, these eyeholes are the tension-cord mount points, as well as the actuator-cord mount points too. >=== -add 'small metallic rings' cmnt -minor fmt, grmr edit -add 'sewn into place' cmnt -add 'forming/sewing steps' cmnt -add 'distribute forces' cmnt -add 'hardware store eyeholes' cmnt -add 'Voilà!' cmnt

I think I have enough info to start making plans, I'll get some charts made when I get the chance. I see that this is an ambitious project with planned features far beyond "follow anon". This means getting a modular, easily re-configurable architecture down (like the aforementioned WaifuAPI) will be critical in the long run.

>>16176 Glad we are on the same page Chobitsu. I'm feeling very confident in this new direction. After much thought on how this would work from a robotics, manufacturing, and durability perspective, I've decided to go with a tensioned mesh approach first. I'm considering different anchoring ideas and we'll need to test various options. I'm think this concept should be dubbed "meshtegrity". >>16178 I look forward to seeing your charts. It is indeed a very complex project with much to be done. Which is why we need good coordination and communication.

>>16181 >I'm think this concept should be dubbed "meshtegrity". It Begins :^)

(Explanation of chart) 1. First, we have to officially get the requirements/features set in stone for the December release. 2. Once we know what features we want, we can make a bill of materials/components that the design needs to house (Battery, microphone, camera, etc) (the hardware design team can take care of the specifics as they experiment with different components) 3. Make a mechanical prototype to make sure the robot can move and house the necessary hardware. 4. Once the robot can move and see, then the software team can get to advanced features and voice commands, and the design team can get to making MC's design production-ready [Chart done in ProjectLibre] Do we have anybody who is already familiar with ROS? (Deleted and reposted because of chart typo. is there a way to edit my posts?)

>>16185 I know some of the info for 1 and 2 is listed in the gitlab, but I want a confirmation so there's no confusion later on..

>>16108 How are you going to deal with vibrations? Won't tensegrity wobble a lot?

>>16185 We will be starting with a dev platform that is very minimal then work our way up. This very minimal version will be used for my answers. 1. A 100 cm cute maid. One swerve drive in her tail with a steering servo and driving motor. She'll be posable by her Anon. She'll have basic conversational skills and offer basic companionship. 2. Some of the BOM is dependent on the software teams needs. Her most basic version would rely on an Android phone, an external battery, an Arduino controlling her servo and an h-bridge, her initial body will just be 3D printed with string for tension. 3. Working on it. 4 Hope to get there this year! I have very limited knowledge of ROS. Chobitsu and RobowaifuDev being the software team will decide on her software. (ProjectLibre seems neat, thanks for bringing it up.

>>16188 I'll do testing to ensure it's at an acceptable level. For reference, people are constantly wobbling, we just don't notice. Your concern is understandable but can be engineered around.

>>16185 >Do we have anybody who is already familiar with ROS? A little bit! >>16190 I'll be very interested to see if you can get this "suspension bridge" body to be rigid and dependable. It's a radical departure from traditional robot design to say the least.

>>16189 >Her most basic version would rely on an Android phone I'd avoid locking myself down to Android. Android programming sucks. Building around a Linux control computer will both be easier and more flexible in the long run. Fact: you can even run linux on top of Android via an app! (albeit slowly)

>>16191 Welcome to the team! Glad to have you, please fill out the form at your nearest convenience: >>15486 >>16192 To be honest, she was originally planned to use a modified laptop. Android phones are much lighter though and very easy to access. I use Termux for Linux on Android and I would not want my waifu to have that kind of latency kek. The Pinephone may be a good choice though its low power SOC may be problematic. I'd suggest modded OnePlus 6/POCO F1's but, there availability cannot be guaranteed. I'd appreciate your input on a low cost, low power, easily attainable Linux computer for running waifu software.

>>16192 >>16193 >Android phone Android programming is its own can of worms (unless you're building off of some easy to use framework). I think a web interface would be better because it's a cross-platform can of worms. >low cost, low power linux computer Raspberry pi? It supports ROS and already has GPIO integrated into the board so you may be able to skip the Arduino. >>16189 >servos and motors for mobility >conversational AI >posable by her anon So the top half is basically a doll, while the bottom half is like an RC car? I assume the "carry small loads" feature mentioned in the gitlab can be nixed for the December release?

If we gave MaidCom a bustle dress, we could put a cargo rack on the butt, lol.

>>16198 >Web interface Whereas I personally would want this, I have a gut feeling most would be against it. The schizo shitposters are a sizable portion of our intended market. :^) Pi's are low in stock and expensive currently, especially when you consider everything that needs to be added. Well, she'll carry things you place on her at first. Next December will have the goal of her carrying things she picked up. >>16199 Kek, that makes some sense.

>>16200 >Pi's are low in stock and expensive currently, especially when you consider everything that needs to be added. >$100-$200 for a bare board Damn, how long has it been like this? We might have to make a rack for a thinkpad or a Core 2 desktop and battery, lol >picrel >can't have a web interface because of schizo shitposters Then android phones are out of the equation, too. A web interface doesn't have to be connected to another wifi network, it could have its own AP with a web server. If people are schizo about wifi, then we could offer a wired-only version.

>>16199 >>16200 >>16202 Lol. Might I remind anons ITT of the butt-pods too? :^) >>15897 >>15900 >>15902

>>16203 Talking of which. Why couldn't MaidCom just keep a tiny bar/fridge/hibachi/etc., in her butt. She could roll up to Master, who says >"Pls make me a drink and a sammich, Waifu." >*waifu rotates at her waist 180' like an owl's head* >*simultaneously, she also rotates her whole body 180' to face her butt-pod towards Master* >*swishes her bustle aside w/ a coy blushu* >*pops open her fridge chest fridge* >*pulls a glass from her onboard dish-cabinet* >*pulls out a cool beverage, and fills glass* >*hands to Master w/ a modest curtsy* >"Here you go, Oniichan!" >*Anon has a long gulp* >"Thanks Waifu! Moar pls?" >*hands empty back to MaidCom* Seem legit?

>>16202 >We might have to make a rack for a thinkpad or a Core 2 desktop and battery, lol This is almost the best idea at this point (until something absurd causes the value of them to shoot up too much, you know it's coming). You could easily tuck away a laptop or "tiny form factor" PC inside a cute bag she wears, no awkward rack needed. This way you can use just about any computer you have on hand. No need to go out and buy something special.

>>16205 >No need to go out and buy something special. I really like this position in general I have a few old boxes around. I'm one of those schizo shitposters Kywy is on about, so I consider we need to take concerns in our security thread and elsewhere into consideration. > But it's certainly a helpful expedient for us ATM to make good forward progress and the manipulators trying to manipulate the markets can't keep it up forever -- the Chinese will eventually step in and there will be far more devices (and cheaper too!) than ever eventually.

>>16202 As a fellow ass man, I understand. Are you implying a wireless method of controlling her via a web app? That can be added. >>16205 Back to Linux on a laptop then. >>16204 This future is wild. I won't build Fridge Chan but, I'll help you kek. I definitely want to add the curtsy behaviour once she has the degrees of freedom to allow it. >>16206 I'm also a paranoid schizo, it's part of why deep down I want to go with a non-pozzed RISC V SBC but, they're just not powerful enough yet.

It seems that while the hardware team is cooking up ideas, the software team can make progress by settling up a TTS engine, Speech recognition, and a conversational AI, because those don't rely on a working robot prototype. Once we have the ingredients, it's just a matter of linking them all together and slapping it in whatever computer winds up powering MaidCom Speech2Text->Chatbot->Text2Speech

>>16207 >Are you implying a wireless method of controlling her via a web app? That can be added. What I mean by web interface isn't "You can remotely access your waifu from an internet connection" (schizo nightmare), I'm thinking something closer to: >Waifu makes a personal wifi access point >connect to AP >connect to web server running on waifu The Waifu is controlled via a web browser, but it's all done through her personal LAN and not the regular internet. >>16207 >>16206 >paranoid schizo Kidding aside, the only difference between paranoia and security is the value of the target. A waifu is no worse than a smartphone in terms of spying, but its ability to interact with the real world makes it potentially more dangerous than a smartphone. But if you're not a VIP (or your front door isn't left wide open), you should be safe with normal hardware.

>>16207 >Back to Linux on a laptop then. I think we probably need to consolidate onto one or (at most) two 'universal racks/storage volume' so Anon can have a standardized location to add his machine? >This future is wild. I won't build Fridge Chan but, I'll help you kek. But she's so much more than Fridge-chan, Anon! :^) >I definitely want to add the curtsy behaviour once she has the degrees of freedom to allow it. Many such small touches with mannerisms will go a long way towards personifying our robowaifus in the mind, including MaidCom. >I'm also a paranoid schizo, it's part of why deep down I want to go with a non-pozzed RISC V SBC but, they're just not powerful enough yet. I hope they get things ironed out with the platform tbh. It's probably our best shot currently at a non-Globohomo computing hardware solution. BTW, I probably haven't spelled things out with Foundations clearly enough yet. A big part of why I'm taking such pains with the networking of Bumpmaster, et al, is so we can take basic common-sense approaches to privacy, safety, and security to protect both our robowaifus and ourselves from the large (and growing) number of bad guys who wish us all harm. We don't have to be some kind of cyber-ninjas to put most of the effective measures in place, either. Just some simple paradigms like only passing vetted, sneaker-netted, information into our waifus -- and never allowing them (or any part of them) connect directly to the Internet. It's a big but important challenge, and one I refuse to just ignore. There's far too much at stake for (potentially) millions of men & their waifus in the future. >>16208 I don't want to speak out of turn, but RobowaifuDev has already made some tremendous advances in these areas. I think he's the man. I'll try to help him however possible to integrate his work into MaidCom & all the other robowaifus.

>>16209 >The Waifu is controlled via a web browser, but it's all done through her personal LAN and not the regular internet. RobowaifuDev is commending WebSocket servers to me (>>16194). I may or may not attempt it for my project, but you can be sure I will take his recommendation very seriously as I admonished every anon on our board to (ITT). >Kidding aside, the only difference between paranoia and security is the value of the target. A waifu is no worse than a smartphone in terms of spying, I would suggest we are going to have 10x the amount of sensors and compute power in our future waifus than any smartphone ever dreamed of having. >but its ability to interact with the real world makes it potentially more dangerous than a smartphone. Very definitely. We had a fairly extensive discourse that touched on this exact issue in our TITS council. >But if you're not a VIP (or your front door isn't left wide open), you should be safe with normal hardware. Dragnet surveillance is a thing, and quite frankly, the simple fact that every robowaifuist pretty much wants to overturn the Feminism, et al, pozzfest boat paints a target on all our backs. "Better safe than sorry" is a long-standing aphorism for good reason. :^)

>>16210 >I think we probably need to consolidate onto one or (at most) two 'universal racks/storage volume' so Anon can have a standardized location to add his machine? BTW, would there be any real showstopper with just having a real hard/firm shell backpack for this? She can keep more modest computing going internally when her pack is off, but in the nominal activity case she'd wear it pretty much consistently. I realize this is a compromise, but it's just that: a compromise. I say let's spitball ideas and hack something together that just werks by December. Then we can tweak, redesign, etc., etc., afterwards. What think ye Anons?

>>16210 >I think we probably need to consolidate onto one or (at most) two 'universal racks/storage volume' so Anon can have a standardized location to add his machine? What about an ATX motherboard mount in the bustle? Pretty much anything from a repurposed office desktop to a compute stick could be used (not counting the PSU and battery for desktop hardware). If that's too big/complicated, we could have a universal cavity in the bottom half for a compute stick, mini PC or laptop. >>16212 >hack something together that just werks by December. We could have MC tethered to a desktop if the onboard computer question takes too much time. A mini PC could easily fit in the backpack, maybe a small laptop (depending on her proportions), but full size desktop hardware is a no go.

>>16209 I actually planned on using MaidCom as a portable server before the Android idea. So, yes your suggestion is definitely going to be added. I've wanted a a cute monster girl maid that is also my media/file server. There's a lot to do before this. >Schizo It's just slang for people that care about privacy and security on imageboards. >>16210 >Standards We do need those. I'll do some research into general laptop sizes to develop mounts. Though I was thinking that we should limit us to 14 inches or less as bigger laptops are much heavier. >Foundations I appreciate your mindful development, it is a boon to MaidCom. >>16212 >Rondoseru server Nice idea, would require counter balancing or, be supported by her tail.

>>16213 >What about an ATX motherboard mount in the bustle? I like the concept, but are we decided yet if there will even be a bustle yet? Ultimately it's Kywy's call as the Team Lead, but we still haven't heard from everyone. I certainly favor some kind of storage volume in the rear-end. Her tail can serve as a kind of support arch for it's mass. >We could have MC tethered to a desktop if the onboard computer question takes too much time. Good thinking. Most android prototyping going on today actually adopts this as a SOP. We're trying to go above and beyond that ofc. BTW, even her rondoseru can be tethered-in from it's storage cradle when she's not wearing it. >>16214 >Though I was thinking that we should limit us to 14 inches or less as bigger laptops are much heavier. Agreed. Enabling mini- or ATX boards would be a big help too. This is what I have on hand tbh. >I appreciate your mindful development, it is a boon to MaidCom. Thanks! I mean to help every.single.project. here with it too. For instance Pandora's. These are basically universal issues we're trying to address in the RW Foundations. >Nice idea, would require counter balancing or, be supported by her tail. Yep. Might I suggest using a fannypack as well around the front girdle filled with batteries as a counter? It would certainly lend some geometrical lever advantage from there across the central mass point. Also, you'll to design pretty beefy Meshtegrity supporting tensionlines to deal with the extra mass up in the floating chest complex.

>>16216 >>16214 >tail for support Picrel comes to mind. One of the pics posted earlier (>>15822) shows a foxgirl tail but a cat or fox tail that touches the ground enough to provide support would look disproportionate IMO. With a lizard, a tail touching the ground is natural. >We haven't confirmed the bustle I should have said "lower half" The designs I have seen so far (>>16163) feature legs fused together so it is already kind of a dress/bustle thing, just at different implied dimensions.

>>16219 >With a lizard, a tail touching the ground is natural. Absolutely not for me haha! :^) While you certainly have a good point about the lever configuration being at an advantage with the convex (ground-relative) curve of a lizard's tail, I would suggest that a 'drooping' concave animu catgrill tail that touched it's tip-wheel to the ground would be just as effective, would be more aesthetically-pleasing, would afford better 'day-to-day' ground clearance for obstacles, etc., and would also resulting more agile kinematics.

>>16219 Isn't that the Lizard House at the San Diego Zoo?

>>16163 Here's my designs thus far, hope they can help your designs. Her skeleton will be composed of meshes that are tied to nexus blocks. These nexus blocks would have block connectors and 5/6 connectors (see picrel). These block connectors will be used for connecting body panels and limbs physically. The 5/6 connectors will be used to connect limbs electrically to her primary/master microcrontroller. I'm also considering servo horns with captive string to manipulate her sekeleton.

>>16216 I think an ESP32 makes sense for her primary microcontroller. This way she could have her software hosted on a Bluetooth/Wi-Fi/USB connecter server. Which could take the form of a rondoseru styled computer case or Thinlpad in her front apron (to name a few of many potential options for keeping her control server with her. >ATX Too big/heavy/power consuming. I was drawing up plans for a mini ITX case which could be 3D printed rather easily. But, I will also design a micro ATX case though due to it's size will require significantly more complexity in printing as most commonly used printers max out at around 200mm3 or 8in3. All desktops will use much more power compared to a laptop of equivalent performance within the same generation so, please bare in mind that these designs will be for high speed, low battery life. Planes and other regulations means she'll need her battery to be less then 100 watt hours but, I plan to make them hotswappable with internal capacitors so you could swap out batteries as needed. I'm also planning it out to look a lot like the rondoseru in my previous pic. I'm a big fan of a latching cover for easy access to her servers internals. >>16219 >>16220 Bustles are possible though I'm probably not going to design them. As a reminder, this project is completely open and designed to be modular so if someone wants bustles, they're encouraged to make one that's compatible with our system. (Once we figure out how our system will work.) >Tails There are many ways to dress up and pose her tail. A shark tail may be the best because of its width and girth. Either way, a cat/fox style tail like picrel 1 is what I'm going to design first.

>>16222 Nice digits to complement a cool design Kywy! This is going to be fascinating to watch how the design evolves as a meshtegrity system. IMO, it's also good thinking to use standardized connectors like that. >>16223 >I think an ESP32 makes sense for her primary microcontroller. Sure I think that would be fine. I'm not at all opposed to a home-based network for your waifu, I just suggest you don't let any part of it connect directly to the Internet. >mini ITX/micro ATX case Yep, good thinking. I think what I have is ATX & mini. If you actually mean to have a rondoseru for her, then I can probably tweak mine to work. I really like the idea that accessories like that (and other parts) can be easily modded by Anon for his waifu. >battery rating limits Hmm, hadn't even thought of that yet. Good to know. As long as we stick with standard voltages, then anons should be able to use a fair variety of ways to power her. >I'm a big fan of a latching cover for easy access to her servers internals. This. For sure a good idea Anon. >There are many ways to dress up and pose her tail. Yeah I was thinking that myself after anon's lizard tail post above. Again, lots of nice modding potentials there. Please keep up the good work Kywy! Looking forward to your designs.

>>16226 Finally got some somewhat successful prints after aggressively sanding my print bed. (Anyone know of a good brand of PETG? NOVAmaker and Duramic have similar failures/smell to ABS.) Glad to report everything from plastic thicknesses affecting material properties, my clipping machanism (I just have the clip on the otherside as it's way easier to print with trash PETG.), and tying things together works almost exactly as intended. Will add stabilizers to the mating surfaces of the mesh and nexus blocks as they wiggle too much. Also reducing the number of holes to two as you honestly only need one knot. Pictures were taken on an open notebook for a sense of scale. Looking forward to more tests soon.

>>16227 Neat! Nice work Anon. Once everything's assembled and the skin is in place maybe some of the cosplay LARPfoam + thin prosthetic-grade silicone cured/powdered overcoat? this kind of structural form will be very /comfy/. Good for huggles! :DD

Crosspost from foundations: >>16230 Threw together a few libraries into a one-pager talking chatbot. Needs work, but it's a proof of concept.

>>16231 >Threw together a few libraries into a one-pager talking chatbot. Needs work, but it's a proof of concept. Thanks! I'll have a look at it over the weekend sometime Ricardo. Lol sorry but I'll have to spoiler your graph. :^)

After careful examination of MaSiRo (https://www.masiro.cafe/tipping), I've realized that they essentially made a robot very similar to what MaidCom will be. I labeled much of her internals to give other Anons guidance on how she functions on an electronics level. Our MaidCom will be much cheaper and lighter mechanically but, nearly identical electrically.

>>16222 Checking in while I'm out of town and have a minute. I like these ideas, thanks!

>>16212 My crude prototype specifically allows for this with a rear hard point to attach a backpack type shape - which could accommodate extra battery, storage, tools, etc) A "back" module is never a bad idea, I would like to keep this feature in the plans.

>>16247 Sauce on pic? Can't seem to locate via the link. I assume those are two linear-screw actuator struts in the central volume? Also, no wonder they need such a massive locomotor system, this thing is built like a piece of light-duty industrial gear. I have high, high hopes that our meshtegrity based approach will afford us much-lighter, much-cheaper robowaifu systems, as you suggest. OTOH, I notice that they have vaguely adopted a loosely-hexagonal floor layout of the 2 driven-wheels and the 4 follower swivel-wheels. Good thinking. Much like the Fuchikoma/Tachikoma legs, this geometrical arrangement brings as many benefits to locomotion stability as it does to meshtegrity frames & shells. I hope we can a) greatly simplify the electronics needed (possibly moving some of that complexity over into the software side of the house), and b) clean up that dang wiring mess! :^) Srsly tho, good cable management is actually far more important for our robowaifu engineering than it is for say, a big data center. Data center wiring messes are simply a nuisance for the networking techs. Bad wiring in our robowaifus could spell disaster. Nice pic & labeling Kywy, pls provide many more like this.

>>16252 >A "back" module is never a bad idea, I would like to keep this feature in the plans. Agreed. However it's not without cost (as is the case in any engineering there are trade-offs always to be considered). Specifically, in this case, we have to engineer unproved tensions for the so-called 'floating chest' of the meshtegrity system in MaidCom (>>16108, >>16222). Additionally, any extra mass up on the back also has effects on the general kinematics of the systems. To wit: you're placing that mass further-out on the 'lever-arm' of the geometry, from the central-mass point (virtually in the pelvis volume). Any such emplacement of mass (not just this specific case) increases the thrown-weight problem that all actuators have to deal with. This necessarily increases all cost calculations involved. >tl;dr It's (almost) always a good idea to keep mass as nearly on the central-mass point as possible (from a mechanical/structural engineering-economics purview). >=== -add the single word 'almost' -add 'mechanical/structural' cmnt

>>16132 >>16165 Truly a man of many talents! :^) I've been concerned repeatedly about pinching in the various externally-exposed mechanical joints. Your old-school 'bellows' design seems a good fit for our low-cost approaches we're attempting here. I wonder if these can be obtained in some fashion already pre-manufactured and cut to our needs? Automotive aftermarket suppliers perhaps? I suppose we'll contrive our own molds, etc., for this kind of thing in our own factory efforts one day tbh. But for now, at this point in time, front-loading as much as possible of that is practically always going to be a big benefit to us here.

>>16264 >Squaring this backpack expansion with her lightweight frame goals is no simple task. Agreed. >I'd appreciate any and all suggestions. Well, I think I'd suggest you don't attempt to make it part of the chest (front or back) at all. Instead I'd suggest a couple of L-shaped frame rails extending back from her hips. They would extend slightly posterior (say, <= 5cm) on the 'base' of the L, and then turn basically 90' upwards for say 10-15cm. Secure a narrow-profile rondoseru (sans straps) in place to them (or even something in form like one of those little 'bundles' I don't know what they're called lol that are at the rear of the waist sash in traditional kimono garb). Then you can balance that static lever-force moment out with an appropriate counter-mass of batteries near her belly's frontal volume. This arrangement should keep the masses reasonably closer to ground level, near her central-mass point, stay mostly out of the way for her day-to-day activities, and (importantly) not impact the dynamic loads of her chest complex. >tl;dr Just attach massive things to her hips, not her chest. These items can also be removed as needed -- by design (including their support-frames, which should probably just slide down into keyed attach-points in her shell). >rocker bogie, et al <plus a tail, too! I like it! Good thinking Anon. Hey, if it's good enough for the Mars Rovers, then it's good enough for MaidCom too, right? :^) >Bellows can be 3D printed though, I'm just going to use stretchy fabric and good engineering to prevent pinching. Sounds good. Certainly anything we can do to reduce costs while still maintaining sound design & engineering aesthetics/integrity is very likely to also be a good choice in general Kywy. Onward! :^) >=== -minor clarification re. hips frame loc'n -minor sp, grmr, fmt edit -add 'ground level' cmnt -add 'support-frames' cmnt -add 'chest complex dynamics' cmnt

>>16258 >Sauce on pic? https://www.masiro.cafe/masiro

>>16267 Great, thanks Anon! I certainly wish them great success both with their Meido Cafe endeavor, and also with their robowaifu designs. Maybe they'll visit /robowaifu/ one day. :^)

>>16260 It's flexible pipe. You can buy it at Home Depot. It's often used for drainage pipes, drain hoses on RVs and protecting electrical connections.

>>16270 Great thanks Anon! After I made that post the thought 'Well maybe something like dryer hose?' came to my mind, but I decided immediately it was too fragile durability-wise and dismissed it. But if there's something like that readily and inexpensively available (I think I've seen it on an RV-type vehicle now you mention it), then that's a very handy thing if needed. However, I think Kywy is already planning for this (important) issue, so the pipe probably won't be needed. Still, good to know. :^) Thanks again Anon.

>>16265 Hm, good ideas on how to achieve balance. The Rocker bogie was just an example, it's patented so we can not use it aside from designs people make at home. (We will be making a version with notation that it is strictly DIY.) >>16267 Thanks >>16270 Huh, didn't even consider that but it is a good material to use. Any updates on designs? Do we need another extension?

>>16165 Hi, I'm currently not part of the specific MaidCom project. But, since everything seems to now being discussed here I wanted to mention that I wanted to include regular Linux programs in the robowaifu AI. If something has been solved already, then there's no reason to reimplement it. There's a program called Taskwarrior for the console. Changes require commands in the console, which could also be coming from another program and of course being logged into a logfile or database.

>>16274 >good ideas on how to achieve balance. I don't need to tell you of all people that we really have to take a systems approach to the study of mechanical dynamics of robotics -- particularly something with such complex kinematics as a mobile, humanoid form such as MaidCom (and even much more complex systems to come). But using simple tricks like counter-weights can go a long way for us to simplify the general problem. >The Rocker bogie was just an example, it's patented so we can not use it aside from designs people make at home. (We will be making a version with notation that it is strictly DIY.) Ah, I see. Good to know, and even better still there's someone leading the project who looks into this kind of thing! :^) >Any updates on designs? Do we need another extension? I realize that I'm not directly part of that division, but I admit I'm somewhat confused Kywy. Haven't we already gotten a couple of nice ideas from Meta Ronin (>>16163) & RobowaifuDev (>>16132)? You yourself have generated a ton of good ideas obvs. And even a number of the rest of us have contributed in our way. So, I'm unclear what's needed further? Admittedly I'm quite ignorant of many design requirements needing to be addressed, and so I'm probably missing things that are obvious to you and others. Can you please spell out in more detail for us what's required? It might help out everyone to be on the same page.

>>16275 Hi Anon, welcome! >Hi, I'm currently not part of the specific MaidCom project Well, please join up! (>>15486) Hey, you can't expect us to carry all the load, right!? :^) >I wanted to mention that I wanted to include regular Linux programs in the robowaifu AI. >If something has been solved already, then there's no reason to reimplement it. These are certainly fair points. Indeed, prior-art forms the basis of the vast ocean of advances men achieve in practically every domain. The extraordinarily eminent scientist Isaac Newton made this very clear in his 'boy on the seashore' quote. Many would claim he was literally the single most intelligent man in history, yet he made it plain all his works were dependent on other luminaries preceding himself. So yeah. OTOH, we have an unusually complex and sensitive set of systems and requirements we're all working towards together here. Privacy, safety, & security not being the least of these concerns. We've talked about these topics in general the board-over, but we have one of particular import to your suggestion, Security (>>10000). Unrestricted access by the uncounted number of possible applications running on a Linux (or any other OS for that matter) system is plainly a big no-no. To put it another way; would you really want Syst*md to be any part of a operational system that controlled the fluttering of the wingtips on a commercial airliner? If you were flying on it? Your grandma? I would suggest that what we are tackling here is at least as complex and delicate in the end, in some ways moreso. Throwing applications helter-skelter at our robowaifus, with no vetting whatsoever, is a sure recipe for disaster -- both for Anon and for his robowaifus.

>>16275 I plan to make a conversational user interface where people can define their own commands, tasks and events. So if you want to use a tasklist manager through your robowaifu you can do so after a dev sets it up with the CUI API. >>16277 Robowaifu security will follow the principle of least privilege. A tasklist manager has no need to access her memories, camera, microphone, servos or decision making process and can be restricted from accessing those, including having memory and bandwidth limits, network and file restrictions and lower process priority. Simply blocking all applications will make it difficult to do anything useful with robowaifus and block other devs from contributing. Updates to critical applications though will require vetting so we don't have a node-ipc malware incident or something similar. Applications could also run in a virtual machine or separate device entirely to prevent zero-days in the operating system from being used.

>>16290 >Applications could also run in a virtual machine or separate device entirely Yep. In fact I sort of indicated this direction in my Robowaifu OS/Brain-cluster thread from back in the day (>>201). Massed-unikernels running on hypervisors offer us an unusually-simplified potential solution to both the security and stability problems. Thanks RobowaifuDev, that input is very appreciated.

>>16276 Meta Ronin's contribution was more of an outline describing his prototype of a design. I shared some of my design ideas to help them crystalize their ideas. Now we await their actual designs. RobowaifuDev's contribution is noted and great but, I want to ensure everyone who wishes to contribute their voice is heard before anything is finalized. Also, you requested a deadline extension on your own design submission >>16159 though, I'm confused by this since you're on software. >>16277 >Syst*md Not in my waifu! :^) Think we should use Antix Linux as our base distro with ROS on top? >>16290 >>16292 Good to see the software team working together. Authentication and isolation principles will indeed be important.

>>16293 >Also, you requested a deadline extension on your own design submission >>16159 though, I'm confused by this since you're on software. Heh, my apologies. That was in relation to your request for a sketch related to my "OP'd crystallization" post. We immediately launched into a long back-and-forth thereafter that resulted in your well-coined "Meshtegrity" concepts we are now pursuing the design of. I considered that 'extension' immediately resolved by that discussion? >Not in my waifu! :^) Poor Lennart Poettering! He'll never have a robowaifu now. How will glowniggers ever cope!?111 >Antix Linux <"Proudly anti-fascist "antiX Magic" in an environment suitable for old and new computers." Heh, I think not fren. Filthy-Commies and Leftists are no friends of us or our goals here tbh. It's not even about their politics, etc., per se, but simply put: they hate free men being free from those selfsame politics & ideologies (>>15728). >tl;dr These types and their cronies/simpathizers are our greatest human threats. I mean to all men everywhere, not just anons on /robowaifu/. That I would willingly use a product of which they boast about this? Heh... :^) How about the incredibly lightweight plug-in-exactly-what-you-need-and-nothing-else Alpine Linux? https://www.alpinelinux.org/ Actually, I'm basically opposed to using Linux in general. If we have to use a full-blown OS at all, then I'd much, much prefer OpenBSD. https://www.openbsd.org/ But hopefully, we won't need to use anything more than a 'barely above the raw metal' approach similar to what I just touched on with RobowaifuDev. OTOH, I realize this is a progressive effort spanning years of time. Pragmatics will require interim compromises until we obtain the funding needed to devise robowaifu-hardened systems of our own. >Good to see the software team working together. Authentication and isolation principles will indeed be important. Indeed it is good! I think RobowaifuDev's CUI (command user interface) is a brilliant conception tbh. I hope we manage many more back-and-forths between us ITT. >=== -minor sp, grmr edit -add 'years of time' & 'hardened systems' cmnts

>>16277 >>>Hi, I'm currently not part of the specific MaidCom project >>Well, please join up! (>>15486) Hey, you can't expect us to carry all the load, right!? :^) Sorry, I'm working on my own project, but I want to keep it compatible where possible and also to go on sharing ideas. That's why I was writing that.

>>16300 Ahh, I see. Well I wanted to extend the offer to you. :^) I assume your project is robowaifu? If so, good luck with your project Anon. We all hope you'll share your progress with us here on the board somewhere. Cheers.

>>16294 What do the other members think of the Alpine idea? >>16300 As an open source project, your project being compatible with shared ideas is very much welcomed. The more compatible projects there are, the more entrenched our waifu standards become. On that note, if you have any questions, want any advice, or want to know any dimensions to ensure compatibility, feel free to ask.

Some interesting ideas that could help us. https://hackaday.com/2022/05/18/3d-printed-linear-actuator-is-cheap-and-strong/ https://hackaday.com/2022/05/18/natural-language-ai-in-your-next-project-its-easier-than-you-think/ >=== -minor fmt edit

>>16308 Thanks for the NLP HaD link Anon.

>>16306 >What do the other members think of the Alpine idea? Never used it before but it looks pretty good.

>>16313 I thank it is wise to use the lightest, most specialized operating system possible. I might even suggest making our own custom distro. >PS testing trip

>>16315 Alright, tripcodes look stupid on this board. Lesson learned.

>>16316 Hello SoaringMoon, Welcome! Are you just visiting or do you plan to work on a robowaifu? We have an Embassy thread (>>2823) if you'd like to introduce yourself. >Alright, tripcodes look stupid on this board. Lol. While I agree that tripcodes aren't so great here, that's entirely due to the programmer of LynxChan and has nothing to do with /robowaifu/ per se. Anyway, make yourself at home Anon.

>Structure material First off, my go to material for the structure would be pvc pipes. They are readily available and rather cheap. They could be interconnected with 3D printed joints. >Tachikoma legs Wheels are good for the inital phase 1 prototype as a way to get around, maybe wheels on 3 or 4 legs. >Simplify the electronics Raspberry Pi and Arduino are rather cheap and readily available, easy to set up but can still accomplish a lot. Raspberry Pi is compatible with ROS; http://wiki.ros.org/ROSberryPi Its preferable as it takes a lot less space than a laptop The cables could potentially be run through the pvc pipes >3D printing The hands, face and structure joints should preferably be 3d printed or injection molded These are my initial ideas, I kind of skimmed the thread so I might not be fully up to speed on the current status but I get the gist of it. I'm okay with coding but leave that to others with more experience for this project

>>16356 >PVC pipes I fully welcome and will help with the parallel development of a version based on PVC pipes. The main branch will remain 3D printed. >Raspberry Pi If you know of a place to get them near MSRP, please do share as I've only seen the sky high scalped prices recently. For now, cheap used laptops running ROS on Alpine Linux is the cheaper and more accessible option. I would have liked to make her based on a small cheap SBC if it was sensible. >Injection molding I fully intend to make molds for much of MaidCom's parts to be able to sell kits and enable others to do so as well with permission from the group. Thanks for your input Hik, glad to have you on the team

>>16360 My concern is that it may take a long time to print every structural part for a 1 meter version (if that's what we're going for) but if that works then its fine. I'm not sure about the meshes In my area, even the latest model of Raspberry Pi (4b) is 5 times cheaper than the very cheapest laptop. I don't know about used ones. My old laptop is incredibly slow to start. The Raspberry Pi has pins (GPIO), so it should be easy to connect up to control stuff. I'm currently starting a project to test that out. Were you Kiwi before? Your pic and the fact you have a name resembling that reminds me of someone from New Zealand I've sometimes chatted with

>>16361 Meshtegrity allows for high speed printing of very large structures with minimal assembly. I'm still developing the technique. Expect more examples within a week as I've recently made some breakthroughs worth sharing but design takes time. I'm in the process of designing a meter tall doll that should be easily printable as a demonstration. >Are you Kiwi? Indeed I am old friend, I changed my name to distance myself from existing entities. Y is because I'm a major fan of Clockwork Planet and in that series, Y is a man that created robot woman that changed the world.

>>16362 > I changed my name to distance myself from existing entities No, It's because he is an edgelord who will take advantage of generous anons and flake as soon as you put your foot down and expect him to do what he said he'd do. Like he did with both Madoka.mi and Pandora. >>15331

>>16442 I share your weariness with Canonical. From what I understand, ROS is bloated and inefficient but, in a way that's supposed to make it easy for the lay-man to use. I'm not the biggest fan personally but, the other members seemed interested. I had no idea it was so bad. Do you think it would be worth going for a different framework then? An open invite for anyone to offer alternatives. Thus far the software is going to be Alpine Linux, we still need a framework for our software that's fast, light, extensible, and ideally FOSS. ROS was the choice but, is now in contention due to its flaws which could be detrimental to the project. >=== -patch crosslink to relocated post

>>16388 I mean, I'm actually also wary of Canonical because of stuff like ads in the MOTD https://news.softpedia.com/news/canonical-under-fire-for-putting-ads-in-the-ubuntu-motd-530372.shtml, but I mean I'm wary of ROS' way of doing things, their way of writing C is misguided, their way of writing portable programs is just going to lead to more unnecessary and lower quality work too (#ifdefs for every platform), and it only took me skimming 2 files to find a buffer overread in code that shouldn't exist (turns out that extra byte can be beyond the end of the buffer in some cases, I already sent a PR). I don't believe they have the minimal competence necessary to write a working system. Alpine is probably the best choice as far as distros go, but we don't have to be married to a distro or even Linux. It's not too hard to make a program portable and even if the program is ported to a system nobody uses, that will help with finding a bug sooner or later. OpenWRT can produce even smaller installs than Alpine due to supporting root on squashfs (a compressed, read-only filesystem) and being more customizable (i.e. it's easier to cut out unnecessary parts) which helps with cost cutting and anything with less parts is more reliable. The whole setup should be portable to both either way because you can't use OpenWRT as a dev machine. I think Linux is the best free Unix system for real time stuff, I've used quite a few and ported programs to all of them. NetBSD is worth a try too. For now, it would be best to revisit all the robotics frameworks and use the best one. Bit by bit, if any component turns out to suck, it can be replaced. This is more work but actually a good thing, as it's hard to gauge what the programming interfaces should look like until after you use them, so we can mooch off from the fact that tools for doing what we need to do already exist, and then we can use the experiences acquired through hindsight to replace them after seeing what they do well and what they do badly. What I think is the best design is to simply write portable programs. Let the operating system be your framework for providing an unified interface to all sorts of hardware. Don't use a custom allocator, if it turns out the system's allocator is bad for real time, then replace the system's allocator, that way it affects not just the robotics-related programs but also the entire rest of the system, all without writing any extra code to add an allocator parameter to functions. For portability between operating systems, create a library that abstracts the operating systems. This design works rather well, we already have this for instance with audio: operating systems each implement their own drivers for audio devices and their own unified APIs for operating on all those devices, and people came along and wrote a libraries like OpenAL for doing audio on many operating systems. Ideally, there would be a library for moving arms, another for speech, another for sensors, and so on. This facilitates development, as it's easier to complete smaller pieces, changes to one component do not affect others, and pieces can be developed independently.

>>16391 Thanks for your input. I believe Chobitsu has mentioned portable libraries before. Would like to hear more from the other members who specialize in software, this could go somewhere promising.

>>16366 Lol, chillax bro. Your own crosslink shows conclusively that Kiwi did in fact apologize to you. Along with him, I hope you'll accept that. We all have room to grow here, right Anon? :^)

>>16077 >>16163 Great stuff Meta Ronin. Hope your trip is going well. Godspeed Anon, look forward to hearing from you again soon.

>>16360 Gumi a cute! I still think papercraft may have some place for the poorfag Anons out there Kywy. If we can do something along the lines of Indian Foamcore Anon (>>10315) using paper + an RPi + a few MC + a few cheap servos I think that would greatly, greatly expand the potential reach of moebot/fairybot Headpat Waifus :^)

>>16395 >a few MC <just realized the acronym conflict ITT Lol, MC==microcontroller :P

Kywy, Anon just posted a video clip that could have a potential for our meshtegrity approach for robowaifus: > (>>16415 >Tendon-driven leg -related)

>>16374 ROS has a lot of "documentation" but it actually says very little. I only found the source code because I looked at the Ubuntu compilation instructions which suggested adding a source repository to Ubuntu and the repository was hosted on Github. I'm wary of that organization. I jumped on the source code of one of their C projects and I see a load of useless wrappers around stdlib functions https://github.com/ros2/rcutils/blob/master/src/strcasecmp.c https://github.com/ros2/rcutils/blob/master/src/strdup.c Every line of code has a cost, adding lines of code to add argument checking to the callee isn't worth it. Programmers will have to lose time learning those wrappers, using them will tie programs to ROS, and they don't actually provide any benefit: you still have an error you have to check if you pass null pointers to those stdlib wrappers. The other thing that code does is let the caller specify the memory allocator. I doubt they found an use for a custom memory allocator in their stdlib wrappers. Most likely they're just losing memory and performance by adding more parameters and layers of pointers to dereference to functions. If you check at the callee, you still have to check at the caller, because then you have to check if the callee returned error. Worse, the errors are only going to pile up, and you'll have to come up with increasingly complex mechanisms to signal what kind of error happened. As errors from one part of the program are propagated to increasingly distant places, it will become impossible to handle them. If there is no way to signal what kind of error happened as is the case here, error checking paradoxically becomes impossible because someone added error checking to a function. If you check at the caller, the callee doesn't have to check anything, and every function it passes the argument to doesn't have to do any checking either. The errors aren't allowed to snowball, keeping error checking to a minimum, and errors are only checked where they might be acquired, keeping them close to their source. All of this without letting any error go unchecked. This is also way less lines of code, so it results in less code to maintain, smaller binaries, and less chances of bugs cropping up because you can't have bugs if you don't have code. Errors should be checked where they might be acquired. Also, type names ending with _t are reserved by POSIX: creating one such type is UB, though it's unlikely to cause trouble. And this memcpy call https://github.com/ros2/rcutils/blob/master/src/strdup.c#L52 copies 1 extra byte unnecessarily. I would send patches to remove all that stuff to them but I doubt they'd accept the patches. Someone decided that poor design was the design for him. === >note: This is relocated ITT, and technically belongs above this post (>>16388)

>>16231 How are you doing, Ricardo? You still with us bro? Just checking up on you, seems like it's been a couple weeks since the team has heard from you. Cheers.

>>16394 Thank you and not so much. My connection got cancelled due to freak snow and I was stranded in Denver for 4 days. Made the most of it but only the other night just arrived back home and still have the remainder of a full workweek. What can I say when it rains it pours (snows?)

>>16484 4 days? Wow, that sucks. Anyway, glad you're back safe and sound Meta Ronin.

>>16391 >OpenWRT can produce even smaller installs Interesting. I briefly considered OpenWRT, glad to know someone else on the team is aware of their innovations. >and anything with less parts is more reliable. Generally-speaking this is always a good rule of thumb IMO. Certainly it's a baseline to start out from. As I'm sure you're well-aware, and for the benefit of the rest of the team here's an old software engineer proverb: >Q: "What is the best software in the world?" <A: "The software that isn't there!" >For now, it would be best to revisit all the robotics frameworks and use the best one. Bit by bit, if any component turns out to suck, it can be replaced. This is more work but actually a good thing, as it's hard to gauge what the programming interfaces should look like until after you use them, so we can mooch off from the fact that tools for doing what we need to do already exist, and then we can use the experiences acquired through hindsight to replace them after seeing what they do well and what they do badly. A lot of wisdom wrapped up in that little paragraph, Nagisa >What I think is the best design is to simply write portable programs. Let the operating system be your framework for providing an unified interface to all sorts of hardware. Agreed, in general. Certainly it's a typical approach for engineers. If we can achieve our goals basically identically on PlatformA & PlatformB, then the leaner/lighter of the two will usually be the better choice. >For portability between operating systems, create a library that abstracts the operating systems. We're intending something like this in the HAL libraries of RW Electro/RW Gears. I hope you yourself will contribute to both, Anon! :^) >>16442 Thanks for the advice about the error detection/correction. TBH, I'm not too skilled with it yet myself but I focus on it pretty regularly these days. Any further advice in this regard would be quite welcome thanks.

>>16392 Well it's Sunday Kywy, thought I'd check in with you mate. We managed a little improvement with the RW Foundations drop last week, and will probably do a little cleanups/refactors with it next Caturday or so. Have a lot on my plate ATM, so not much else to share. Hope you're doing well Class PresidentTeam Leader. :^)

>>16395 Fully laminated paper would definitely be a good material for waifus. I fully welcome anyone who wishes to adapt our designs. We have the plastic versions at .7m 1m 1.5m and 1.9m scale. >>16439 Great reference, I enjoy the accurate muscular skeletal system. >>16484 Was just in a similar situation. Had a family situation come up that involved going to the middle of nowhere without access to internet or a computer. Glad we're both back >>16508 I've only had a few hours to get back to testing meshtegrity. My mind was a tad fried so results are pretty bad but were somewhat helpful. Much better results are on the horizon. Hopeully we'll have a new test platform by end of June/July for you, Nagisa, RobowaifuDev and the rest of the software team to test software on. For reference, the long one is a 20cm/7.87inch lower leg test that though a failure, was almost a success. A 148cm waifu would have a 39cm lower leg. I'll have one of thos ready by end of next week. Wished to print out my doll idea but, simply had no time as I had to drive to the middle of nowhere as previously mentioned.

>>16525 >but were somewhat helpful OUTSTANDING! Your hex/tri mesh looks wonderful Kywy. I would say you definitely have the idea firmly in mind now. Might I suggest that along all the triangle 'edges' you spend a little extra printing building up a slightly-'rounded spar' form? The 'mound' cross-section should be oriented to the exterior of the shell, once everything's rolled/formed around. I think you'll find this will better-rigidize the mesh with more strength against strain overall. The mesh should endure loads a bit better, and I expect it will be well-worth the extra costs involved with this slight modification to your current design. It will be interesting to see how you plan to manage the joins as the mesh sheets form around & back together again. Hexagons are really quite remarkable geometrically, and I expect that you could reasonably capitalize on their natural interlocking characteristics at (almost) all of the join edges. While I see that you are using quite uniform hex layouts in your mesh, I don't see this as a fundamental requirement per se. You can customize the triangles; adapting them for better aesthetics, greater strengthening at limb's component-connectors, and for better mesh sheet joins--all as needed. Once everything's formed-around, stitched, & tensioned up, then perhaps as well some kind of shear-resistant, very thin plastic film (such as vinyl sheets) could be tightly adhered down onto & around the outer surface of the meshtegrity shell to provide additional, surface-lateral strength to help further resist deformations? I plan to test out this 'high-tensile, tangential surface film' effect with Kapton tape in lieu of the vinyl--it's a) amazing stuff, and b) already nicely adherent on mine as well. I think we're going to find the combination of all these approaches will yield a lightweight, yet remarkably-strong exoskeletal shell material for MaidCom. Relatively inexpensive too! That the shell-system overall will also have literally hundreds of natural, well-distributed interior mount points for suspension & actuation cording, reinforcement-framing, &tc., is just icing on the cake. Cheers, Anon. Glad to have you back! :^) >=== -minor sp, gmmr, fmt, prose edit -add 'actuation cording' cmnt -add 'Kapton tape' cmnt -add 'uniform hex layouts' cmnt

So, checking in with you early this time. We finished up the migration over to pure libcurl for this Caturday's drop of RW Foundations code (>>16543). As explained in that thread, any new work will be on hold for at least a month. I'll be monitoring progress ITT though. Cheers.

>>16528 Frankly, I'm hitting some bad roadblocks with meshtegrity. My 3D printer continues to give me all kinds of problems with bed adjacent layers. Complex compound curves also are extremely finicky and dificult to work with. It also has has buckling issues that requires significant reinforcement or the mesh to be supported by a solid under layer. So, for now I'm switching over to designs optimized for vase mode (spiralized out contour). Printing PLA at 225 at 50mm2 with 1mm line width using a .6mm nozzle produces a surprisingly durable part with low mass. This test half chest is scaled for a 150cm waifu, has a mass of 36 grams and survived me laying on it so, I'm confident a full waifu would support an Anon ontop of her while having a mass (sans electronics) that's sub 1kg. Normal tensegrity will be used to keep her durable and light instead. Meshtegrity isn't abandoned, it will still be used for cylinders. Meshtegral cylinders are the one shape that truly works with thin PLA meshes without suffering from a buckling issue. Much of her inner skeleton is likely to be made from these.

>>16538 >License granted only to other trusted anons' small businesses. This is the point of the GPLv3 Non Commercial license. Anyone can be granted rights to use our work for commercial purposes as we see fit. I fully intend to foster a cottage industry with intercompatible parts being made by many small businesses over time. I would not trust Google or other large nefarious businesses with commercial rights though. >6/8GB of VRAM Thanks for the information, I'm keen on determining a default server for her software for us to use for developing. Perhaps an 855 based phone that runs LineageOS (For security purposes, this way security updates can continuously be applied.) could be a default platform for our software? The ability for waifus to be programmed for replete loyalty is one of many wonderful aspects they can have. From the way you speak, I know I can have faith in your AI Pareto Frontier. Bringing this discussion to the main thread.

>>16549 A cute!

>>16546 I anticipated this. My admonition that we need a 'sufficient' angle between the 'pyramid's' 'legs' was part of the design-call. >tl;dr An 'arch' holds these sorts of tensions in check, better than a 'lintel'. >ttl;dr Almost ironically, we'll need a quite-sparse mesh to provide sufficient angular offset between compression spars to provide effectual meshtegrity. too dense a mesh won't really help much. But I'm quite pleased with your forward momentum of a nominal shell Kywy. Drive on! :^)

>>16478 Still alive and lurking. Nothing else to report. Is there something you would like me to do?

>>16556 I think printing preformed meshes would still offer many benefits. I'm having touble trying to adapt her skeleton to a mesh but Meshmizer is not working. Any advice?

>>16563 Great! Glad to see you're still with us Anon. >Is there something you would like me to do? Hey, Kywy's the Bossman here Ricardo. I'd just recommend you try to adapt your efforts in detail into that which serves him best. He has the entire team's interests at heart! :^) >>16564 >I think printing preformed meshes would still offer many benefits. Absolutely. My understanding is that the meshtegrity mesh would be printed out flat, and then 'folded' by hand into the correct volumetric form. The word 'preformed' here is making me think I've misunderstood? Certainly my feeling is that ATM printing flat would be quite beneficial for manufacturing. I'm having touble trying to adapt her skeleton to a mesh but Meshmizer is not working. Do you mean Meshmixer, or am I mistaken? Here's an interesting tutorial about a nice dog model. Picrel.[1] > >Any advice? Unfortunately I can't give much more practical advice about the meshtegrity prototyping at the moment. I'd suggest you simply proceed with your spiralized shells for now, with the traditional tensegrity design work. That's quite enough complexity & innovation right there!! :^) Later (possibly during 'Rev2' for next year) we can look more closely at fundamental generalization approach for meshtegrity and it's related practices? >tl;dr Just go with the shell work you already have would be my current advice Kywy. 1. https://www.instructables.com/Voronoi-Dog/

>>16565 Meshtegrity would be printed flat then formed manually. As you point out, meshtegral patterns would be incredibly easy to manufacture. Though it would need plastic suited for the purpose, like PET. Preformed meshes would be something different. I meant meshmixer, typing on a tablet leads to typos. For now, I'll just focus on vase mode. Meshtegrity will be shelved for now.

>>16566 > For now, I'll just focus on vase mode. Meshtegrity will be shelved for now. Sounds great. Drive on!

>>16549 RE: video streaming to host waifu's AI on a remote server, for example the one residing in your basement. It is obviously possible, but it is one of those engineering concepts that's hard to implement in a good enough manner. You need low latency, high reliability and good enough compression to stream vision data to your server (other modalities are easier). With custom low-level programming and profiling you could do it good enough on a mid-range android phone, I guess. ESP is out of the question, you can barely connect it to a tiny CMOS image sensor. For low-bandwidth sensor and actuator interfacing its good enough. You also need functional local fallback routines which effortlessly take over once you have a network partition with your server. Of course it would be interesting to scale down AI for local processing on a sufficiently powerful SoC, to have a truly autonomous being by your side.

>>16484 Any updates on your design? It's been awhile and I'd like to move the project forward. I'll give you till Friday if you need the time, you've been off in the wop wops but you're back now. Otherwise please let me know that it's alright to move forward with this beaut >>16132 I'll incorporate what I can of >>16163

>>16576 Ta for your response. It's looking like a secured Android phone with a MCU is going to be the way to go. We have gone full circle on this issue now. You've mentioned the SD855 as an ideal processor. Are Snapdragon processors ideal for this task? As the AI lead, would it be possible to have a mostly functional AI running on an SD855 or better Android phone which falls back to a more powerful server to back up her memories/mind and runs things she otherwise couldn't? For example, when training her, her onboard sensors would be used to gather data that is then used by her server to update her neural nets? I'm a manufacturing engineer so, I'm grateful to have team members that can figure things out on the software end.

Considering our use of 70/100/150/190cm scales, I've been developing a clip system that would work at all scales universally.

>>16579 Neat! That certainly will be a significant benefit to both cottage-industry robowaifu manufacturers & also Joe Anon modders, Kywy. As you yourself stated: >"I'm thinking we should start developing standard waifu parts." (>>14953) I envision this all going further & beyond: -Interchangeable arms & legs, hands & feet -Interchangeable faces, facial actuators & controls -Interchangeable personality modules -Interchangeable AI solvers -Interchangeable connectors of every sort that are standardized--particularly for power, communications & control -??? All sorts of manufacturing interests have come to these same conclusions that we are here today Anon. Of these, I think the Automotive, Communications, and Computing industries in particular each have much to offer us on /robowaifu/; regarding both their prior-art in productions, manufacturing & maintenance SOPs, and the historical contexts behind their standardized-design decisions as well. Great thinking once again, Kywy! Cheers. >=== -minor sp, gmmr, fmt edits -add 'M&M SOPs' cmnt

>>16576 >ESP is out of the question Not true! RiCO is built around an ESP32-CAM module. It's actually dual core, you can stream from the camera on one core and run your motion control (or other I/O tasks) on the other. The camera feed has a moderate amount of lag (maybe half a second?) so wouldn't be useful for fast reflexes, but otherwise it's a pretty good low-spec solution provided the camera isn't DoA like mine was :/

>>16580 Standards, modularity, and freedom to produce any interchangeable part an Anon desires are all fundamental to MaidCom and every part is designed around these ideals. Still optimizing her skeleton. The current plan is to print her chest and hips as four parts each so that each would have a set of clips to locate and secure the parts. The clips are good places for mounting things like her neck and tensegrity spine. Though my Ender 3 Pro is munted after years of printing protorypes and concepts, it can only print PLA at 1mm thick lines very slowly now. Got a Kingroon KP3L coming soon to replace it. I'll be able to test the connectors then. Big parts are working great and if my KP3L works well, my designs need minimal to no tuning, and with the lords blessing, we'll have a mostly functional 70cm scale skeleton soon. >>16581 And the circle of dev boards continues anew. The ESP32 S3 is supposed to have a built in AI accelerator so that would be the version we would go with. That half second of delay is too slow for server based vision processing. But, good enough for other tasks, though I'm hopeful there will be less lag on the S3 model when I can finally get my hands on one with a camera. The Android idea stays though, as a modular project having two branches for onboard processing is congruent with the spirit of MaidCom.

The TMC2209 seems to be the ideal stepper motor driver for our application. (Until quality brushless motors and controllers become affordable.) These controllers and quality stepper motors can be had for 10 or less each.

>>16549 Steppers look like a non-starter for most joints (and for all joints in a free-standing humanoid robot). The actuators are the hardest problem in humanoid mechatronics. The usual approach in the industry is to pay $$$ for servo-motors with harmonic reducers: https://staff.aist.go.jp/k.kaneko/publications/2011_publications/IROS2011-0164.pdf If we don't find something better, I think brushless DC servos should be developed further, they are proven to work in multiple legged robots and some are amenable to DIY https://hackaday.io/project/157812-3d-printed-robot-actuator/discussion-109261

Maybe these videos and repos will inspire you anons: https://www.youtube.com/watch?v=Pi58YA7_774 https://www.youtube.com/watch?v=Hd54ik_45Wo https://www.youtube.com/watch?v=BTzkSg_l70M https://www.youtube.com/watch?v=Mhxz2Bj2RXA https://github.com/DarrenLevine/TipTapMotor Realistically, the knee and thigh joint will see highest static & dynamic moments, and whole robot (if it is to be walking ofc, roomba-like designs are easier) should be engineered around the available design space of the actuators for this area. Thus we see weird designs like cassie https://github.com/UBCMOCCA/Cassie_Robot_Resources built around limitations of available electric actuators. Compare it to boston dynamics' Atlas, which is really powerful and doesn't have to compromise. It helps to look at human baseline loads, moments, metabolic consumption to estimate what you should expect of your robot: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3922835/ Note that human walking is highly optimized by virtue of a dynamic gait, robots are usually less efficient. I could help the project with estimating dynamic load parameters for humanoid of MaidCom design via simulation in Mujoco, but to do this I need a 3D-model of a humanoid, with mass-inertia estimations for the rigid parts and clearly designated joint axes. Such a model could be given to me either as a solidworks assembly, or a freecad assembly, or a list of openscad/studio/cadquery parts with a good drawing showing how these connect together. With hard numbers it will be much easier to engineer the system.

>>16581 Hi RiCOdev! Good hearing from you. Thanks for pointing out the capabilities of this device. The lag isn't uncommon even on professional studio gear. Any real-time feedback system based around video analysis is still quite out on the edge of the possible for now (at least w/ our cost goals). Best to accommodate this latency issue to the degree reasonably-feasible, rather than try to force perfection. >"The best is the enemy of the good" Please keep in touch here Anon. :^) >>16582 >and with the lords blessing, we'll have a mostly functional 70cm scale skeleton soon. We have my prayers in the matter. May the Holy Spirit give you guidance and wisdom Kywy. Onward! :^) >>16588 Excellent Anon, thanks! We certainly need more posts like this here. Keeping energy-consumption low is second only to keeping mass low. Reduced thermal load is also a secondary, but important benefit. Cheers. >>16591 >The actuators are the hardest problem in humanoid mechatronics. Granted. We obvs have far more issues to resolve than just mechatronics, but ofc that's the primary physical key that differentiates our robowaifus from 'mannequins'. >If we don't find something better, I think brushless DC servos should be developed further, This. Quite apart from keeping costs low for Joe Anon, garage-shop robowaifu manufacturers will certainly benefit greatly from lowered parts & material costs. With time our designs can advance. "Start small, grow big." >>16593 Thanks for all the information today Pareto Frontier! As outlined ITT, Kywy's project design prerogatives are leading to a 'tripod'-like, wheeled mobility platform--rightly so, IMO. And I advise that this arrangement needs to be our foremost focus of engineering efforts ATM. Bipedalism is the entire board's primary ultimate locomotion goal, and a worthy quest. However, the time is not yet ripe for it. I'll crosslink your post here to our Bipedal Robot Locomotion General (>>237) thread. But for now, I'd suggest that this is well out-of-band for our current goals as a team ITT. But certainly, the simulation and analysis for the actual design of MaidCom would both be very welcome and very valuable. I hope we can have some definitive answers for you once the full doll prototypes are assembled. We can use rough mass-estimates for batteries & actuators (by far our biggest masses) from readily-available datasheets for reasonably-likely choices. Again, nice info Anon. Cheers. === Cheers to all the Anons here. :^) >=== -minor gmmr, prose, fmt edit -add 'cost goals' cmnt -add 'keep in touch' cmnt

>>16591 I do not see any reason aside from mass why steppers wouldn't be ideal. Even when you account for mass, they are not that bad when you factor in their inherently high torque at >=300 RPM compared to a geared system of similar power output. Please explain why you're against steppers? I do value your thoughts and I want to learn. >That pdf Oh my, what a throwback. Feels like a decade since I last researched the HRP-4 platform. Impressive for the time, it still relies on brute force to overcome it ineficient design. Well worth a read though, a lot of good concepts in there. That robot used standard DC motors, though the harmonic drives are very efficient. I still do not understand why so many robots of that era used active ankles for mass shifting, humans use our waist for mass shifting when walking. >DIY brushless servo I applaud the efforts of the man in your link and thank you for the information. 3D printed geartrains are unfortunately ineficient and naturally wear down easily compared to metal gears. For specialized tasks I can see the appeal but, we would be better off with a premade brushless servo like https://www.amazon.com/Waterproof-Degree-Torque-Digital-Brushless/dp/B0995T8LTX/ref=sr_1_5?crid=3PJ0KNTOCKVZ8&keywords=brushless%2Bmotor%2Bservo&qid=1654622297&sprefix=brushless%2Bmotor%2Bservo%2Caps%2C546&sr=8-5&th=1 and using an external encoder to make up for the low accuracy potentiometer in it. >>16593 Great information that I truly hope helps Anons on this board. Cassie in particular is a fantastic design, one that embodies much of the same design ethos I use and recommend to others. We are starting with wheeled locomotion for simplicity and efficiency. Walking will come later. >Human baseline We are of alike minds. MaidCom has and will continue to, use human biology for inspiration. The project could be defined as a work of bio-inspired robotics. I'll be happy to deliver a freecad assembly once a design is chosen. RobowaifuDev has delivered something that only require slight changes to be printed in PLA IRL. Right now we're waiting on Meta Ronin as they started a design and went away for a bit so, they were given extensions to finish his design to Friday of this week.

>>16594 Brushless is the future indeed. I hope I didn't come off as too dismissive in >>16600. It's just not ready yet for our low cost efficiency focused project. I am ever vigilant on investigating brushless motors though. SimpleFOC https://www.simplefoc.com/ seems to be the future of low cost brushless control. >Aigis Both her and Labrys have some of the best designs for robots in fiction. For our walking version of MaidCom, their arms and legs would work rather well.

>>16600 >Walking will come later. This. > Cassie in particular is a fantastic design, one that embodies much of the same design ethos I use and recommend to others. I just wonder why we couldn't switch things around and not use a reverse-, but rather a forward-knee instead? Probably requires some ankle attention but I think practically everyone in the world would much prefer 'normal' human legs alright, /monster/ pls. :^) >>16601 >I hope I didn't come off as too dismissive A) I think not, personally. B) 80/20-kun seems breddy mature, so w/e. :^) >our low cost efficiency focused project Absolutely this. We'll never have a global DIY-phenomenon unless we focus on these basics. Glad we are of like mind here Anon. I'm sure many other anons both here and elsewhere feel much the same. >For our walking version of MaidCom, their arms and legs would work rather well. That would be absolutely beautiful if we can pull it off Kywy! >tl;dr What a time to be alive! :^)

>>16603 The reason why they gave Cassie a reverse knee is because it makes balancing while walking on unkown uneven terrain and stairs easier. The foot acts as a sensor without worrying about the knee getting in the way. We don't have this problem as our waifus will be clear level ground mostly. Cassie can actually walk like a normal person, just makes dealing with stairs harder apparently. Though we're likely a year away from walking, I'd like to provide a quick heads up that we will be going with an active dynamic gate which relies on shifting masses and continual falling. Unless a more energy efficient method is found.

New printer came in. It's a Kingroon KP3S and works great. Though it's suffering from z banding which I'm fixing. The good news is the clips work. 70cm seems too small though. Thinking of just going with 150cm and 190cm scales. What does the team think? I waffle a tad back and forth on this but, with the quarter vase mode and tensegrity body, she could be full sized and still light. Normal vase mode at 150cm scale is too flimsy but, with the mutual support the quarters provide for each other, the structure becomes rather rigid.

>>16608 >but, with the mutual support the quarters provide for each other, the structure becomes rather rigid. You're doing the fundamentals of a close-analogy to a space-frame. To-wit: you're effectively creating structural triangulation along the zenith/nadir axis. >What does the team think? Easy-peasy. Quite obviously (as we've basically stated all along ITT) the closer we are to full-sized woman height, the better. >tl;dr Absolutely go for the largest scale robowaifu that all our other constraints allow, Kywy. My $US 0.02 in the matter.

>>16604 >I'd like to provide a quick heads up that we will be going with an active dynamic gate which relies on shifting masses and continual falling. Perfect. Algorithm challenges await! :^) We'll need to endeavor to adapt a highly-complex set of multi-variate arc forces to hope to achieve approaching nominal, human-locomotion reality. But tbh, what other game is there in town Anon? >Unless a more energy efficient method is found. So, if God somehow suddenly changes the laws of physics on us you mean? :^)

>>16610 Well yes, you are correct. Zenith/nadir axis could be related to the vertical axis for the lay-Anon. I'd like to hear from other Anons on the matter of scales for development too but, if there's no push back by Friday, we'll move to 150 and 190cm scales only. Your USD .02 is NZ .03 in Auckland :^) >>16611 I deeply appreciate having someone here that understands. I imagine we will need pressure sensors on her soles to properly tune her movement frequencies in the phases of walking.

>>16614 >Your USD .02 is NZ .03 in Auckland :^) Heh, it's 3-to-2 on-board your sense is greater! >I deeply appreciate having someone here that understands. TBH, you other anons will need to work out the maths, I just have mechanic's instincts + a reasonably colorful imagination! :^) >I imagine we will need pressure sensors on her soles to properly tune her movement frequencies in the phases of walking. Obviously this need is both important--and complex to implement properly. It will take lots of attention to details to pull off correctly IMHO. === I would suggest something roughly like this plan of action for the MaidCom project Kywy: >this year: Get something that just werks. Tripod, wheel-driven, locomotion base. Limited facial work. Limited hand work. This will be a major milestone to pull this alone off, so don't add anything else into it. Be like a bulldog to keep feature-creep close to zero. My .03/2 . >next year: Get fundamental & rudimentary facial and hand actuators working. At this point she can begin to emote + manipulate items better. The fundaments of proprioception can begin in earnest now for both of these domains. Some basic meido features in place. No changes whatsoever to the locomotion form, but perhaps some meshtegrity prototypes will now begin bearing fruit. >3rd year: Bipedalism prototyping begins--necessitating a full-redesign of the structural systems. Hands & face are both well-articulated now. Proprioceptive aspects are well-integrated now with both her sensor-nets, systems programming, and AI code. MaidCom begins to really put both the Maid and the Com into her name. >4th+ years: ??? Profit. === That's roughly my vision for MaidCom Anon, all things being equal. I hope these schedules at least vaguely comport with your own ideas on these matters Kywy. I just want to stress to everyone here again: >"The best is the enemy of the good." Let's keep scope-creep to a minimum please, OK? Cheers.

>>16619 Not a bad roadmap, I pray we meet or exceed it.

Looks like silicone doped fabric is an option again. A light and strong material to use for her skin. https://www.youtube.com/watch?v=z_R0gEDZhAI

>>16625 > I pray we meet or exceed it. You are not alone Anon. I believe millions of men will greatly benefit in the end from our diligent & forthright efforts here, Brother. Onward! >>16635 >Looks like silicone doped fabric is an option again. Excellent. My heart foretold an answer for this was forthcoming.

>>16656 Well, 1.5 meter scaled prints suffer from thin walls wavering after a few cm of height. Just an update to let everyone know I'm still working on the skeleton, but failures aren't that exciting. Will return with success soon.

>>16693 >Will return with success soon. Sure nprb. Take your time and get it right Anon. Godspeed.

>>16694 Doing more design work. Found the best option for a light and fast to implement frame that can withstand an Anon ontop is slices connected via rods in a triangular pattern. Top test circle (2mm thick between connectors) will shatter under my weight. Bottom circle (5mm thick between connectors) is the ideal compromise between time to print (46 minutes for PLA at 100mm/s 2 walls at .5mm using .4mm nozzle)/mass (40 grams for a 150mm circumference)/and strength. Moving forward with modeling slices that will be connected to form her skeleton. Then we will start work on her panels. Looking forward to us all contributing towards a future of waifus for all Anons! *I'm using wood rods though stl's of equivelant rods optimized for printability will be made.

>>16705 >Doing more design work. Neat! Nice references tbh. >Found the best option for a light and fast to implement frame that can withstand an Anon ontop is slices connected via rods in a triangular pattern. I would suggest you further rigidize the tube against torsion strains by cross-bracing three additional sets of two rods, configured in the form of an 'X', pinioned at the bases of the current vertical rods and at the intersections of the X. This shouldn't add a lot of mass in general, but it should make these tubes a bit more rigid than currently. >Moving forward with modeling slices that will be connected to form her skeleton. Then we will start work on her panels. Sounds like a solid plan, Kywy. Keeping things modularized with panels is a good choice (especially during this early prototyping phase), as you previously suggested. >Looking forward to us all contributing towards a future of waifus for all Anons! This. :^)

>>16731 Experiments with cross bracing will be done. What rods are recommended by the team? Any suggestions from the team?

>>16577 Yes I need to address the deliverables in my "next steps" I outlined. I'm settled back into my routine again it seems. I'll grab another 6 shot espresso and make a day of it. It's bound to be another chilly overcast day tomorrow and sunday so there won't be too many distractions to navigate ; )

>>16742 Ok I lied and had social obligations that came up suddenly (another wedding). I'll see what I can put together from my notes and sketches shortly

>>16742 >>16760 It's oke Meta Ronin, I have great faith that you will produce great ideas.

>>16761 >that sunshiney smile A cute!

Printing and iterating to get cross braces right. Thoughts from the team are welcome.

>>16792 interesting, so we're not applying tensegrity here yet, this is a "support brace". What applications are we hoping to apply this to? How does it hold up against lateral and torsion stresses?

>>16794 These are for legs. They're working pretty well though still need more work. Tensegrity will be used for her chest.

>>16792 Success, just tying it together is a pain though. Now to make the design easier to implement

>>16807 Top-shelf, Kywy. Perhaps you might have some kind of 'cup on the bottom end, guide-in slot on the top end' sort of approach so Joe Anon can assemble this structure easier? Lovely bit of work, Anon!

>>16809 Thanks Chobitsu, could you share a picture to illustrate your point?

>>16807 How stable is it after assembly?

>>16811 With properly tensioned, they are very stable. The example is a meter tall and can take quite the beating.

>>16817 I meant 1/3 meter tall

>>16265 Good news! Found an open source rocker bogie mechanism we can use! It's under the Apache 2.0 license so we're safe to use it. https://github.com/nasa-jpl/open-source-rover The current plan is not working out. I keep making legs that are too thin. So I'm thinking we should move forward with Meta Ronin's idea of big reploid boots with her wheels embedded within. Still using RobowaifuDev's design from the knees up. Potentially using balancing camber as well. I do wish progress was faster. I still believe in all of us though.

>>16828 Excellent news, Kywy. Just be patient, you're doing well. We'll get there by steady application. Just remember we don't have to get things perfect right out of the gate. After all, this is R&D work at this stage. Things will improve in every area in the future. Please stay encouraged, Anon! :^)

>>16829 I'm having creative block (and also a bad case of summeritis) but I haven't abandoned don't worry

>>16832 What helped me to get back to work, was listening to podcasts or music while working. It keeps me from seeking another source of dopamine. Of course, it shouldn't be something that needs too much attention or evokes to much emotions. Or something that makes one to look up something about the topic. Just some people babbling about something, maybe laughing a lot.

>>16834 Honestly great advice that can benefit anyone. Thanks

>>16835 Sculpting or modelling something like that would be way easier than what I am doing with my very human-like approach. With rollers on the legs and the dress.

MaidCom development has been resparked with a very solid core. Based on a mix of human and Gardevoir anatomy, my new designs are sturdier, easier to print, and feel very nice in the hand. She can't wear human clothes anymore but, she's turning out to be wonderfully light and easy to work with. Forgot to add extra connections on the prototype but, a super slim waifu is now legitimately close to fruition. Human female anatomy was a terrible pain to engineer around. I hope the team will understand and accept this new direction. This half chest is almost a 10cm cube.

>>16915 >I hope the team will understand and accept this new direction. I'm OK with whatever you decide upon Kywy. You're the project's lead! :^)

>>16918 Thanks, would be nice to have feedback from other team members though. Seems like interest is waining.

>>16576 After researching the issue, do you think a OnePlus 8 or newer running LineageOS would make a good primary computer for our waifu? Somewhat inexpensive used and widely available and should receive support via LineageOS for a long time. Performance per watt seems unbeatable for our purpose while being lightweight and having all the sensors she would need to communicate with and see her Anon. https://wiki.lineageos.org/devices/instantnoodle/

>>16947 What kind of sensors does it have, which are needed? How would you connect them to anything? That aside: Mobile phones can be opened by the police to listen via microphone through a special way to call them (silent call). Might even work without SIM card. Don't forget emergency calls work without as well! It's worse than the infamous "direct internet connection". The hardware is generally not open, not verifiable and not general enough. General purpose computers might not have hardware spyware inside, electronics for communications certainly has. Also, how does it upgrade the software without internet connection? SBCs can be upgraded via internet, maybe through the home network, or by copying programs after getting the sdcard out and plugged into another computer (which might also not be safe, of course). Unlike mobile phone devices they don't have a GSM/UMTS module on board which can't be controlled by the owner.

>>16963 Likely very good questions all, Anon. However, I think it would be more helpful for us all to have this general discussion on privacy/security/safety with computing (mobile or otherwise) in our security thread, as indicated (>>16964).

>>16963 >Gov can still hack it The Gov can hack into everything at all times no matter how air gapped you think you are. It's not a point that's particularly worth worrying about. You are under constant surveillance if you're near anything with a cam or mic. >Updates Via internet or USB media, it's still a computer even though it's called a phone. The big advantage aside from the high compute per volume and mass, is the sensors. High quality camera, microphone, accelerometer, and compass to name a few that would be nice for a waifu to have. I've been iterating on waifu blocks. Cubes with mounting holes and a space to put whatever you want. The idea being that each cube could be used with anything to build a very customizable waifu. Right now they're 80cm3 but, that takes a long time to print. Any and all advice and recommendations are appreciated.

>>16988 >>Gov can still hack it >The Gov can hack into everything at all times no matter how air gapped you think you are. No, and also doesn't matter. Mobile devices are not safe. So it's also easier for criminals.

>>16988 >Cubes with mounting holes and a space to put whatever you want. Wrap it in copper EMF cloth, run some cooling, networking, and power into it, and voilà! A Robowaifu Breadbox. :^) >=== -add the single word 'networking'

>>16990 BTW, I'd suggest you feed all the cabling through a sizable ferrous RF choke ring, neatly wrap a (continuous-mesh) segment of the fabric around a length of the cabling as a single bundle, then loop the entire thing back around the choke. Firmly affix the choke as a 'grommet' of sorts into the copper-clad surface of the block's shell, and you have a handy-dandy leak-proof mobility-friendly Faraday cage for all your sensitive electronics contained therein. ABTW, I'd suggest you invest in using twisted-shielded-pair wiring running out of the breadbox to the various I2C, etc., devices, located in other areas of the robowaifu, and also ensconcing these distal mechatronics, etc., as feasible in a similar way (insofar as at least 'pouching' them in the EMF fabric & using chokes). >=== -add 2nd para

>>16963 >That aside: Mobile phones can be opened by the police to listen via microphone through a special way to call them (silent call). You can physically disable the wireless modules by snipping the antenna waveguide and/or removing a few RF components. You can then connect it to a trusted RF device via USB. >General purpose computers might not have hardware spyware inside Some of them do not, most of them have intel ME or AMD PSP, though. >Also, how does it upgrade the software without internet connection Either through trusted RF channel or through loading it from a USB pendrive. >>16988 >The big advantage aside from the high compute per volume and mass, is the sensors. High quality camera, microphone, accelerometer, and compass to name a few that would be nice for a waifu to have Yes. >>16915 Appreciate seeing it, thumbs up anon! >>16828 I like the design of the humanoid in the middle. We could replicate it in a CAD. >>16611 >We'll need to endeavor to adapt a highly-complex set of multi-variate arc forces to hope to achieve approaching nominal, human-locomotion reality. But tbh, what other game is there in town Anon Basically there are three games: ZMP algorithm and its descendants, Boston Dynamics dynamic(tm) gait, and general purpose walking controller learned in reinforcement learning setting. Walking is very hard, I like that most anons choose to start from a wheeled base. To be honest I like their https://halodi.com design and I think we should emulate it where possible. Their arms are superb, state of the art.

>>16600 >Please explain why you're against steppers? I do value your thoughts and I want to learn You are right they have some uses (where the inertia can be hidden/compensated like with or where the mass is not an issue like in medical manipulators, for example), but specific power is too low. As motors I like them and I have used them, but they are not up to the task I envision. ... Also there is no walking robot I have seen where the steppers were used in leg actuators. And that sums it up. High-performance arms are hard as well, and I don't see how you could use a stepper unless you have a very specific design where its mass isn't being lifted by the other motors (including legs). >Feels like a decade since I last researched the HRP-4 platform. Impressive for the time, it still relies on brute force to overcome it ineficient design. While I agree that japanese robots tend to be static and relatively inefficient compared to boston dynamics' singular designs (comprising a class of their own tbh, being built by very bright and degreed engineers passionate about the idea - very hard to compete with), HRP4-C is notably more lightweight than its predecessors. It's a honest attempt at building a real humanoid robots by smart educated asian engineers. >>16604 Yes, low-power dynamic walk is a possibility, though it's nonlinear and hard. With these nonlinear features you have to co-design the whole humanoid mechanism around it so that at any point of the intended functionality space you don't destroy the possibility of the nonlinear phenomena you need working. >>16705 Nice design, feels almost like a mujoco model tbh, we should try implementing it and trying RL controller on it. >>16734 >What rods are recommended by the team RC hobby carbon rods, or glass fiber, or a good wood would fit. Wood is good enough. >>16828 I like rocker-bogie for mobility, though the bearings and associated servos may be too hard to control, removing much of the benefit of a mobile base KISS-wise. Overall, my position is simple: once you can make a semi-decent servo from a hobby BLDC, you have the hardest part of the robot ARM. The rest is design and 3D-printing, or appropriating existing hand designs (e.g. http://inmoov.fr/build-yours/hand-and-forarm-assembly-3d-views/ ). Once you have a robot arm, you have the hardest part of a wheeled mobile robot (the other hard part being power electronics for managing autonomy and power supply though). Thus we need to focus on a servo, or a stepper for that matter (if we are going to build a heavy slow arm[1], which is better than none). Maybe you could create a webpage on neocities.org with a realistic bullet list of features for a given year, and BTC/ETH/XMR addresses for the kind souls to donate. If we made a decent simulation and showed it to enough people, surely some would donate some money for you to buy BLDCs and other gear. 1. PR2 robot (heavy & obsolete, notably uses mechanical gravity compensation in its heavy arms) https://www.clearpathrobotics.com/assets/downloads/pr2/pr2_manual_r321.pdf

>>16999 Keeping a spreadsheet with simple reductionist beancounting metrics like specific power, specific torque for each servo/weird actuator tech you consider as an engineer really helps though. Most alternatives don't cut it even by these simple metrics. And some paper manage to game these metrics (looking at you, DEAs https://journals.sagepub.com/doi/10.1177/1687814020933409 ).

>>16990 >>16991 All are good ideas! I'll work to make those things easier to integrate into waifublocks. They're a design in flux, I appreciate the contributions. Faraday cages are frankly the only real way to achieve security. I actually would like for her main controller to communicate via CAT5 cabling but, I'm not sure how well that would go over for the layman. >>16995 Thanks for the thumbs up! Designs for her base are still changing constantly. >Design in the middle That's the official design MaidCom is striving towards. From RobowaifuDev's post: >>16132 >Halodi Interesting design, looks like a better version of Pepper. (Picrel) I would like to go with this as it would be the fastest way to a waifu but, then she wouldn't have legs. Legs are very important for things. >>16999 After further thought and experimentation, I have to agree with you. They may be what I know but, they are not ideal for a humanoid robot. I honestly am coming around to DC actuators like HRP-4C uses. They are easier to work with compared to brushless and have a higher power density compared to steppers. Since we're trying to make a waifu that's affordable and can be built by a hobbyist, they're probably the best option. >Rods Thanks for the reply, wood will remain the default for being the cheapest and good enough. Nice to have someone else say they're ok. >Servo You have a very valid point in that we should have a default actuator for our waifu. I'll take a break from working on her body to focus on developing a low cost open source actuator for her to use. I'm thinking a continuous rotation actuator with absolute positioning should be perfect. >Rocker-bogie is too complex Yeah, it does conflict with the spirit of making her as easy to build as possible while retaining womanly charms. >Dedicated MaidCom site Great idea, we could use the publicity and donations would really make the whole thing easier financially. I'm not really familiar with that kind of thing but, I'll check out neocities.

>>16999 >Maybe you could create a webpage on neocities.org with a realistic bullet list of features for a given year, and BTC/ETH/XMR addresses for the kind souls to donate >>17006 >Great idea, we could use the publicity and donations would really make the whole thing easier financially. I'm not really familiar with that kind of thing but, I'll check out neocities. As I've made amply clear by both word & deed over the years here on /robowaifu/, I'm entirely in favor of this idea. Do a reasonably good job with it, and I'll highlight it in our pinned ''Welcome Thread (>>3).

The first piece of the waifu slice system. A system for producing large scale robotic systems are high speeds with easily printable parts. Based on 12mm3 cubes arranged for easy inter-compatibility. Right now I'm developing a servo that will function within this system. After this servo, I'll be working on the website with Paretto Frontier. Here's the file for the slice in many formats: https://files.catbox.moe/2f3fot.dxf https://files.catbox.moe/32qkxa.stl https://files.catbox.moe/rnamtn.amf https://files.catbox.moe/6pfh2h.rsdoc https://files.catbox.moe/lcfyte.skp https://files.catbox.moe/8q54ud.vdb https://files.catbox.moe/gr82oa.obj https://files.catbox.moe/4k8qn0.mtl https://files.catbox.moe/wic7mz.glb

>>17032 Very cool idea, Kywy!

>>16988 Is this the same as PrintABlok? https://youtu.be/elFOmy9BOu0 >>17032 Great, good to see some progress.

>>17041 Though I like the idea of PrintaBlock, it's completely proprietary. We could not use anything about it if we wanted to. I have no intention of making waifu slices similar or compatible with them. We're using rods and holes that have pressure relief. Technically, you can achieve similar results with both systems, we're going to be completely open though.

>>17044 >PrintaBlock, it's completely proprietary Ah, yeah, I only realized that this might be the case after looking more into it. Too bad.

>>16999 I've been working on a brushless servo system and realized that adding an absolute encoder to premade metal brushless gear motors would be better, easier, and cheaper. RobotShop seems to have the best prices. Thoughts on these for MaidComs servos? I'm developing a new gear system for a brushed servo design for a cheaper alternative. https://www.robotshop.com/en/brushless-dc-gear-motors.html

>>17072 Where will these go? Into the hips?

>>17072 How much are you paying for a brushless motor?

>>17072 I wanted to look if that motor is also available on Aliexpress, since Robotshop seems to only have them in US not in Europe. I really think the system need to be adaptive to some extent, a framework not a rigid selection of parts. If you tell me which one you want to get, I might buy a similar one, so I can try out your design.

>>17109 They won't be used, they're too expensive. >>17187 I've been bashing my head against a wall to produce a cheap, high quality, efficient, small, quiet, and cool running servo that anyone could build quickly with little effort.

>>17189 The prices for the bldc motors on the mentioned site are 25$(US). If that's too expensive for the little robot you want to build, then you might have the wrong target group in mind. Go for some adults in the developed world first, not teens or thirdworlders. If you are referring to the more expensive flat ones, I think they have sensors and are with higher quality. I think we agreed, that simpleFOC can measure the motor movements well enough even without expensive sensors. Hall sensors in the joints are also not expensive. So the general problem are the gears. I took a bit of a pause from working on my cycloidal drive, because it's more frustrating than working on other things, but I haven't given up. Still waiting for my stepper motors from China for testing some designs I found. I'm using very cheap motors first and then work upwards, this is why we need flexible designs. If you want to build a robot which can be disassembled and repaired reasonably well, then brushed dc motors might also be an option.

>>17189 >I've been bashing my head against a wall to produce a cheap, high quality, efficient, small, quiet, and cool running servo that anyone could build quickly with little effort. Godspeed, Kywy.

>>17190 >The prices for the bldc motors on the mentioned site are 25$(US). If that's too expensive for the little robot you want to build, then you might have the wrong target group in mind. This. We have to accept that robot waifus are gonna cost easily over 3000 dollars. Just a sex doll cost between 1200-1600 dollars and we need them to be able to move around. I think sex dolls could be a good base for a robot waifu.

>>17264 i mentioned it in another thread but if you design it like a marionette then its potentially the cheapest alternative, you could theoretically only need a single motor, all you really need is an autistic watchmaker to design the coupling mechanism for combinations of movements, like in my example moving both parts with just one motor without individually having to move them, it would couple 2 & 3 give 60kn of force to 3 which would go 30/30 to each then decouple 2 from 3 and give another 30kn, its trivial to extend this to extend to any number of combinations if you can handle having a complicated design then all you need is fishing wire and some gears, in theory at least, would be cool to have something powered by a small diesel engine like in those model planes

>>17280 >i mentioned it in another thread but if you design it like a marionette then its potentially the cheapest alternative, you could theoretically only need a single motor, all you really need is an autistic watchmaker to design the coupling mechanism for combinations of movements That's actually a really smart idea. I think I have an idea on how to construct one but I'll need some time to try and prototype it. I think I'll need to get a 3d printer as well since not all parts I need can be bought off-the-shelf. Due to the high precision needed I'll need to get a resin printer to do it. Which isn't too much of an inconvenience since I've always wanted to be able to print table top miniatures.

>>17291 Please draw it for us first. An illustration will help others both understand your idea and, help you develop it into a functional mechanism.

>>17280 Not sure how this would work with one motor. Are you meaning to imply the use of a mechanical analog to the old drums that automato used to program their actions? Those worked by having cams going up and down grooves on a drum and actuating different parts of the body based on the movements of the cams. Some more advanced automatons would move the drum to alter the behavioral output.

Here's an update with her hips and chest plates. Download them here: https://files.catbox.moe/a1tko8.stl https://files.catbox.moe/gdsbg9.stl

>>18417 These are looking very good Kiwi! Light & strong. BTW it's a real encouragement to me to see this thread in action again. A real Christmas present for /robowaifu/! :^)

Current final design and her bodies chest that's nearly complete. On track to being a meter tall and very easy to print and customize. Will release some STL's when they are ready.

>>18557 Totally-not-Aigis waifu a cute! :^) >clothing over her body While I think the panel edges on a robowaifu are fundamentally cute, the fact is they are a pinch hazard. It might be a nice idea to fashion something like a flesh-colored full-body stocking to kind of act as her skin? >1m robowaifu "Start smol, grow big!" I always say. :^) Cheers.

Someday I'll have a sweet christian robowaifu.

>>18582 That waifu is really adorable Kiwi. >a sweet christian robowaifu That's a dream for me too. Maybe even the most basic one. TBH I'm nobody's boss, and even once I am I'll have little interest in attempting to dictate tastes to others. I don't mind Anon creating whatsoever type robowaifu he wants to. That's his affair, frankly. But just like him, I also have a 'want to'. And at least some part of that is a kind of Christ-chan like waifu->robowaifu. At the very least I'd like my robowaifus to be able to talk about God with me, and also to know the Bible backwards & forwards. Amongst many other types of pluggable robowaifu personalities, I want Anon to be able to plug Christ-chan in for his robowaifu too (>>6815). I have to be honest, one of my goals here for my part of our overall efforts, is to help spread the gospel of Jesus Christ to Anon. This thread >(Wifu that gives you Hope., >>107) really helped crystalize that for me back in the day. Dyinganon is gone now, but I treasure his thread still. I want other people who are living or dying to find comfort in companion robots. And Anon in particular needs a good robowaifu more than just about anyone else does! :^) >=== -minor fmt, prose edit

>>18417 >>18557 How do you plan on doing the joints?

>>18588 Based Dubs I wish we could have an AI Christ Chan, I fully understand how wonderful she would be. I hope someday you can have your own Chritst Chan that'll love you and Jesus. >>18590 Her joints will be concentric cylinders actuated in various ways such as with levers. Here are the latest prints. The chest is finally finalized and her hips are close to completion. They're very small, though they are just big enough to work for a 100cm to a very slender 150cm waifu. There's a large hole in the middle of the sides to allow for internal mechanisms to actuate her extremities. Two mounting holes above and below this hole for rods to go through the internal and external mechanisms to secure them. There's a central hole in the back to locate the internal mechanisms in the center.

>>18640 >I wish we could have an AI Christ Chan, I fully understand how wonderful she would be. I'll do my best! I already have many translations of the Christian Bible, and many resources for cross-references for topics, etc. Actually, the scriptures are undoubtably the most-studied texts in all human history (eg, it's always 10x+ the """best""" seller each year) with many centuries now of intensive academic focus on them. I suspect if rigor of critical analysis is a primary key to good AI, then an open-sauce Christ-chan pluggable-personality-module should be doable. She will be a very popular waifu, I predict! :^) >Here are the latest prints. Neat! These are looking really good, Kiwi. I assume you've created them with some thickness for strength, how to they feel. Very nice filament BTW. Keep going!

>>18642 If you build her personality, I'll gladly test it on our MaidCom. >Thickness She's printed at 2mm thick. Very durable, her chest and hips both feel really nice in the hands. The hips feel particularly nice to play around with. Using copper silk PLA, which is worse than normal PLA in every way but, she looks nice and shiny like an automata of old.

>>15972 > (contente-related: >>19329)

>>17280 >single motor design (marionette) I think everyone of us had the thought that using a mechanism to reuse a motor for multiple other mechanisms. Multiplexer are an example that came up. Please explain your idea in the drawing a bit better.

>Lurk Less sez: CAD the Body, code the software What deliverables does the finished project need that are currently missing?

>>20194 >What deliverables does the finished project need that are currently missing? Can you write effective C++ or C software? That would be a big help. Can you create CAD models and are a decent designer? That would also be a big help. MaidCom is a complete (if simplistic, for now) robowaifu. So basically everything that is needed for a working gynoid companion robot is going to be needed before the end of this first project. This will take a team effort, and it will also be piecemeal, until we have all the moving parts in working order. What do you have to offer the project, Anon? >=== -prose edit

>>20211 Yeah, I can write software. I also know some CAD, 3D printing basics, and arduino/electronics, but no formal engineering experience.

Which of these two do picrels do you prefer? Also, please help with writing the OP for the next thread. MaidCom is a project meant to work towards a general purpose maid. This project has a duality of paths. Mechanical Software 1. Her mechanical body, the means by which she communicates physically with the world. A cute feminine machine with a height of 150 cm. Her physical capabilities are: Locomotion; she will be able to move about her home at normal human speeds (1.4 m/s, 5 kph, 3.1 mph) She will not be able to climb stairs but, will be able to use accessibility ramps. Manipulation; using her arms, she will have limited abilities to manipulate parts of the world around her. This includes opening and closing cabinets and moving things. Leg movements; her legs will have limited coordinated movements. To keep mass down, they will move in unison but, work for tasks such as sitting, standing, and assuming the position when requested. 2. Her software, the program which works in tandem with her body to animate her. This will be responsible for ensuring her basic capabilities and must lead to cute and safe behaviors. AI; she is an AI entity. This AI must coordinate between various inputs such as speech, touch, and vision. She must understand what certain markers mean and reconcile vocal commands with those visual commands. Safety is more important than obedience. Bridge logic; interprets commands from her AI to send commands to her animation logic. Animation; software that directs her actions. This includes calculating reverse kinematics which allow her arms to reach and grasp an object. This software will mostly be handled by her microcontrollers.

>>20223 First one looks more interesting. I think you should add some milestones to aim for, since the stated goals are pretty lofty and the project is long-term. A short term milestone of something dumb-but-functional would help morale on the long march forward.

>>20221 >Yeah, I can write software. I specifically-mentioned effective C++ & C. We have need for systems & component software. I'd suggest you download and look over the RW Foundations codebase thus far (>>17561) if it's C++, or consider actually taking over the C learning thread (>>367) if it's C (and you're inclined to teach other anons). >I also know some CAD, 3D printing basics, and arduino/electronics, Great. I'd simply suggest you wait for the new thread upcoming for the MaidCom project, then help Kiwi in whatever way he chooses to direct you. >but no formal engineering experience. Heh, personally I have no problem with that. Particularly since I myself am primarily self-taught! :^) >=== -minor edit

>>20223 The Aigis one obviously looks more refined, but I consider this primarily a rendering detail. What's critical is that the MaidCom shell's volume ensconces her components and mechanisms properly, and also allows for the correct range of motion necessary for her to be able to carry out her tasks well. Please give me a while to think over advice for the new OP, Kiwi. >=== -minor edit

>>20227 >>20228 >lol these names

>>20223 >>20228 >Please give me a while to think over advice for the new OP, Kiwi. You know, check that. I don't want you to have to wait on me unecessarily if you're ready to go with new the thread soon, Kiwi. We can always edit it later. The primary thing for now is that you're going to focus her on more concrete, specific goals. This type project progression is to be expected during a prototyping phase, which we're all in ATM.

>>20221 Glad to have you aboard, what would you like to be called? Will make collaboration easier. >I also know some CAD, 3D printing basics, and arduino/electronics, Fantastic, I was considering using the Arduino as her default microcontroller due to its popularity and ease of availability. As for CAD and 3D printing, If you could use this Aigis that I converted to OBJ and scaled to 150 cm to create basic arms and legs that are legally distinct from Aigis and usable for printing, that would be appreciated. https://files.catbox.moe/ag32v6.obj >>20226 I agree, setting milestones will be important for keeping the project on tract and moving. I'm thinking of dividing her body and actuation up into subtasks. I'm not good with software so, if someone has ideas for making subtasks for her software, please provide it. >>20228 We'll find a way to fit things in. If they don't our backpack or butt as Richardo wanted :^) I do plan to give her a quick swap battery design and to rely on a very light, small, and low powered on board computer. An optional external computer for higher powered capabilities will be an option.

I took a look at the RW foundations library. Is there an architectural plan in place? It appears everything is in one executable, which seems odd for a high-tech robot (especially with the idea of splitting the workload between two computers). ROS uses a pub/sub modular model and comes with a simulator, which may be better for a distributed dev environment (we won't all have a completed robot at home). But, I haven't used ROS much, so I can't speak with certainty. I'll have to make a proof-of-concept. >>20234 >make usable arms/legs based of Aigis Like unpowered doll arms/legs? Do you recommend a particular CAD software? (It's been a while since I last CAD modeled.)

>>20264 Unpowered doll arms and legs would be a good start. Experimenting to find a body that looks good in practice will be a good start. Then we can figure out how to actuate her.

>>20234 >We'll find a way to fit things in. If they don't our backpack or butt as Richardo wanted :^) Haha, I'm sure we will Kiwi. :^) >>20264 >I took a look at the RW foundations library. Is there an architectural plan in place? It appears everything is in one executable, which seems odd for a high-tech robot (especially with the idea of splitting the workload between two computers). The reality will likely require us to use many computational devices one our midterm goals. For now, just whatever DoF that Kiwi directs us to. But yes there aren't any actual 'deliverables' in that yet, just one smol utility tool (eventually) for our waifus to track IBs for us -- and a fairly sweeping set of stubs to begin crystalizing the architectural framework. It's all quite-unfinished for now, but several key advances (well, for me anyway) are already in place and working. AMA.

What about organizing the RW foundations modules into something like centers of a brain? It would intuitively separate the different functions of the software: -Executive Function -Situational awareness ("Where am I?") -Decision Making ("What should I do?") -Memory -Short-term Awareness / Self-awareness -Skills ("How should I do it?" - cooking, cleaning, etc) -Sensory -Tactile -Auditory -visual -Motor control -Gross (Arms/legs) -Fine (Grasping, fingers) -Expression (Face, lights, audio) -Limbic/Lizard brain -Electrical systems, Battery charging, audio/display drivers, anything that a non-engineer shouldn't have to touch For example, this would separate hearsay.cpp into separate speech synthesis and speech recognition modules. They're two different technologies/brain functions that don't have to be entangled in one file. Kind of like the Unix philosophy. Gross and fine motor controls could be multithreaded to run simultaneously, executive functions could be offloaded to an AI, hand.cpp could be re-implemented as a wrapper for Tactile senses and Fine motor control, cooking and cleaning would be high-level scripts that run on top of these generic functions... I think it's good for cutting the elephant into bite-size pieces. IMO the end goal should be a system that can be easily reconfigured for different designs and use cases (bipedal humanoids, tank centaurs, etc). If that ever conflicts with optimizing for the ultimate humanoid robowaifu, we'll cross that bridge when we get there. >>20277 >several key advances (well, for me anyway) are already in place and working. AMA. What are they?

>>20295 Interesting questions, Anon. Let me think about this for a while. Maybe other Anons have ideas here?

>>20295 >Subtasks for her mind Could someone with better AI knowledge confirm whether this is a good way of splitting her mental development into? I think it's close to a good idea.

>>20337 No one ever build a human-like AI. The basic idea sounds reasonable.

>>20234 Do you have dimensional drawings for the leg interface on the hips? I should be starting on the legs Soon(TM)

>>20539 Here's the current torso. 38.2 cm tall, 156 cm at her bust, and 174 cm at the widest. Heavily modified it to make her easier to print and lower mass for a minimum viable torso for a 150 cm waifu. Her legs will need to be longer to make up for it and reach 150 cm final height. There are three mounting options for her limbs. Staring with bare shoulders which are slanted 80 degrees and hips slanted 60 degrees.6 cm cylinders on her shoulders and hips for a flat surface to embed the limbs interface. There's a 9 cm cylinder option as well. I personally prefer the 6 cm option as it looks nice while providing an easy surface to work with. Picrel for reference. Can send an STL or OBJ of your preferred torso to work with if you want.

>>20545 That's looking really good now Kiwi.

>>20545 >Can send an STL or OBJ of your preferred torso to work with if you want. Are you sculpting this or using CAD? CAD should allow you to export a STEP file (more dimensionally accurate, IIRC)

>>20546 Thanks! >>20552 I use DesignSpark Mechanical, Autodesk Meshmixer, and Blender. None of which natively exports STEP and STL/OBJ are accurate.

Leg, version 0.1

>>20567 That's an interesting design. Could you explain what is going on? How does this leg work?

>>20606 >What's going on? It's just a single piece, no joints or anything. (Hence version 0.1) `I haven't done CAD in years so I made the simplest design that would technically work.

>>20610 I banged it out in a single night, plz no bully

>>20611 I didn't mean to come off as rude, the design just looks different compared to anything I've seen before so, it's interesting. I like that you kept it round and almost organic looking.

>>20612 You weren't rude, I just imagined the tone as >This looks whack but I'm gonna give anon the benefit of the doubt in case there's some kind of 4d chess engineering going on. >I like that you kept it round and almost organic looking. 'Twas a happy accident. I just kinda made it up as I went along.

WIP of leg version 2. The knee is going to be a hinge (somewhat like a gopro mount) because a knee doesn't need lateral movement. The foot will be a ball joint. >inb4 the joint should be rounded, not square Plz understand, I am not a pro. Will fix it later. Also including .stl of version 01

>>20731 >>20732 Thanks Anon, nice work! I imagine there will need to be some definition of joint interfaces worked out here eventually. Kiwi probably already has some ideas on this matter. Thanks for the dropping the file directly here on the board too (since it's now archived for all). Please keep up your good work! :^) >=== -prose edit

She can't be made entirely from TPU. So, which parts should be soft? I'm thinking her breast, butt, and hands should be soft. Should other parts be made soft? Studying Danny Choo's Smart Dolls has been elightening. Highly recommend others look into them. https://dannychoo.com/archive/en/posts/smart-doll-design

>>22345 >Should other parts be made soft? Yes, the face & vagoo region.

>>22347 Do you any ideas for achieving this? I'm thinking of a basic skull and skin

>>22348 Could you fashion some kind of durable foam to go over the hard surfaces?

Please help me choose a head. Decided to just modify a doll body that when scaled up fits a womens size S. Modeling her myself was taking too long. Now I need to settle on a head, the one I was using (labeled 5) was unsettling for some. Strongly considering the Smart Doll head that's free to use. https://shop.smartdoll.jp/collections/filter-learn/products/smart-doll-free-3d-files-stl

>>22886 >>22887 >Please help me choose a head. Why? The first one for your prototype or own robowaifu? Or for everyone? Won't you use a connector which allows to replace it later? Also, what would possibly be wrong with her? Looks nice.

>>22889 For the prototype. She needs to have mass market appeal to help advance our cause through increased mindshare. The face is what matters most to people. >What's wrong with her? The face I made makes some people uncomfortable. >Customization via connector Still in the cards, a strong default is good for marketing.

>>22886 >Please help me choose a head. We trust your judgment Kiwi. You understand character appeal well enough AFAICT. Just make a decision and go with it, would be my advice Anon. And even if you want to change it later, well this is one of the great unique advantages of robowaifus! :^) >>22893 >She needs to have mass market appeal to help advance our cause through increased mindshare. The face is what matters most to people. I agree.

>>22894 the thing about being early is that the quality is not as important and the competition not as intense. Which is why we should crunch a little bit...

>>22935 >the thing about being early is that the quality is not as important and the competition not as intense. Which is why we should crunch a little bit... That's certainly true in the case of our interests r/n, AFAICT Anon. Mind expanding on 'crunch a little' please?

>>22936 codeword for stop talking and do something even if its kludge

>>22938 Oh. Haha got it. So, we're looking forward to your crunch-mode artifacts here for the board, Anon. I'm currently already in double-crunch-mode in my own life r/n. :^)

>>22942 That's fine chobitsu, you go be busy some of us are going to put in some work into this and make money multipliers out of it.

>>22945 >put in some work into this and make money multipliers out of it. Excellent. That's the very thing I desire for this community. Please keep us all abreast of your progress Anon! Cheers. :^)

>>22946 thank you, maybe i was a little rude sorry about that...

>>22947 No worries Anon, didn't really even notice heh. :^)

I'm going to have to upgrade my computer...

>>22960 oh that's the pic i meant to post the video

>>22960 >>22961 Neat! What are we looking at here, Anon?

>>22972 I imported the waifu model into blender and pieced it together with the robot hands but blender is unusable right now despite the fact I have an rtx 3600 and 32 gb of ram.

>>22973 I just order 32 more gb of ram let's see if that fixes it...

>>22973 I see. Hmm, maybe you can use a 'proxy mesh' technique where you work with a much lower-res mesh for implementing animation work. What are you doing to it in Blender may I ask? >>22976 Nice. I hope that helps you Anon.

>>22973 >>22976 >64 GB of RAM That's a beast of a PC you got there. Hopefully it works out and you can render your model in Blender.

>>22983 thank you, I'm going to have to call a non robo waifu technician cause now my computer won't turn on and I need a second opinion haha...

>>22992 Couple of questions Anon. -Did you choose a memory stick matched closely with your current one? -Have you checked your BIOS setup? I hope you solve the issues Anon.

>>22997 I tried to pick the same brand and have them both be ddr4, I'm not sure if they're the exact same speed but that shouldn't be a problem... I thought they were the exact thing I got last time...

>>23000 wow so i was putting the ram backwards, lol. Then I had to change the slot order but whatever. The guy didn't show up I had to fix it myself. This waifu technician right here doesn't need a pc technician haha. Anyways time to get back to what I was doing on blender.

>>23001 So I think I got autorig pro to work but it still chokes up. This is ridiculous. That blender add on should not have been written in python ff.

>>23000 >>23001 >>23002 GG. Please keep us updated on your progress!

>>23003 thank you. I'll be posting the video when its done ;)

>>23008 this is taking longer than usual because the model has so many polygons that it makes my computer freeze whenever I try to do anything with it. I already decimated it down to less than a million polygons but its still too much.

>>23033 I'm sure you'll figure it out Anon. Just keep moving forward! :^)

I've thought about it and I think I will focus on the AI first. I will make it so you can talk to a phone and it answers back. Then the hand. You guys got the rest right? right? I'm trying this model right here: https://huggingface.co/KoboldAI/PPO_Pygway-6b-Mix/tree/main Its not cute but perfection is the enemy of progress as they say.

>>23037 >You guys got the rest right? right? Lol. I suppose that depends on what you actually mean by """the rest""" Anon. :^) A Homo Deus? Of course not, no. Comfy simulacrums of idealized female companions ensconced within reasonably-functional robowaifu frames? Probably so given enough time & effort. And your own efforts may in fact help contribute towards that end-goal here Anon, so work hard! Cheers.

>>23008 alright here is the waifu from the maidcom project dancing. https://youtu.be/se5gcniC1-Y

>>23091 Nice. Is this for simulation later?

>>23111 It can be used to visualize the waifu doing different things...

>>23091 Thanks Anon! Glad you worked things out. Look forward to your future progress with this. Cheers. :^)

Starting to get the model the way I want it. Much smoother and lower poly. Still optimizing for printability and actuation.

>>23222 >digits Her model is coming right along now, Kiwi. Good job! :^)

>>23222 Kiwi you told me to slice a hand that is different from the one on the site. Can you please share the hand file.

working on that hand outer shell for now

>>23235 Oh boy you guys are going to make this thing difficult from start to finish aren't you? I'm trying to help and then I'm told not to help.

>>23236 >and then I'm told not to help. <[citation needed] :^)

>>23235 I'm curious why the seams are rendering with a jagged edge like that Anon. Any idea?

>>23238 Because polygons are triangles. When you delete vertices you're left with pointy triangles. :^)

>>23391 Neat. Thanks.

>>23393 New one, going to be Copyleft once finished.