/robowaifu/ - DIY Robot Wives

Advancing robotics to a point where anime catgrill meidos in tiny miniskirts are a reality.

The Mongolian Tugrik has recovered its original value thanks to clever trade agreements facilitated by Ukhnaagiin Khürelsükh throat singing at Xi Jinping.

The website will stay a LynxChan instance. Thanks for flying AlogSpace! --robi

Max message length: 6144

Drag files to upload or
click here to select them

Maximum 5 files / Maximum size: 20.00 MB

More

(used to delete files and postings)


Knowing more than 100% of what we knew the moment before! Go beyond! Plus! Ultra!


Open file (363.25 KB 1027x1874 MaidComRef.png)
MaidCom Development Kiwi 03/16/2022 (Wed) 23:30:40 No.15630
Welcome to the /robowaifu/ board's project. Together, we will engineer a modular robot that will serve and provide companionship to their Anon faithfully. See picrel for details on the current design. This robot will begin with a basic maid robot then move forward towards more capable robots with functionality approaching Chii/2B/Dorothy. First goal is to have a meter tall robot which functions as a mobile server bearing an appearance that approximates her owners waifu. 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.
Look forward to seeing all the great work on MaidCom, Kiwi!
Open file (70.12 KB 500x392 good_girl_headpats.png)
>>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!! :^)
Open file (177.95 KB 561x1366 MaidCom1.png)
>>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.
Open file (186.38 KB 1000x1000 Untitled2_20220319175859.png)
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
Edited last time by Chobitsu on 03/22/2022 (Tue) 09:10:50.
>>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
Edited last time by Chobitsu on 03/25/2022 (Fri) 08:02:24.
>>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.
Open file (786.58 KB 500x250 1649233070266.gif)
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
Edited last time by Chobitsu on 04/09/2022 (Sat) 18:32:26.
Open file (409.35 KB 1610x2048 20220413_192800.jpg)
Open file (352.48 KB 1470x2048 20220413_192827.jpg)
Open file (363.85 KB 1391x2048 20220413_193119.jpg)
Some interesting designs to help inspire Meta Ronin and Madtrickster in their designs for MaidCom
Open file (49.41 KB 451x634 GITS-Fuchikoma.jpg)
Open file (20.25 KB 640x337 Tachikoma-read-books.jpg)
>>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.
>>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! :^)
Open file (142.54 KB 1024x768 WaifuInATachikoma.jpg)
>>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.
Open file (186.48 KB 1453x1500 71Pn5HgzTuL._AC_SL1500_.jpg)
Open file (137.64 KB 350x350 carlos.png)
>>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.
Open file (183.48 KB 1453x1500 71JMek5TvLS._AC_SL1500_.jpg)
>>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
Edited last time by Chobitsu on 04/23/2022 (Sat) 13:52:11.
>>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.
Open file (143.93 KB 600x900 FQt3bOMVcAMrW9f.jpeg)
>>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
Edited last time by Chobitsu on 04/28/2022 (Thu) 19:45:03.
>>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
Open file (79.63 KB 680x524 Safety.png)
>>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
Edited last time by Chobitsu on 04/30/2022 (Sat) 18:02:51.
>>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
Edited last time by Chobitsu on 04/30/2022 (Sat) 21:48:35.
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
Edited last time by Chobitsu on 05/02/2022 (Mon) 09:27:41.
>>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 :^)
Edited last time by Chobitsu on 05/02/2022 (Mon) 17:00:27.
Open file (543.66 KB 1107x943 wip.png)
>>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
Edited last time by Chobitsu on 05/04/2022 (Wed) 12:10:13.
>>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! :^)
Open file (116.47 KB 679x679 ChickenHex.jpg)
>>16109 https://www.amazon.com/MAPORCH-Upgraded-Plastic-Hexagonal-Gardening/dp/B0936GX5JB/ref=asc_df_B0936GX5JB/?tag=hyprod-20&linkCode=df0&hvadid=533302654497&hvpos=&hvnetw=g&hvrand=10175299579296854402&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9030805&hvtargid=pla-1382615920529&th=1 ZW5jcnlwdGVkUXVhbGlmaWVyPUExMlBMM0ZLMEZUWkpZJmVuY3J5cHRlZElkPUEwOTE2Mjk1MkpPMkpENFo5Mk5KTyZlbmNyeXB0ZWRBZElkPUEwNDg1ODU5Njk4NFBMN0k1Skk2JndpZGdldE5hbWU9c3BfYXRmJmFjdGlvbj1jbGlja1JlZGlyZWN0JmRvTm90TG9nQ2xpY2s9dHJ1ZQ Here's a couple of examples, gardening mesh seems to be the best bet based on material properties. I'd appreciate it if you would endeavor to sketch your ideas out. Or provide images that are related to your conceptual idea. Would help everyone on the project better understand.
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.
Open file (360.48 KB 1088x1193 doodle.png)
>>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
Edited last time by Chobitsu on 05/08/2022 (Sun) 23:11:06.
>>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
Edited last time by Chobitsu on 05/09/2022 (Mon) 01:53:26.
>>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.
Open file (2.51 MB 4160x3120 20220508_220334.jpg)
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
Edited last time by Chobitsu on 05/09/2022 (Mon) 19:24:07.
Open file (90.65 KB 679x679 LargerHoles.jpg)
>>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.
Open file (259.28 KB 972x1600 MeshWoman.jpg)
>>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
Edited last time by Chobitsu on 05/09/2022 (Mon) 20:38:22.
Open file (309.76 KB 3000x1000 VariationCutting.jpg)
>>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
Edited last time by Chobitsu on 05/10/2022 (Tue) 00:53:39.
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 :^)
Open file (13.63 KB 1494x325 chart.png)
(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?
Open file (13.01 KB 145x320 bustle.jpg)
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.
Open file (8.32 KB 508x675 laptop rack.png)
Open file (89.28 KB 700x972 aunt fanny.jpg)
>>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.
Open file (48.24 KB 658x885 drossel_06_wxp.jpg)
>>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.
Open file (80.24 KB 1822x861 chart.png)
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. :^)
Open file (1.39 MB 1500x1063 14744373_p0.jpg)
>>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.
Open file (126.31 KB 486x648 standing monitor.jpg)
>>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.
Open file (249.83 KB 1000x1397 FluffyTail.jpeg)
Open file (218.94 KB 3661x2587 sharkMaid.jpg)
>>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.
Open file (238.22 KB 1795x1030 PXL_20220512_221908673.jpg)
Open file (301.17 KB 2283x1467 PXL_20220512_221840781.jpg)
>>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.
Open file (558.79 KB 868x1228 1622835214405-1.jpg)
>>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
Open file (66.96 KB 496x467 The Ultimate fucker.jpg)
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
Edited last time by Chobitsu on 05/16/2022 (Mon) 00:53:40.
>>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.
Open file (316.68 KB 1000x1781 1652433199392 (1).jpg)
Open file (104.33 KB 220x165 220px-Rocker_bogie.gif)
Open file (230.81 KB 1440x1800 1652411619583.jpg)
>>16228 A foam padding would work well. Especially with an outer fabric skin like picrel 1. >>16231 Adding you to the software team, thanks for your contribution. >>16251 >>16252 Thanks for your check in. Both I and Chobitsu have started brainstorming ways for a backpack to work. Which we've been referring to as a Rondoseru as they are the cutest variant of backpack (to me). >>16258 Found it on 4chins, no idea where they found it. Those are linear actuators used to adjust her height. I recently came across a tutorial for designing your own which could be helpful for us. https://youtu.be/-C9e--3nvro MaSiRo robots are built for working in cafe's so they have fundamentally different needs. Though, more points of contact are better for stability, rocker bogie mechansims being a good example. I'm striving to keep her electronics as simple as possible. Part of the reason for the 5/6 connector being developed is to ensure clean simple wiring. I plan to post more infographics to help our mission. >>16259 We were very recently talking about using her tail to help with this dilemma. I'll lower her backpack expansion area to the lowest it can go as you're correct about how the thrown mass would affect her dynamics. Squaring this backpack expansion with her lightweight frame goals is no simple task. I'd appreciate any and all suggestions. >>16260 Bellows can be 3D printed though, I'm just going to use stretchy fabric and good engineering to prevent pinching.
>>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
Edited last time by Chobitsu on 05/16/2022 (Mon) 07:30:45.
Open file (130.77 KB 1280x719 IMG_7448.jpg)
Open file (91.53 KB 628x838 IMG_7423.JPG)
Open file (82.67 KB 628x628 IMG_7460.JPG)
>>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.
Open file (112.06 KB 1861x868 wopr.jpg)
>>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
Edited last time by Chobitsu on 05/18/2022 (Wed) 02:26:38.
>>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.
>>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
Open file (75.86 KB 500x500 105670.jpg)
>>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
Edited last time by Chobitsu on 05/24/2022 (Tue) 11:37:08.
>>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)
Open file (149.69 KB 634x1535 compositeic1.jpg)
>>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.

Report/Delete/Moderation Forms
Delete
Report