/robowaifu/ - Modular Platform, "Assistant": Wheelchair-style robot base to jumpstart projects

Name
Subject
E-mail
Message	Max message length: 6144
Files	Drag files to upload or click here to select them Maximum 5 files / Maximum size: 20.00 MB

Spoiler images
Password	(used to delete files and postings)
Use bypass

Modular Platform, "Assistant": Wheelchair-style robot base to jumpstart projects Lin 08/21/2023 (Mon) 01:14:26 No.24744

Lord knows I'm terrible at these writeups, so I'd recommend glancing at the attached CAD screenshots to get a quick idea of what this project is about-- on that note, most of this post will be copy/pasted stuff from the design docs, mainly stuff that won't change, so apologies in advance. Long story short, I've talked to a bunch of guys, both on the chans and elsewhere, who have some great ideas but aren't sure where/how to get started. My hope is that a (comparatively) simple, modular base that provides power, movement, and basic sensor data will let them get started on their own project without having to re-invent the wheel (and get nerd-sniped in the process.) # Brief The purpose of this platform is to establish a generalized "blueprint" of a (comparatively) cheap, human-scale "modular base platform" that can be built by a capable layman and maintained by a hobo, while supporting and powering any "robo payload" <= 75lbs, 5kW. Emphasis is placed on all parts being readily available or substitutable, and could conceivably be built from salvage at near zero cost (or in the face of malicious sales restriction), excepting digital controllers. Durability has also been prioritized, with over-engineered tolerances and (optional) bilateral redundancy for everything but the drive motors. Sacrifices have been made to accommodate this vision (primarily weight, though to a lesser extent, performance), and Builders with access to specialized tools or a higher budget will likely want to tweak the design (ex. using aluminum T-Slot instead of right-angle stock, welds in place of frame bolts, etc.) The design is purposefully made to resemble (and, if necessary, function as) a wheelchair (see reasoning below.) ## Project Budget Target Cost: $2,500 USD-2023 with new, mid-grade parts, excepting computer/processor. (realistically, I expect this to be closer to $3,500 in the short term, until people more clever than I improve some of the design's weaknesses/sacrifices) ## Prototype Info - Prototype Budget: $10,000 USD-2023 - (I have access to specialized equipment and labor (at a price), including a commercial 3D printer, 5-axis mill, welding, lifts, etc.) - First design revision expected by the new year (2024). Physical construction to begin Spring 2024. Basic electronic control system, motor/BMS interface to be somewhat complete between January and (Spring) 2024. # Requirements & Purpose - At bare minimum, the Robo shall be physically capable of navigating any ADA-compliant environment. - Robo shall be capable of interacting with standard human features-- counter-tops, tables, eventually doors, etc. - This necessitates vertical mobility, as many counters expect a human's "waist height" to be @36in - Should be constructible from either imperial or metric materials as available, with the standard being 25mm/1in framing stock. - Tolerances should be excessive, and all components that cannot be handmade (sprockets, chains, gears, wheels, batteries, etc.) should be interchangeable with off-the-shell parts (ex. bike/car parts) - The "baseline model" should require no specialized tools or skills beyond the grasp of a determined autist. - It will, however, require basic tools like a drill with specialized bits, soldering iron, an appropriate saw, angle grinder, and a lot of time. - Should be movable, even when inactive/broken, by a single adult of reasonable fitness. - Assumes novice male deadlift of ~173lbs (up to 220lb would be reasonable with minimal training), and the ability to raise+carry 75lbs (Payload) near shoulder level. - Should be transportable within compact vehicles, not to require more than 1 minute to restore to a mobile configuration, with no tools. - We assume a back-seat forward distance of at least 18in (upper minimum 20in), and two non-occupied passenger seats total (front or back, need not be adjacent). - Should attempt to (technically) remain within the legal bounds of a plausible "mobility aid device", "prosthetic", etc. - Not a particular stretch, as the design's default configuration looks quite similar to a wheelchair, can be occupied by replacing the Mount with a seat, and is big enough to carry a human (and powerful enough, though expect significantly decreased speed and runtime) - An added, if unlikely benefit is that in may help public acceptance due to a less-threatening, more harmless appearance. - A fully capable model (to spec), with a complete payload (~75lbs), should not exceed 250lbs, ie, the lower end of (architectural) transient load limits. - Note that static weight is an entirely different measure, and "parking" your Robo should NOT be done just anywhere. Find somewhere made to carry a static load (kitchens, baths, bedrooms with a safe mount, etc.) And, of course, check building codes in your area, obey laws, etc. - Has space and hardpoints for (optional) safety mechanisms (for now, I'm simply designing with this "in mind") - Ideally, this would include something to avoid running over unseen objects, be it LIDAR, ultrasonic, electrostatic, etc. - Lower-hanging fruit to prevent easily-avoidable accidents, such as bumpers and chain/gear shrouds, shall be included in the initial design. - In case of catastrophic failures, the Platform should be designed to sacrifice itself to prevent the Payload being damaged. - Non-catastrophic failures should ideally not impact Robo capabilities (immediately) in the case of a system with redundancy, or engage the fail-safes otherwise. # Final Remarks > Career engineers will probably cringe at the... /misuse/ of materials, such as bolts in a force-transfer or structural role (Bridgehead Rotation and Payload Locking Clips, respectively). (PS don't look a the scrap Bridge Clutch schematic) This entire project is built on the idea that "Something real that theoretically works is better than something theoretical that really (might) work." The goal is a design that can realistically be built by anyone capable, out of parts they save up for and salvage, so they can build something to improve their own lives.

Lin 08/21/2023 (Mon) 01:55:55 No.24745

Attached are a few files that didn't fit in the OP (see below for comments on them), as well as answers to a few questions that will probably come up: >Where are the (motor supports | secondary wheels | wheel sprocket cassettes | wheelchair back | ...) This design was done in a paper-pencil notebook, with motion studies and CAD stuff done to prove out the more risky/uncertain parts of the design (areas where I might have miscalculated, or overlooked something intersecting, etc.) Anyway, my 1st priority was to prove out all the parts which, if incorrect, would torpedo my design. At this point, all those issues have been proven out, and no issues should be design-breaking, so I'm entering the rest into CAD software in my free time. If you're worried I overlooked something, by all means, mention it, but if you're worried that the design looks a little bare, that's intentional at the moment >gibs me dem CAD files bruv Currently, the license I'm using is kinda borrowed, so distributing the files is a no-go. I'm looking into both acquiring my own license for the project, exporting into a 3rd part format, etc. When the time comes, I'll have a full repo with both the DDs, studies, and CAD files on github. re: the attached CAD images >Drive Platform Mainly just attached to let you mentally cut the design in half and visualize the Sled/Bridge separately in the frontal and oblique views. >Bridge cross-section Meant to show the viability of building from scrap/off the shelf parts. As you can see, bolts are repurposed both as the Payload/Bridgehead rotator (top center) and locking pin(it's ground+chopped, but top center-right). Holding the Bridge and Bridgehead together is a pipe nipple, and the slide "bearing" is simply a sheet of PTFE, but can be substituted with lubricated acrylic. The Bridgehead shafts (upper left+right) is just pipe/metal rod stock with a side ground (D-profile is the everyman option, though keyshaft is preferred for heavier payloads), and the sprocket attached to either one is just a #40 16t off a bike. Needless to say, the chains between top and bottom are both just bike chains, and the Bridge Clutches (directly attached to the vertical Bridge frame), while ideally made with industrial inner-outer gears, can be built out of two <3in sprockets, 4 sheets of aluminum, a bunch of bolts, and 4 hoseclamps. Janky, you say? Hell yeah. And they still exhibit a sheer failure weight of 150lbs @16in, a 200% tolerance for a 75lb payload, even when the bolts are simulated as "compromised steel" (rusted/cheap) Anyway, the point of all that is just to show that even if you don't have a big budget, or you're just a normal guy without machining/engineering experience, that's OK, and you're still perfectly capable of building a robot. re: the OP, feel free to ask any questions you might have. and I figure I'll post updates as I finish em, at least weekly.

Robowaifu Technician 08/21/2023 (Mon) 05:07:05 No.24748

> Great to see someone who obviously has actual engineering experience propose a design with fairly realistic capabilities and budget here. Too many dreamers think they can make a humanoid robot with moving arms and legs, with no prior experience, for $500. I think it's worth noting (just in case you haven't already seen) that MaSiRo Project is moving away from rotary joints to lift the upper body to a more robust linear stage (see pic). They also appear to be switching from aluminum extrusion to steel tubing.

Chobitsu Board owner 08/21/2023 (Mon) 09:31:13 No.24756

>>24744 Hello Lin, welcome! Very nice OP, BTW. :^) As a complement to your project thread, we also have a Wheelchair Waifus thread (>>2983). Please have a good look around the entire board as well. Looking forward to seeing your project's progress, Anon. Cheers! :^) >>24748 >Too many dreamers think they can make a humanoid robot with moving arms and legs, with no prior experience, for $500. That would actually be an absolutely excellent outcome Anon! :^) >=== -minor edit

Edited last time by Chobitsu on 08/21/2023 (Mon) 10:08:56.

peteblank 08/21/2023 (Mon) 09:43:03 No.24757

You guys are completely neglecting the sex aspect of the waifu. Are you monks?

Chobitsu 08/21/2023 (Mon) 10:13:30 No.24760

>>24757 Actually we have a dedicated thread for this topic Pete, as you should be well-aware (>>419). The >tl;dr is that we aren't trying to create so-called sexbots here, Anon. You can already find very expensive varieties of them today, quite apart from us. We here on /robowaifu/ are firstly concerned with devising opensauce waifus (primarily of the robotic variety), that will offer good & wholesome companionship for Anon. Most will want snu-snu capabilities added on as well, ofc. :^) >=== -minor edit

Edited last time by Chobitsu on 08/21/2023 (Mon) 10:20:14.

Lin 08/22/2023 (Tue) 03:17:44 No.24780

>>24748 Aye, I've had a couple people mention the MaSiRo project now, looks like I'll be doing some reading to catch up on that. Was your picrel of their current design? I only glanced thru their site, but in seems like they use an LA-compound lever mechanism instead of a pure linear one... Funny enough, my original design used a linear actuator attached to the Bridge's midpoint, forming a class III lever for the Payload's elevation. I had a spreadsheet with the force requirements worked out somewhere too, 1st picrel (and no, the 21k lbf wasn't a math error-- like I mention later, terrible mechanical [dis]advantage) Anyway, I ultimately decided against it for two reasons: - Just wasn't gonna fit (main reason). My design absolutely needed the ability to control its CoM and balance itself on the fly, so the entire Sled/battery-carriage area had to be clear of obstruction along dZ. And, while I could get required stroke distance down to 8", cheaper (<$1k) LAs are generally (2 * $stroke + ~6") long, which meant I'd need an LA over 20" long, on a Platform that was... 20" long. Plus, putting an LA only a few inches below its fulcrum makes for a ridiculous mechanical disadvantage. - LAs are SLOW. I had transition from "sitting" -> "standing" within 1.5 seconds, upper bound 3s, while an LA would take well over 10s, and that was advertised (unloaded) time. A rotational elevation mechanism came with its own challenges, namely exerting over 120 N*m of torque (which is why I have a 3"+ hub/"clutch" attached to the shaft, with steel force-transfer bars running the length of the Bridge). I played around with stuff like an assist spring or a "boost actuator", but in the end, I went with the kludge-like "just shim it up a couple inches so you never have to deal with worst-case forces in the first place" (see Bridge torque proof graph in OP) Well, it started out as a kludge, but it turned out that I needed the extra space on the Drive Platform anyway, so, uh, happy little accidents, right? >switched to steel framing I'm a bit curious about that one. Although my design is agnostic to frame materials, I'll be using as much aluminum as possible in my prototype, cause I want to make sure all the stuff can be made with hand tools (and drilling >1/2" in steel is gonna be a bad day even if you do have nicer tools.) Plus, my design is already overweight given a full set of batteries, so...

Lin 08/22/2023 (Tue) 04:14:50 No.24781

>>24757 >he can't bust one out to 1st picrel alone ngmi bro Jokes aside, this is a "robot base (platform)", basically a fancy wheelchair with an elevator and a *lot* of batteries. The bits you're thinking of would be a part of the "Payload", which could be anything from an industrial robotic arm to a humanoid doll from the thighs/hips-up. I'll try to get the mounting assembly modeled next weekend, but to give you an idea, it's a set of drop'n'lock "clips" that will center and anchor any compatible Payload you put on top of it. As for what that Payload looks like...? Well, think 2nd picrel, if you want to shoot for the moon. Anyway, I can't speak for any other projects, but I doubt that neglect is purposeful. If I had to explain it, in my case it's more: "Designing+building the Payload will be many times more difficult than the Base, and almost all the parts will have to be custom printed/machined, so it will be much slower and easier to get discouraged. To prevent that, the project should be structured to make each milestone as rewarding as possible." For example, if I build a base/movement platform beforehand: "cool, I have a robotic arm that can pick up a tennis ball" becomes "Hell yeah, now my robot brings me beers while I work!" which is way easier to psyche myself up for imo, managing motivation or "morale" is every bit as important as more obvious quantities like "budget" or "timeline", and just like you might have to delay certain goals to match up with your budget, you might also tweak the order you attack problems in so that you keep up a fairly constant stream of "success".

Robowaifu Technician 08/24/2023 (Thu) 00:22:50 No.24845

>>24780 >Aye, I've had a couple people mention the MaSiRo project now, looks like I'll be doing some reading to catch up on that. Was your picrel of their current design? I only glanced thru their site, but in seems like they use an LA-compound lever mechanism instead of a pure linear one... The mechanism you saw is for their current iteration. They're designing a second revision MaSiRo to fix the many issues that plague the current one - It breaks down often due to being built relatively cheaply and with hobby-grade components. This new design is what I posted (source: A_says on twitter) FWIW, the linear actuator alone for their new version - Oriental Motor EACM6RD30AZMK - is $1300 usd PLUS another $550 for matching driver (kaching!). And it's not even strong enough to lift your beefy 35 KG payload.

NoidoDev ##eCt7e4 08/25/2023 (Fri) 00:37:37 No.24869

>>24744 Great start, I'm just answering so late because it's quite a lot. > ~173lbs (up to 220lb would be reasonable with minimal training), and the ability to raise+carry 75lbs (Payload) For non-muricans: 78-100kg and 34kg >>24780 >but in seems like they use an LA-compound lever mechanism instead of a pure linear one... Well, if I understand correctly this is about bowing. Related: >>2983

Lin 08/28/2023 (Mon) 01:35:12 No.24967

>>24744 This week, I narrowed down the Bridge (“legs”) to my original design’s specs, which necessitated narrowing the Drive motor’s mounting plate, shifting the motors back, etc. One bonus of this is that the Drive Mounting Faceplate can now be constructed out of two 1/8in aluminum plates sandwiched together, meaning this part can be constructed with hand tools and no longer needs to be milled. I could go into more detail, but it’s easier for me (and less boring for you) to just post a gif swapping between top-down views. Long story short, it’s down from 12+2in to 10+2in, half-motivated by aesthetics and the other half structural limitations (below) Load-bearing simulations on the Bridge revealed that a full 75lb Payload could cause the support beams to deflect by more than the ~1.5mm clearance during elevation or while carrying a transient load, binding the driveshaft and giving our poor robot a *very* bad day. This was addressed by inserting (hardened) 5mm 1055-steel rods into the support beams (only costs $20, surprisingly), as well as narrowing the Bridge. Minor Bridge Axle deflection was noted as well (in the middle); although not an immediate concern, to reduce wear long-term, I added an _optional_ set of bearings above the Drive Motor mounts. Costs about $50 in total, though it makes the mount more robust. [center of 2nd picrel) Other main bit of progress was mounting the Sled rails and designing the motor mount—as usual, everything with this prototype is overkill, so I opted for a 2HP motor that could allow the Sled to climb beyond a 45deg angle (my vision was to allow a robot to “swap out” its own battery carriage/Sled), moving over 1ft/second. For more sane terrain (ADA spec++, so <=7.5deg), a 300W or better motor @ 100-200RPM should work fine. I’m using a 20t -> 16t #25 sprockets/chain, but with the smaller chain, you should be able to fit up to a 34t -> 10t reduction if you need to reduce your motor’s RPM. Decisions I’ll need to make from here (as always, input is welcome): > should I go with the wider Bridge Axle (less flexible drive train gearing and more wasted space, but keeps all pressure on the outer Platform frame), or bring the Bridge inward to the support beams (which puts more stress on the Platform’s inner frame) (so if you were wondering why the Bridge Axle had 6 bearings on it atm, that’s why, even I wouldn’t over-engineer something *that* much… probably) I’m leaning towards the narrower support-beam option, though that’s more for aesthetic than practical reasons. I may just retain both sets of bearings in the design, then see if I can remove the outer ones on the physical prototype. > I can widen the Sled/battery carriage by 2/3in (or less), or leave it as-is. I’m redesigning the Sled’s frame to allow for wider boat batteries, and widening it by even 1/2in would save a lot of trouble (and potential design sacrifices), but could come back to bite me if I run into issues with the wheel’s dynamic gearing (sprocket cassette + bike derailleur) needing more working room. Widening the Sled could also make the robot more vulnerable to extreme shocks (earthquake-tier), as the Sled’s widened rails would only need to come 1/8in out of alignment to interfere with the drive sprocket, so maybe not *that* much of a concern. [3rd picrel] I’m stuck 50/50 on this, ended up ordering the sprocket cassette I had in mind so I can model it (bike part manufacturers, unlike industrial ones, don’t share their schematics—go figure /s) and hopefully make a more informed decision. Didn’t get around to modeling the locking-clip systems, like I’d hoped-- sorry, man. >>24781

Lin 08/28/2023 (Mon) 02:52:19 No.24969

>>24845 Thanks for the twitter handle, I was surprised to see a few other hobby roboticists in the comments-- we're something of an endangered species, especially with this economy lmao. I wonder if it's more popular, or at least socially acceptable, in Japan Their choice of actuator is a bit curious-- seems like they went with an industrial, super-precise one, and two of em at that? I recall seeing several actuators that could push 100s to a couple 1000lbf for under $500. Mind you, they were bulky, ugly, and intended for solar farms and the like, and the machined aluminum cases in MaSiRo's new design *are* sexy as hell, but RIP that guy's pocketbook. ... I say, as I nervously glance at my own design's BOM with almost $3k in motors... Well, on second though, can't put a price tag on passion, right? Man, now I wish I spoke Japanese, I wanna ask the guy why he's using a pneumatic spring to reduce load on the actuators, instead of a braking mechanism like the one I opted for. Hopefully I didn't overlook something... >>24869 Ah, that explains it! That part of the design looked quite purposeful, like the compound lever was part of their requirements, but I couldn't figure out why. It is quite striking how three projects (Maidcom, MaSiRo, and mine), with no knowledge of the others, ended up heading in (mostly) the same directions... "convergent evolution" for the robotics world, I suppose. Admittedly, my design being more "industrial" in purpose (was designed to act as an ad-hoc vehicle, handle rural terrain, and carry a couple hundred extra lbs) probably accounts for most of the differences, otherwise I'd probably have come up with something much more similar.

NoidoDev ##eCt7e4 08/28/2023 (Mon) 14:16:44 No.24992

>>24969 >seems like they went with an industrial, super-precise one I don't get why people are doing this, but I have no proper training in robotics. I always thought our advantage as outsiders is, that we don't do certain things just out of some sense of "honor" or mental inflexibility. Look at how German engineers over-engineer everything, making things out of machined metal, super precise and robust "because this is how we do things". >BMW Motorrad X2City - The Kick-Scooter With Electric Auxiliary Drive >https://www.youtube.com/watch?v=2FUqtwjLCk4 >2400€ Industrial robots need to be extremely precise in some cases, and repeat the same action 10k times a day, a humanoid companion robot doesn't work that way. It's just silly (or I miss something). >Man, now I wish I spoke Japanese, I wanna ask the guy ... Google Translate or a better service should work, or not? >nervously glance at my own design's BOM with almost $3k in motors... Whua, how? >Ah, that explains it! That part of the design looked quite purposeful ... When looking at a Masiro video again, it might be the movement of the chest, not bowing. She moves the chest while driving, to make it look a bit more like she's walking.

Lin 08/29/2023 (Tue) 03:03:31 No.25012

>24969 Just wanted to clarify, the price I mentioned here is specific to the prototype-- I plan to test forces many times greater than the design expects, so I can figure out its weak points and fix them in later designs. >>24992 > > nervously glance at my own design's BOM with almost $3k in motors... >Whua, how? Sorry, I should have been more specific, the *prototype's* BOM (the general design's motor requirements can still be met by sub-$100 ebike kits). Anyway, my goal with the prototype is to push the general design to its absolute limits, up to and including destructive testing, so most of the motors that I, personally, plan to use are 2-10x more powerful than they need to be. For those curious, I can set the industrial-grade motors' torque/rpm precisely enough to mimic a cheaper motor's profile, and record "estimated" energy consumption. My goal here is to get a more accurate idea of the absolute minimum requirements, so I can say stuff like "Oh, I recommend at least a 500W motor here, but if you use a 300W, you can expect it to take X seconds to accelerate with a top speed of Y", that sort of thing. At the other extreme, I can use those motors to exert forces many times higher than the design *should* be able to handle, so I can see what parts of the robot fail/are the "weakest links", then address them in later design revisions. The end goal is to solve "all" of the design's major issues before any other anons decide to build their own. TL;DR: this design is meant to be an open-source blueprint, not just "my personal robot", so I'm treating the prototype more as a testbed than a "final product". (back the NoidoDev's message) Maybe the MaSiRo project is doing something similar? (which would explain their use of industrial actuators) >Google Translate or a better service should work, or not? I dunno, I don't have a twitter account yet, so it'd basically be "huh, I got this machine-translated question from some random account that signed up yesterday, asking an oddly specific question about some aspect of my design..." Maybe it's just me, but that'd seem a bit sus... >She moves the chest while driving, to make it look a bit more like she's walking. If that's the case, that could be another explanation for their actuator choice-- since normal LAs are super slow, if you want something to bob fast enough to visually mimic a "walk cycle", you're going to need a fancy actuator that sacrifices weight for speed, which would also explain using 2 of them.

NoidoDev ##eCt7e4 08/29/2023 (Tue) 13:21:29 No.25027

>>25012 Ah, okay, thanks for the explanation.

Lin 09/04/2023 (Mon) 00:04:33 No.25189

>>24969 Well, I think I answered my own question… TL;DR (of this week’s update): I designed a “jaw” brake mechanism to hold the Bridge (keep the robot “standing” without power), but it needed more force than I expected, so I’m looking into alternate ways to fail-safe. Also fleshed out the frame a bit more, settled with “jigsaw-style” interlocking beams and “truss-plates” to reinforce load-bearing joints, but that’s not as interesting. Anyway, the details: This week’s “hobby time” went towards evaluating the (Bridge brake mechanism)’s requirements. Most of the literature I found on calculating brake requirements was for vehicle, eg caliper/disk or drum brakes, which either required too much force or were too complex for DIY fabrication, respectively. Anyway, I designed a “jaw”-clamp brake, used lever+friction equations integrated along its surface to approxim- er, determine the clamping force required (if there’s a physicist reading this, I apologize for desecrating your field so), coming out just over 15lbf applied opposite the “jaw” axle. requirements were: - braking a 100lb Payload with worst-case Bridge angle (I used the acceleration characteristics of 20 degrees, since it’s shimmed at 12 degrees) - within 500ms (faster than the shortest Bridge with the heaviest Payload would crash into the Drive Platform beyond nonzero Payload impact tolerance [below]) - with a “jaw” travel <= 0.5”, length of 4”, applied to a drum (clutch cover) >= 3” (my specific build uses a 90mm diameter clutch) - assuming the Payload can withstand the force-equivalent of a 1” (~25mm) drop at its own weight Given that the entire design needs to fail-safe, I used a 20lb extension spring, which kinda dashed my hopes of using a rack-and-pinion and a cheap Amazon-tier gearmotor (not impossible, but a rack with a fine enough pitch would cost more than the entire brake itself. At this point, I’m looking into cheaper Linear Actuators($50?), but the design does require some form of “slip clutch” (allow the brake to engage “instantly”, instead of the LA disengaging over a couple seconds). Keeping both complexity and costs down, I’m looking into worm-gear LAs, but the cheaper ones lack any sort of disengagement mechanism, so I’m also looking into an alternative fail-safe mechanism— the Bridge clutch itself. Basically, keep a compression spring on the center-bearing-side (on the Bridge axle, in front of the drive motor, see 1st picrel). That’d require strengthening both the clutch caliper (not modeled yet) or the caliper’s shifting mechanism, so I’ll be opening that can of worms shortly. If I needed to, I could skip the secondary fail-safe altogether and start working on the next part of the design tomorrow (so this isn’t design-breaking). I’ll shelve this if it starts holding things up vs. my timeline. That said, whether this fail-safe is necessary *is* up for debate, since it’d only be needed when: [robot is elevated] && [robot disengages bridge clutch to correct Payload angle, which should be both momentary and rare] && [Bridge axle chain, or gearbox, fails] Anyway, 2nd picrel is the Bridge Brake in isolated, les axle/spring/actuator. Just some 1/8in aluminum with standoffs, and a bent 1/16in sheet to back the rubber. It does require a jigsaw for the drum cutout, which isn’t ideal, so let me know if anyone has alternate ideas for the brake’s structure. Funny enough, the rubber alone didn’t provide enough friction, so I measured the characteristics of grip/hockey tape on a rough metal surface and applied that to the “drum” (clutch cover). Tape allocated up to 3/64in, so yes, industrial reinforced friction tape can be used (eg, the generic McMaster-Carr friction tape). Way too tired to bother with the wear calculations atm, but it should last for at least 2-3 years without replacing the frictive bits (given reinforced rubber, which can be sourced from rubber drain tubes, bike tires, etc.) >inb4 the wear rate comes back to bite me in the ass Btw, I have some IRL plans this upcoming week, so my next update (10th) could very well be skipped. Back to normal the following week, tho

Lin 09/11/2023 (Mon) 00:15:58 No.25302

TL;DR: Selected and modeled final wheel+gear parts (minus derailieur), which revealed that my rough design for wheelbase struts was too wide; halfway through redesigning it now. Settled on a DIY double-sided linear actuator for Bridge Clutch engagement, which sounds scary, but is only ($30 in parts) + motor. Help wanted: I’m using a bike derailier (shifter) to change gears, which is fine going forward, but will self-derail* if I try to drive it in reverse. The obvious solution would be to use an actuator to lock the tensioner, but my intuition is telling me that I can add an idler and angle the thing to put it at a mechanical disadvantage (so that, while the robot can’t shift gears in reverse, it still drives fine). * self-derails because the tensioner is pulled to max while the chain on the now “far” side of the derailieur slacks, then falls off the drive gearing (2nd picrel is a cutaway of the lower drive leg, with the transparent cone-thing being a 51t sprocket cassette [convex hull]) Also, I feel like someone has already solved this… some weirdo has gotta have wanted to pedel backwards on his geared bike at some point, right? (I don’t have enough X-axis room for a second cassette, like that British dude used…) - Selected a specific Primary Wheel for use in the prototype (and first design revisions) - BMX 20in / ISO 406mm, 1.75in rim width, <= 2.25in tire width (OD ~= 20in, measures 19.6in diameter x 2.0in wide for specific wheel+tire chosen) - Opted to use a composite/polymer wheel, since modifying it will be significantly easier than a conventional, aluminum+spoke bike wheel design. - Conversion requires removal of the cartridge bearing in wheels, replacing it with a keyshaft between 1/2in and 1in. - Shimming will likely be required- my plan is to purchase rod stock of the wheel’s ID, then boring out the keyshaft hole with a standard drillbit. - Of course, that’s in the case I can’t simply buy a sleeve/pipe with the appropriate dimensions in the first place, or enlarge them to fit the keyshaft. - Rationale: Bike wheels expect support on both sides of “axle” (just a structural support). For a one-sided support structure to be viable (with the prototype’s forces and shaft >= 5/8in), one needs over 2in of axle (beyond the wheel), supported on both “near” and “far” sides (forming a lever; fulcrum is the first support strut+structural bearing, load-bearing wheel on one side with another supported bearing opposite it. - Will look into acquiring a set of wheels so I can figure out exact procedure and design for wheel conversion. No surprises expected, but then again, are they ever? - Modeled a quick convex hull of the drive sprocket I ordered (the wiggly cone-shaped thing attached to the wheel), in order to model a finalized wheelbase - Altered Sled rails to transfer load directly to the wheelbase, instead of being suspend by the Drive Platform. Makes teardown of the robot far more time consuming, but the sheer number of design issues it allows me to bypass make it a worthy trade, imo. - The above two revealed that my original, rough design for the wheelbase “struts” (the side parts on either side of the Sled) wouldn’t work - Instead of being able to use full-width stock, I’m redesigning two “forks” to hold the Axle bearings whilst staying out of the gears’ way. These will use either half-width stock (<= 12.5mm, 1/2in) or solid plates (will need to run a couple simulations to decide if I can get away with using less material, or if it would be better to play it safe) - re: 2nd picrel again; at this stage, everything there can be rearranged pretty easily— I’ll leave it for a week or so to see if anything comes to me, and if not, I’ll just use a servo + eccentric wheel to jam the derailieur’s tensioner arm when not shifting. - (also, the Bridge engagement calipers are just placeholders atm, I know they would bend IRL)

Lin 09/18/2023 (Mon) 00:16:15 No.25381

Progress Summary: - Mocked-up the “Wheelchair Seat” that transforms into a cargo bed. - Got a physical set of the composite wheels I plan to use, only to discover that the cartridge bearing’s sleeve appears to have been “casted in”, and can’t be punched out without destroying the wheel; currently re-designing the “hub”/keyshaft receptacle around the aluminum bearing sleeve (I was going to have an analogous part anyway, so it’s not a major shift) - After watching several videos of robots being trashed by ne’er-do-wells, I’ve made some minor adjustments to my design to mitigate it. Nothing drastic at this stage, mainly just adding some extra frame around critical areas, reinforcing the load-bearing portions, and lowering the center-of-gravity where possible. - In an emergency, the robot can “drop” (quickly lower, while still retaining) its Sled (battery carriage) to increase its stability and ideally survive being tackled (optimistic, I know) - Made a deal to get some help with the design’s suspension— I might have to fight him a bit to keep my robot from being turned into a racecar, but it’s nice to have an uber-specialized professional’s input. - Until that’s wrapped up, the linkage/suspension between the Drive Platform and the Wheelbase will only be a placeholder, so don’t expect to see anything there till mid-October. Future Considerations: - Looking into compressible epoxies to reinforce the wheel’s hub, since with a full load of “cargo” the robot tips the scales at 450lbs. - (the rated 200lbs of cargo capacity comes from the owner being able to use their robot as an ad-hoc means of transportation) - Haven’t started designing the shell/enclosures yet, but I’m playing around with the idea of fiberglass/aramid/nomex phenolics on a 3D-printed backing. Notes: Going forward, unless there’s an aspect of my design that’s being discussed or that people have questions on, I’ll be shortening these write-ups to just be a TL;DR list, as above.

Chobitsu 09/18/2023 (Mon) 00:28:15 No.25382

This is remarkably-good work, Lin. Keep it up! :^)

Robowaifu Technician 09/18/2023 (Mon) 03:27:33 No.25384

>>25381 i saw in the tard olympics that their wheelchairs had the wheels at an angle, maybe you get better turning or tokyo drifting like that, could be a consideration?

Lin 09/24/2023 (Sun) 18:34:01 No.25505

Picrel: Timelapse from proof-of-concept; thought it could be interesting to illustrate the 80/20 rule in action— the first revision (r01) took the same time to develop as r03 - r05, despite the latter revisions looking nearly identical Progress Summary: Ran into an issue with the dérailleur (not) fitting within the allowable wheelbase, so I’ll have to mount it quite differently than a bike. Worst-case I’ll have to design my own dérailleur, which would be a massive PITA (moreso cause it’s losing an off-the-shelf part + complicating the design than any technical challenge.) Other than that, pretty boring week, starting frame revisions across the entire robot (finally taking bolts/other fasteners into account). Also did mounting hardware for the Bridge brake/clutches well as the clutch caliper (LA head) itself Feels like I’m actually on schedule for my New Year’s design goal— I almost can’t wait to see what unforeseen detail will go horribly wrong Also, I’m traveling for IRL stuff again (no CAD workstation), so next week’s update will likely be short or skipped altogether. >>25384 Thanks for the input— I’d considered something like that earlier on in the design, too. After a bit of research, the rationale for it (in wheelchairs) seemed to be (in order of importance): 1. improve ergonomics 2. widen wheelbase 3. increase contact area between tread and ground As for my own design, (1) doesn’t apply at all (just robot problems, amirite?). Nice as a more stable platform would be, (2) is actually a demerit given the design’s requirements and current size— with best-case (rel hinge) “door clearance” in normal houses being as low as 26”-28”, I’ve had to make a wheelbase 24” (or less) a “hard limit”, since requirements for pathing and environment modeling increase exponentially as the margin of error decreases. (3) in itself would be good, it’s just a very small benefit that you can get in other ways, like changing the tire composition/effective PSI, which I was already planning on later down the road (puncture prevention and all) Still, thank you— I really do appreciate the input.

Lin 10/02/2023 (Mon) 02:40:47 No.25688

Progress: - Worked out the robot’s power system wiring (everything’s easy ‘til you’re routing 1K-amp), the prototype will use a bunch of automotive/trucking relays, while the final version will ideally have a dedicated busbar “switchboard” to keep cost down. - Designed drive-reduction chain tensioner, with both adjustable force (resistance springs) and backstop (ease wear on frequent start/stops as would be expected for most indoor applications, while have a hard “backstop” so that maximum, near-instantaneous torque can still be exerted when needed. (it looks janky as hell, I know— after playing around with the numbers, there was simply no benefit to industrial parts in this case; plus, keeps costs to $15 + spring + sprocket. I’ll just, uh… not put this part on my resume lol) - Played around with wheelbase/drivechain tensioner designs, none of em really accomplish what I’m look for yet, more work to be done (pay no intention to the self-intersecting wheelbase tensioner “sketches” if they show up in the photos— they’re just for aiding visualization) I was on the road for a chunk of the week, hence only getting 1 part done, but it did kinda force me to work on the electrical system, so… (What? I-I’m not a procrastinator… why would you think that, anon?) Basically, the electrical supply system has 3 primary modes: - Standard: lead-acid cells (boat/truck batteries, specifically) in series, providing drive motors with 24V/400A for standard operation. Li(Fe)Po 12V either completely offline or only powering electronics. (will support partial charging of LiPo, I plan on keeping the prototype under 70% unless planning an “outing” to maximize lifespan) - Exhausted: Lead-acid cells nearly depleted— LiPo 12V cells routed thru 24V converter to charge the Lead-Acid cells in series (wasteful, but lithium-based batteries can’t [safely] supply the type of current needed). Depending on how much this occurs with the prototype, I may add the ability to directly drive the motors from the LiPo cells, but acceleration will be notably hampered (3-4 seconds to accelerate to “walk” [see OP], instead of 500-800ms) (TODO: find a way to efficiently boost 11.8V … 12.2V to 12.6V for LiPo->LA charging. Suggestions welcome.) - Charging: LeadAcid cells routed to parallel, charging lines both to LA and LiPo BMS at 12.6V— prototype contains onboard AC120->DC12.6V converter. Drive power routed through onboard 24V converter, with limited acceleration capabilities (probably not as big of a problem here, unless your poor robot is running around with an extension cable) Kinda funny how robot development begins to parallel biology, huh? Aerobic vs. anaerobic exercise and all… Also, playing around with the idea of an integral AC inverter, so I can run tools directly off my “assistant” robot. The electrical system can handle it easy, but physically fitting a 3kW inverter… Might just stick a 1kW on the prototype as a proof-of-concept, then keep my notes on scaling up. Probably not useful to most anons here, but it could be useful for the more general applications of this design (for normies, more as a tool than a companion)

Chobitsu 10/02/2023 (Mon) 04:09:10 No.25694

>>25505 >>25688 This is really pro design work, Lin. Looking forward to your prototypes phase!

Kiwi 10/02/2023 (Mon) 20:30:25 No.25733

>>25688 >1k+ Amps If you're not a car, a 36 volt system shouldn't require such high amperage. >24V 36V will require significantly less amps to run, making everything much easier for you. I'd recommend 72V if you're making her a car with tank steering. >Motors are placed to require right angle gears Why not place them like picrel? Would make everything easier. >Lead acid Why not just use LiFePO4? It's a much better battery and you aren't saving any money on lead acid once you factor in the inefficiency, deterioration, and mass increasing cost of transportation. It'll honestly make the system cost much higher for its owner over years. >Built in inverter for power tools This feels like you're on the slippery slope of scope creep.

Lin 10/08/2023 (Sun) 00:50:41 No.25841

IRL stuff again, so no update (or responses in other threads) till next weekend, my apologies. Did get a bit of CAD stuff done, mainly prep and going back-and-forth with the guy helping me on the design’s suspension; we’ve discussed postponing dynamic drive gearing till the prototype revisions (ie, after the first build), which would solve literally 50% of the design’s TODOs. >>25733 I’ll give this a proper response next week— I do have reasons for most of the stuff, but you’re absolutely correct re: batteries.

Lin 10/15/2023 (Sun) 22:33:28 No.26010

TL;DR: We now have power transmission to the drive wheels, as well as a wheelbase frame that constrains motion in a way which can be (more) easily controlled (a requirement for the in-progress suspension). Wheelbase frame had to be partly redesigned, so the drivechain tensioner I completed last week has to be re-done. Other changes: - Suspension requirement required that the Sled (battery carraige) rail take up less height; the rail is now a steel beam, replacing the original T-Slot. This will require a TSlot “fixture” to still allow for adjustment on the rest of the frame, and that’s been added to my list. - secondary (adjustable) tensioner springs for Drive Platform - Reduction Tensioner - (a bunch of minor stuff I forget, since I skipped last update) One of the picrels is the wheelbase frame, showing how the suspension bears and constrains the force: - The inner “plate” (the opaque one) rotates on its hinges’ axis, effectively allowing for vertical/dY movement of the wheel - The inner plate’s bearing allows for 10-degree skew - The outer plate can slide dZ (forward-back) in either direction, allowing the Platform to drive over larger obstacles (ex: rocks and such, on a worksite) without transmitting (damaging) shock to the Drive Platform - (the outer plate follows the inner plate’s rotation around the Z-axis, effectively allowing vertical/dY movement) - vertical load-bearing is split between both plates— the Sled’s (battery carriage) weight is directly carried by the inner plate, with the outer plate acting as a fulcrum - horizontal/shear forces (relative the drive axle) will be mostly constrained to the outer plate— the inner plate allows the axle to skew (as above), but is otherwise rigid The suspension’s frame redesigns ended up being more in-depth than expected, so the only help I’ll get from here on out is having the springs’ characteristics solved— I’ll have to come up with the suspension configuration myself, which (so far) has been pretty fun. Also, as mentioned last week, I did end up axe’ing dynamic gearing for the 1st prototype— I’m having enough headaches with suspension as it is, so to stay on target for my New Year’s goal, sacrifices were made. (wheelbase picrel: pay no attention to the self-intersecting sprocket/missing lower struts, I’m still playing around with new tensioner mounting designs)

Lin 10/15/2023 (Sun) 23:40:16 No.26011

>>25733 Most of my answers come back to the design’s underlying purpose— that is, to be a relatively cheap DIY assistant robot that can be made and maintained off spare or surplus parts, even in an unfavorable environment and under exposure to the elements. Likewise, although I’ve selected specific, off-the-shelf parts for the prototype, the design itself was meant to accept whatever anons could scrounge up, so I’ve made more aggressive design decisions that can then be scaled back, budget permitting (larger motor bays, space for doubled-up chains, etc.) I wasn’t being glib when I said a design goal was that it could be > maintained by a hobo Call it a sort of “once bitten, twice shy” after brushing with homelessness myself. In a worst-case scenario, the ability to buy replacement parts at a local bike/car/hardware store is priceless. Anyway, I’ll address your questions out-of order >batteries: lead-acid vs lifepo4 I don’t have a lot of experience with batteries (and I’m not particularly attached to lead-acid for the prototype)— the reason I’ve stuck with them so far is mainly due to expected power consumptions, where there are (very brief) spikes as high as 10kW. I expect that sort of use is going to absolutely destroy any battery that’s subjected to it, so the idea was “I might as will pick the cheaper ones”, since they’re practically a supercap if you take the concept to the extreme. I’m open to, and even have an alternate Sled configuration using a LiFePo4 battery (a integrated unit intended for offgrid use, but still) with motorcycle batteries to fulfill instantaneous power requirements. My main sticking points with that are: - prone to catastrophic failures - can’t be repaired/easily replaced (unless you start getting janky with 18XYZ-type cells and DIY BMS units) - requires either a custom battery/BMS, a significantly larger boost converter (for drive voltage), or multiple batteries (lithium batteries are a lot harder to efficiently fit in a given footprint, unlike lead-acid ones which come in every shape/size imaginable) - requires a separate environmental control to be (efficiently) usable in winters >drive voltage and current The current spikes I mentioned are *very* transient (hundreds of ms at most), and the math'd scenario that gave rise to em was towing my _car_; frankly out of scope, hopefully not something I’ll ever need IRL, and at the far end of the motors’ datasheets. Still: I, like every engineer, enjoy fantasizing about how a little extra TLC to a particular aspect of the design might save the day. Generally, most of the stuff I saw had consumer-grade motors ending above 12/24V, with industrial or specialized ones taking over between 36-72V. At least, most *efficient* e-bike motors are 24V or less, same for go-carts. As for selecting 24V for the prototype specifically, the TL;DR is that it’s (a) close to what most anons building it for themselves would use (b) so I can work with a company I’m semi-familiar with, and don’t have to worry about quality— in past projects, I’ve wasted a ridiculous amount of time buying mystery-meat parts, only for them to burn out at 60% of spec or vary between batches. Just ain’t worth it, imo >motor placement, right angle vs side-by-side That was my original plan, too. The main issue was with (affordable) drive/gear reduction, since most motors put out 5-10k RPM, while my design is cruising around 10mph with only 150RPM (drive axle)— crunching the number, I came up with the Drive Platform needing a ~12x reduction before even driving the axle. With gears made for this range of KE, you end up with very large gears and a practical reduction limit of 1:2 or 3. A gearbox would be ideal, of course, but the gearboxes rated for this cost in excess of $1k. That leaves us with chain-drive reduction, which is way more doable with a small budget or improvised parts, but requires large sprockets, a sufficiently strong chain, and a tensioner if you hope to minimize backlash, all of which increase the design’s footprint. And the chain reduction mechanism isn’t just long (>14” for a single-stage), but tall (>8”) too. Now, you could switch to a multistage mechanism, but that requires a lot more moving parts and driven shafts, plus a bulkier enclosure. To solve that, you can switch to a smaller chain pitch, but that can’t be bought off the shelves, (…) so on and so forth. In the end, I settled on a single reduction stage, which necessitated bilateral symmetry due to the sprocket size (otherwise it would require changes to the design of both the Drive Platform’s frame and the Wheelbase mounting hardware for each side, which is a whole other can of worms) Also: - Bridge drive “cuts” the footprint in half requiring motor+gearbox < 4” long, or would require the two mechanisms stacked atop eachother— while doable, it would eat up basically all of the design’s ground clearance (~6”) - I am aware of cheaper worm-drive gearboxes (and their helical variants), but those tend to have terrible efficiency (50% best-case) or can only be driven in one direction. > integral inverter vs. feature creep Either way, I’ll need a stable DC source that can provide at least a kW or two (for the Payload), so it’s not adding much in the line of electrical requirements. Physically, my current plan is to just sketch out a face to bolt on the same model of inverter I keep in my car, so it’s not much effort there, either. So, very low cost, from an engineering standpoint. Now, the benefits are potentially appealing to a whole different use case, or at least planting the idea of robots being a (functional) companion for working men. Maybe it’ll catch someone’s eye, maybe it’ll end up ignored, who knows? It’s entirely possible this is just me trying to demonstrate a type of future I see for (companion) robots, but if it only costs me a couple hours of design time, well… I can indulge my daydreams that much.

Kiwi 10/17/2023 (Tue) 00:22:45 No.26042

>>26011 >Transient current spikes If you have that problem, super caps are the only solution. Lead Acid is horrible at handling spikes. Kills 'em quick. >Catastrophic failure LiFePO4 is not Li Ion or Li Polymer. Completely different and safer than Lead Acid. >Ease of repair They come in the same package as Lead Acid batteries now. With built in BMS to make them idiot proof. >Lead Acid being superior in size and weight Why would you think that? LiFePO4 has higher specific energy, energy density, and specific power compared to Lead Acid. Lead Acid only has lower cost. >24V Please provide a link to the specific motor and controller you are using. I am curious. From your pictures, I would guess the AmpFlow A40-300. In which case, lower voltage is appropriate. Forgive me, at this scale I assumed you were going brushless, which benefits from higher voltage. >Right angle for compact speed reduction Since you're so firm in your design, go for it. >Inverter Go for it. Dream on friend, I want to see how big you can dream.

Lin 10/30/2023 (Mon) 02:05:32 No.26144

TL;DR: - Suspension is a PITA, and I’ve come to learn why specialists in the field make mid-6-figures. Attempting to design something possible with only off-the-shelf parts and hand tools is a major limiting factor, and I’ve yet to find a prefab suspension kit that meets my requirements under $500 x2 (which would break my $3.5k “consumer” cost req.) - Using a spreadsheet for simulation is becoming a bottleneck, so I’ve started developing the robot’s “software” (the simulator, software, and firmware share (most of) a codebase). I’ll post more details once I have something to show, but the goal is to break the design into functional groups as opposed to physical parts, so I can easily tweak hardware details while keeping everything abstracted for the control software— it’s designed to present inputs/outputs with appropriate “hinting” (X revolutions of motor Y will “probably” change robot position by Z), which most ML libraries should play nice with. >picrel Closeups of the new suspension— uses three “layers” of springs per strut, two pairs of struts bearing different types of loads - an internal foam-like material, more for damping than force - layered wave/disc springs - outer coil spring, bears most of the load during normal operation (pay no attention to the intersecting stuff for now, the whole system is passively loaded and the CAD program slows to a crawl when that’s modeled) (also, I'm still narrowing down selections for the outer coil spring-- the diameter will be <=1.5", so no intersecting like the current photo) >update Not all that much to report these last two weeks— I’m on my fourth redesign of the suspension. The first two attempted to re-purpose motorcycle and golf cart suspension, which respectively fell through due to price+damping characteristics and part size/clearance (I’m already wider than my footprint’s “maximum” of 24”, so anything that worsens it is a non-starter). The next version worked, but required a lathe and some machining experience to fabricate, which I’m trying to avoid (of course, I can fall back to this for the prototype if necessary). The 4th (and hopefully last, fingers crossed) version minimizes shear force enough that I can re-purpose steel pipe for the telescoping parts, and only requires threading tools (+saw, drill). The force is split up enough that even hardware-store coil springs should be enough, though I’ll be using stacked disc springs in the prototype so I can easily tweak things. The disadvantage here is that it requires the load to be split between two pairs of struts, which makes modeling the system stupidly difficult (hence wave/disc springs for adjustment, because I’ll almost certainly have *some* error) Also, did some miscellaneous stuff like adding carry handles to the battery carriage, so it can be hot-swapped by a male of average strength (planning to add drag wheels to make this more viable) As mentioned above, my free time is split 50/50 with software design, so further CAD progress will be slower. (RIP what remained of my social life lol) :: Going forward, I’ll be reducing my updates to every other Sunday (likely until I begin the physical build, since progress at this stage will be slower) >>26042 May I know what your concern with the 90-deg force transfer was? My main concern (beyond availability of gears) was motor shaft deflection under extreme load, but calculating it out indicated that the chain-drive mechanism would fail before gear skipping (of course, the wheels would slip long before either case). I could be wrong, however… Re. Lead acid battery footprint, I wasn’t speaking of energy density, but practical wasted space if I can’t find battery packages that efficiently fill the volume I have available: a “packing problem” A coworker of mine recommend I look into drone battery packs, which seems to address those concerns of mine.

Chobitsu 10/30/2023 (Mon) 02:46:51 No.26145

>>26144 Highly-impressive engineering work Lin. Here's to hoping this iteration of suspension fall within all your working range parameters for your first prototype! Cheers. :^)

NoidoDev ##pTGTWW 10/30/2023 (Mon) 05:20:22 No.26150

>>26144 That's great. I hope you find a cheap DIY method for the suspensions. Btw, the guy who works on Hannah (@DaveMakes) has mentioned he likes to put her on some rolling body like Masiro... Edit: I meant him, Dave Browne, https://www.youtube.com/@DaveMakes - he's hard to find through search

Lin 11/13/2023 (Mon) 00:24:57 No.26362

The end is near! … well, I can see the end of my to-do list now, so that’s something. Progress: - finished the Bridge “brake” (2nd picrel, holds the Payload stable and in “standing” position without using power) I’d been procrastinating— designed to to work with any generic cable-drive, only requires 6lbs*G with 0.5in travel - redesigned the “Seat” to be thinner while offering more area— the Payload can now rest on 12in x 3in (design scales between 2in and 6in with a single parameter change) - designed front follower wheels (frame only)— these are only for balancing, so I’m not gonna put too much effort into them for the prototype Current: - designing rear followers and managing CoM for “cargo mode” (picrel). Tried out a few scissor/4-point linkages, but none of em are quite right atm Remaining mechanical tasks: - Drive-wheel Tensioner, round 3! - Sled Umbilical - Cargo carrier load-bearing frame - Payload mounting system (mockup) - Generic linear actuator -> cable drive adapter - ultracap bank - make Bridge legs solid (structural simulations indicated the current ones would bend over time) - Sled vertical retention lip - Bridge motor mounting bracket After that, it’s shrouds/shell and fasteners. Fingers crossed, I’ll get to that early-mid December. If I find myself crunched for time, I’ll drop the cargo-carrier mode for the prototype (the first one, at least) Right now, the BoM will probably have to wait till January, but that’s still acceptable. Unfortunately, I have a day-job deadline in December as well— if push comes to shove, I’ll have to defer this project (and my New Years goal), but it’s 50/50 right now.

Lin 11/13/2023 (Mon) 00:44:35 No.26363

>>26150 His latest prototype is nothing short of beautiful— incredibly life-like, too. I’ll have to watch more of his stuff to see how he pulled off the saccades… I suppose he kept the mass of the eyes really low? Probably not viable for a camera or lens-bearing eye, but perfect for anons who really want bio-mimetic robots. Any idea if he works in animitronics? Cause he seems super nonchalant about all the cool stuff he’s doing…

Chobitsu 11/13/2023 (Mon) 04:09:07 No.26378

>>26362 >The end is near! Very exciting Lin! Nice improvements. >it’s 50/50 right now. Regardless of when, it will be wonderful to cross the finish line for this project, Anon. You'll do it! Cheers. :^)

Lin 12/04/2023 (Mon) 04:47:57 No.26950

Not as much progress as I’d hoped the last few weeks (IRL work), but I’m starting to get parts ordered/delivered for the build this spring. So far, I’ve picked up: - 24V @ 200Ah (4.8kWh) LiFePO4 batteries (80lbs) - A Lenovo P16 for the “brain”, 64GB RAM, A1000 6GB GPU, cellular modem, etc. (in addition to the discrete GPU, it also supports 2 thunderbolt PCIE expansions, which I’ll probably end up needing down the line) (a 6GB GPU isn’t enough for running LLMs, of course, but it’s plenty for more advanced CV, stereoscopic stuff, object classifiers, etc.) - Rockchip ARM board running a linux RT kernel (2x2 MIPI lanes, hardware encoding, ethernet, nvme support, lots of GPIO, etc.) (this will be the “master” microcontroller, though I’ll try to drive stuff directly from it until I run out of I2C/GPIO) - L3 switch running linux, 8-port (I deliberated between CAN and ethernet, but I needed higher bandwidth than viable with CANFD— plus, it makes development way easier, too) - AC PSU (1500W variable, supports CV < 36V and CC < 100A)— I wanted to go higher, but didn’t want to blow fuses if I have to recharge her on the go. Batteries support up to 2400W, but lifetime is maximized by charging at 960W. (PSU will be integrated into the Sled/battery carraige, so the robot can just use a wall socket to charge) - I considered a couple FPGA boards from Digilint, but I decided to defer it till next year— I’ll have my hands full with hardware anyway, no point in over-committing (more than I already have) on the software side (my plan here was to offload most of the hardware control from the ARM board to the FPGA, minimize latency and all, but I’ll cross this bridge only when the current board becomes insufficient) Planning to order a few different brands of linear actuators to start playing with (towards the end of December), to evaluate which manufacturer I’ll go with in the end (the prototype will have 12 of em— 4 for the Bridge/Payload mount, 4 for the support legs, 2+2 for brakes. Strictly speaking, only 3 *should be* necessary, but I’m still (kinda) hoping that I can get the thing to climb stairs down the road) Also, I’ve been browsing ultracaps- planning to settle for 9 2.7V “nodes” in series, each with 4 caps + ballast resistor in parallel. EE is my worst engineering subject, but as I understand, this should maximize capacitor lifespan while preventing catastrophic failure even if an entire node (and its 4 caps) fails. I’ll be using a dual-busbar system for the nodes, with conductive screws and paste to support 23kW transients. It’ll still put out a ton of heat when used, but at least it won’t hurt the batteries. The nodes will be just over an inch “thick”, and will be located in the “seat” backing, shielded by steel panels Still studying EE stuff so I can calculate discharge/”safe” time and Tau interval; the ballast resistors alone probably won’t be enough, I might need to add a couple passively-closed relays with high-wattage resistors using the steel shielding as a heatsink. Gotta admit, this stuff is a lot of fun to learn. The ultracapacitor bank will come in at $1,000 ; thankfully, it’s not necessary (unless you’re as crazy as I am) As far as CAD, now that I’ve got the Prototype’s batteries picked out, I’ll be redesigning the Sled to fit em, narrowing the whole design back under my 24” width limit. Currently, I’m replacing the Bridge legs and Drive Platform’s sides with solid 1/2” stock (instead of 1” TSlot) to take advantage of the narrower Sled. Also, weight management (picrel)— she a chonky girl right now (350lbs with a full Payload), a whole 100lbs above my target. Well, she *is* American, after all, but I’m gonna see if I can’t put her on a diet.

Robowaifu Technician 12/04/2023 (Mon) 21:15:46 No.26967

>>26950 wait, is this tiny boy the wheel transmission

Chobitsu 12/07/2023 (Thu) 01:38:39 No.27075

>>26950 Really looking good, Lin! Keep up the good work. Cheers. :^)

Lin 12/18/2023 (Mon) 01:36:47 No.27414

Been busy with work as I feared, but in good news, I’ll have the whole week between Christmas and New Years off— might have a bit of crunch towards the end of it all, but we’re still looking at a complete mechanical design before 2024 (les BoM) Anyway, this is one of my more abbreviated updates, but: - shaved 25lbs off prototype/experimental version and ~50lbs from the “normal” version - shaved off 1” in Drive Platform width, bringing us safely under 24” total width (23.5” width at wheelbase extremes) - reinforced/enlarged the frame in strained areas of Drive Platform; mainly the “beams” running front-back - redesigned Bridge to use solid stock to avoid strain between “sitting” and “standing” positions - bunch of minor frame revisions, primarily to spread out load (ex: the centered bearings supporting the Bridge) or use lower-cost fasteners. - designed capacitor bank consisting of 9+1 “nodes” as described here >>26950 (see picrels) > but why does the capacitor bank use copper busbars and ceramic/fiberglass insulators? Isn’t that expensive? Because its (maximum) output power is uncomfortably close to that of an arc welder > … isn’t that kinda overkill? Yes. (and I like it that way) Or, more seriously: to maximize the batteries’ long-term lifespan, I’m trying to keep their current draw under 250W whenever possible; still getting details from the vendor, but it looks like keeping the batteries between 40%-70% capacity with <= 250W draw will increase their expected lifespan 5-10 times over (going by “total power supplied over lifetime”) >but doesn’t that just transfer the wear to the ultracaps, which cost almost as much? Yes again, but the caps’ lifespan is three orders of magnitude more than the batteries’ (thousands of cycles vs millions) and is measured in complete discharges (as opposed to “mean partial discharge” or whatever black magic battery manufacturers like to give out) (napkin math puts expected capacitor bank discharge depth to accelerate to indoor speeds under 30%, but that seems a little too good to be true, so I have some more studying to do…) More EE related stuff: - designed circuit/selected parts for lower-speed sensor reading— muxers, shift registers, ADCs, and the sensors themselves. Won’t be pretty, but it’ll get the job done at the acquisition rates I need (see >>26954 ). - Planning to use some cheaper STMicro boards to acquire and “package up” sensor data, so as to not waste precious IO lines on the SBCs (which are reserved for low-latency applications like current monitoring, emergency braking, etc.) What remains (ME-related for prototype milestone) is: - final Sled revision with new PSU/AC inlets - one last mounting bracket - Seat backing/load supports - fastener selection X [imperial fuckton] ; (my just desserts for procrastination, I suppose) >>26967 Yup, there’s a 12:1 effective reduction between motor and wheel to hit (closer to) peak efficiency at indoor speeds; see spreadsheet picrel and the OP ( >>24744 )

Chobitsu 12/18/2023 (Mon) 04:13:15 No.27417

>>27414 >but we’re still looking at a complete mechanical design before 2024 (les BoM) This is very exciting news, Lin! Godspeed your solid effort here. If you meet your target costs, then I'm planning on building a copy of your prototype during 2024 if I can possibly do so. Cheers. :^)

NoidoDev ##pTGTWW 12/20/2023 (Wed) 08:09:01 No.27475

>>27414 I like the idea of Ultracaps. I had them in my mind as well, though more for power boosts in some scenarios. My plan is still to go with LTOs instead of Lithium-Ion. That said, I also think this life-expectancy much less important if the waifu doesn't have a seamless skin.

Lin 01/01/2024 (Mon) 07:00:02 No.27877

(actual post coming up later) Happy New Years, everyone!

Chobitsu 01/01/2024 (Mon) 07:27:15 No.27880

>>27877 Getting really excited to see your project prototype come to fruition in 2024, Lin. This is going to be really good to see happen. Happy New Years Cheers! :^) >=== -minor edit

Edited last time by Chobitsu on 01/01/2024 (Mon) 07:28:03.

Lin 01/01/2024 (Mon) 08:12:27 No.27881

PR1 ; 0-10c milestone (all MVP mechanical functions) - No full writeup for a week or two, gotta take a break after my “vacation” - This was my first solo ME project of this scale, so there’s a LOT I learned along the way— if people are interested, I can write down the takeaways and pitfalls. - regardless, it served its purpose as both a warm-up and starting point for more challenging designs My first build of the Assistant Platform will be referred to as PR1 (prototype 1); building to start in spring 2024. PR1 (the prototype specifically) is massively over-engineered (and will come in around $8k and over 300lbs with Payload because of that) For example, I used bearings rated for 2800lbs when only 600 would have been more than enough, a frame that can support twice its weight, drive train parts suitable for 40HP despite having less than 10HP, etc. Although the BoM will contain the exact parts I used, the program I’ve been working on refers to them by qualities: >sleeve-bearing_5o8in-ID_3o4in-OD_1in-length_1o8in-flange-width_2800lbs-radial-load_60RPM_flanged_13p45-USD_2934T46_Corrosion-Resistant Flanged Sleeve Bearing (it’s fed thru a 3rd party CAD program, so forgive the mangling— not to worry, the program decodes that just fine) Anyway, with that info, you can pick out parts (or even outright substitutions) that fit your budget. For the bearing example, the alternative I selected is: sleeve-bearing_5o8in-ID_3o4in-OD_1in-length_1o8in-flange-width_2200lbs-radial-load_60RPM_flanged_1p84-USD_2938T45_High-Load Oil-Embedded Sleeve Bearing So you’d be saving $25 on those particular bearings just by sacrificing longevity and environmental resistance, which I (arguably, over-)prioritized for my own build. Milestone highlights - overall dimensions within ADA wheelchair specs; < 24” width, 21.5” length, 25.5” (platform/”wheelchair”) height (including 6” ground clearance) - redesigned Sled/battery carriage - designed plating; functions both for protection/safety and as a structural element to reinforce the frame (these areas will be marked) - I used 1/16” sheetmetal for most of it, but it should be doable with 1/4” OSB or similar (or plastic, for the non-load-bearing parts_ - redesigned capacitor bank— PR1 will be reconfigurable between 12V, 24V, and 48V, with 1/2 primary voltage sourced via midpoint tap (will need to test, it might be too unstable to tap like that…) Missed (I’ll need to design these later) - “push handles” (placed as they would be on a wheelchair) - “cargo mode” stuff (rail extension interlock after folding, should be in a picrel) - rear follower/stabilization wheels and the cargo-mode wheel extension frame - (might be up to 6” dia, I’ll probably need physical testing to know for sure) Stuff I procrastinated (will work on in my down time— mainly busywork) - non-structural fastener selection (especially for the plating) - motor mounting bracket (lol. lmao.) - in all seriousness, I’m talking with a couple manufacturers to see if I can get custom higher-power motors for the PR1 (so I actually have an excuse this time) - cord spool (one for charging and another for Payload supply) ; I’ll probably use off-the-shelf ones that can self-rewind and re-purpose them Stuff that got deferred till build-time: - Brakes + wheel shroud - dynamic gearing? >>27417 You’re more than welcome to. I do need to find a way to batch-convert hundreds of Solidworks files to a version I can distribute (purchasing my own $10k license just ain’t in the budget, and work doesn’t want me to use theirs for anything public), but I still intend for the design to be open source. If anyone has ideas there, please, let me know Oh, and I’ve got a nagging feeling that I shouldn’t have hand-waved balancing as much as I did; worst-case is that it bumps up length to 28” (traditional wheelchair wheel placement, with free castor-wheels in the front), so be forewarned before you start buying stuff >>27475 Aye, the reason for my own emphasis on lifespan is personal preference, so if you don’t care about replacing your batteries every few years, you could probably eliminate the capacitor bank entirely, or just use AGM motorcycle batteries in their place (1/5th the cost). Of course, your poor robowaifu won’t be able to arc-weld things without it, but that might be another “me” priority lol >>27877 >2 seconds late because of captcha REEEEE Corrections/notes: >1st picrel (“Standing” mode) suspension axle shift distances should be dZ and dY, not dX >3rd and 4th picrel (“Bowing”/Pickup) By “pick up” I refer to the interlock mechanism that will be on the “seat”/Bridgehead— this particular movement was designed with the hope of a robot “Payload” (the waifu part) being able to get back in its “wheelchair” from a workbench or bed without help (obviously will depend on programming, but physically, it should be possible; I’ll test the mechanism myself with PR1) Also, I have a design for an assist spring mechanism that can be wound up to aid movements with excessive torque— aiming to get the torque requirement under 100N/m for the “self pickup” movement. We’ll see if it’s needed (still paper/pencil atm, and low priority, since PR1 is crazy overbuilt (180N/m motor) )

Chobitsu 01/01/2024 (Mon) 15:51:32 No.27898

>>27881 >If anyone has ideas there, please, let me know I don't have any experience with Solidworks, but a quick search yields these results. Maybe first attempt a conversion into STEP, Revit, or Catia file formats? Good luck Anon. - https://www.reddit.com/r/SolidWorks/comments/aizvz2/any_way_to_convert_solidworks_files_from_newer_to/ - https://grabcad.com/tutorials/how-to-open-solidworks-new-version-file-in-older-version-open-sw-2020-file-in-2018-backworks-sw - https://www.youtube.com/watch?v=swa_jzhUyWM - https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/How-to-open-Solidworks-files-in-Revit.html - https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/How-to-convert-Solidworks-files-to-the-dwg-format.html

Lin 01/08/2024 (Mon) 01:48:52 No.28144

>>27884 >>27888 >The main role of the waifu is sex It’s not, though. If all I wanted was a “doll”, I’d buy a doll, and I certainly wouldn’t spend $10k and half a year’s worth of personal time on it. >she does need legs so it can have sex. t. pussy who’s too afraid to stick his dick in a live capacitor bank >No legs=not a waifu I believe we’ve discussed this before, Pete— both ITT ( >>24781 ) and elsewhere. This project is a _platform_, a simpler robot that provides power and mobility so that future projects can focus on the humanoid aspects. With tech as it is currently, bipedal locomotion is a massive hurdle (hardware-wise), and fitting enough (battery) power into a human-sized robot is even worse. Not impossible, mind you, but unless you’re secretly a millionaire or are hiding some revolutionary tech under your bed, you’re gonna have to make some tradeoffs (or wait a decade) See my shitty shoop (picrel) that tries to show what a Payload might look like. If that won’t work for you, then I’d recommend a more “segway-like” (legs with wheels) platform for your waifu. I understand your frustration, but you’re neither my boss nor my customer. If you want people to build your vision for you, then you either need to convince them of the merit in doing so, or offer them benefits in return (“inspire, or hire”, as I’ve been told in the past) And to be clear, I’m not criticizing anyone who’s focused on the more intimate aspects of their waifu— we’re all humans, after all. For me, specifically, the primary focus is companionship— I want a waifu that can assist me in my work and be with me throughout the day. I won’t go into the specifics of my use case, but it’d be in poor taste to add tig-ol-bitties to what others will view as an autonomous workbench that follows me from the office to the shop, and into the field. (that’s also the reason for the massively overpowered electrical, drive, and (future) sensor/IO/networking systems in the PR1 build, for those curious)

Mechnomancer 01/08/2024 (Mon) 16:19:16 No.28168

>>28144 >an autonomous workbench that follows me from the office to the shop, and into the field. Oh hey that description reminds me of my first robowaifu prototype "Carry" lol (she was kinda a failure cuz her drive motors were not powerful enough and I accidentally broke the SD card with her source code). I can speak from experience that having a little owo robot watching you in the workshop certainly adds a life to the place. I agree with you in that one shouldn't overlook alternate means of locomotion for robowaifus. Lookit some of these mecha musume model kits. If I can't get mine to do a basic bipedal shuffle I'm gonna make it sit on a spooder-like platform (already have a mechanism in mind I plan to make large-scale anyway for the lulz).

Kiwi 01/08/2024 (Mon) 19:58:29 No.28176

>>28144 >Wholesome wheelchair waifu Based, Fiore is best Fate girl. Hope to see her on your platform someday! Keep up the great work. I recommend testing some systems out IRL as she is becoming rather complex. It is best to check early and often, I've personally encountered many unintended things in my various attempts. For instance, I made a pair of breasts filled with memory foam that were torn apart because I neglected the lowered strength of TPU on the layer lines.

Robowaifu Technician 01/10/2024 (Wed) 08:43:36 No.28269

Pete is one horny mf, whichever thread I open up he's there talking about sexing the waifu lol. I for one wish you good luck, yours is definitely one of the most down to earth and feasible designs, I hope to see it realized this year like you're planning!

Lin 01/15/2024 (Mon) 01:07:17 No.28442

TL;DR: Now that the major mechanical goals are done, it’s on to sensors/control systems— currently, I’m focusing on ones that are tied into mechanical design, such as the “wheelchair handles” (manual control/override), wheel/suspension sensors, etc., as well as finalizing and ordering the embedded boards. Final BoM pushed back to the end of February, with January spent integrating sensors and larger electronics into the mechanical design. Help Wanted: I’m looking for an FCC-legal low-bandwidth radio, one that’s resistant to interference and capable of transmitting through brick walls. I lack experience in the field, but I was thinking khz or low mhz— all it needs to do is transmit a cryptographic heartbeat (8-64 bytes @ 10-100hz ~= 6.25 - 50.0kbaud) between the robot’s Watchdog and the Control Pendant. Must fit within a 3.5”x2.5” square and be viable to transmit off battery. Any advice is appreciated! Final controller decision: ODroid M-series (RK3568) 3X ODroid M1 (1 for Drive Platform, 1 for Sled/Battery Carriage, 1 for future “Payload”) 2x ODroid M1S (1 per control/”Training Pendant”, one for use and a spare in reserve) (1 entirely different microcontroller to act as a security/safety watchdog, basically a remote killswitch/modem gateway— will run a barebones RTOS instead of a linux rt/preemption kernel, under the assumption that the SBCs can be compromised) I’ll elaborate in the future, but I decided to go with a tethered “training pendant” scheme similar to what we see in industrial robotics. After all, the Assistant Platform (at least, the PR1 in all its over-engineered glory) is crazy overpowered, so a pendant that prevents the robot from coming into contact with the wearer (unless explicitly allowed to do so) should make the development process much safer. Likewise, a couple people (IRL) expressed concern at moving the PR1 indoors safely (at least, prior to environment modeling and basic “AI” navigation.) To address this, I decided to turn the “handles” (like those of a normal wheelchair) into a manual control system, allowing me to “drive” it around as if I were pushing it. Of course, this is something of a stopgap, but the PR1’s goal was always to assist me in my work— the sooner I can bring it into the field for testing, the better. Other things worth noting: - Custom motors are a no-go at this stage (I figured it might just be a coil winding/wire change, but the tweaks I’d hoped for required larger overhauls, so I was quoted $10k as a minimum purchase value. Ah, how I wish I was rich…) - Evaluated a bunch of embedded boards (ARM/Rockchip, ARM/ODroid, PPC/SPC58, couple RPIs, etc.) - My goal here was to find a board with a decade or more of production lifetime, ethernet, mipi lanes, CAN, ideally PCIe lanes, etc. (mentioned in more detail here >>26950 ) - Needed a board that could serve interchangeably as ALL the controllers in the robot, so I only have to maintain a single OS image/software build. This results in some waste (ie, full-powered SBC for managing a few batteries), but the reduction in dev/maintenance time is worth it - Final decision was the ODroid M1/M1S — $50-$80 per and a bit less powerful than the Rockchip board I’d had in mind earlier, but it comes in two different form factors, one suitable for IO-heavy robot control (the M1) and another suited for lower-power interface roles (such as the control/”training pendant”— similar role to industrial ones) - Miscellaneous mechanical revisions/QoL stuff - a stand/fixture for maintenance and Platform assembly (will basically “jack up” the robot so I can mess with or entirely remove the wheel and its assembly - Handles (in addition to the directional control function I mentioned, they can be rotated 90deg and can function in “cargo mode”) - Wheelbase/axle chain guard - Added headspace (inside paneling) for an encoder on drive wheels (in addition to normal operation, can detect external forces acting on the robot, like its owner pushing the “wheelchair”) - setting up simulation models for the robot’s power system— Digilint gave my workplace a Multisim package, so I might give that a shot instead of a *spice gui (if someone has other ideas, let me know— I’m not attached to it or anything, it’s just… free!) >>28174 That’d be appreciated, thanks Kiwi. The linkage that was posted is certainly interesting, but I’ll post my remarks on it to >>237 Also, I highly discourage anons from trying to crowdfund anything they didn’t create themselves, or at least, don’t understand 100%. It only takes once to be discredited for the rest of your life— save crowdfunding for when you’re confident you can deliver. >>28176 Indeed— except for the handles (which were conditional for IRL field testing), I don’t plan on adding anything else (and I’m deferring the cargo mode stuff till I have the PR1 driving around). btw, I did order a couple helical gears to prove out 90deg power transmission— they were a bit nosier than I’d like (probably due to the testing jig I threw together with a hand drill), but I didn’t notice any glaring issues. Fingers crossed that no unforeseen details go horribly wrong lmao

Lin 01/15/2024 (Mon) 01:24:20 No.28445

>>28262 >>28265 I think you two are, uh… really, really optimistic when it comes to the *physical* complexity of bipedal locomotion. I’d highly recommend taking the time to sketch things and work out physics equations to model walking/humanoid motion… I think you’ll be impressed by just how powerful humans actually are. Even once you find motors that can put out the mechanical energy you need, I’m guessing their RPM will be off by a couple orders of magnitude… Just a “cosmetic” arm (with nothing but its own weight to worry about) is non-trivial, much less something even *approaching* human capabilities. And disregarding all that, it’s not like these limbs are operating in a vacuum-- they impose *extremely* strict weight requirements (as in, overshoot, and your robot won’t even be able to stand up), not to mention tanking the volume I have to work with, taking me from 5 hours of battery to 5 minutes unless I pull a DARPA and stick an engine/generator in the thing; unfortunately, people tend to get a bit pissy if you operate an ICE indoors, can’t imagine why… To clarify a few things: - Programming/systems design is actually my strongest field-- the reason I’m reluctant to go straight for walking/limbed robots is _not_ because of controller concerns. - The Assistant Platform was my first solo large-scale ME project; there were a LOT of pitfalls/lessons I learned, to the point that if I’d started on the humanoid portion, I’d likely have had to scrap most/all of it - Even when limbed robots become viable in the future, I’m almost certain that wheeled platforms (not necessarily mine) will remain in use. With some improvements and creativity, one could probably be built for under $1000, and both maintenance and build tolerances are much more forgiving. Especially for inexperienced/broke anons, or those with more extreme power requirements, legs might not be preferable in the first place. For >>28262 , specifically: - For more complex designs, progress is rarely linear/incremental-- if I were to start designing robot limbs tomorrow, I could likely make something capable of crawling/trundling about, but I’d have to scrap EVERYTHING if I wanted to make them stronger, or human-speed, or human sized (basically any major requirement that I didn’t hold at the start of the design process) - With experience, you can minimize the waste from major revisions (especially if you use the same fundamental mechanism-- ie, cable drives or artificial muscles), but no amount of cleverness will overcome mechanical limitations that you had to compromise on at the start of the design. Back to your point, limbs capable of crawling might reach their point of “diminishing returns” long before getting close to walking capabilities-- meaning I’d be redesigning from near zero anyway, and stuck with a less useful prototype in the mean time. It’s not as if I have something against legged robots or whatever, it’s that I have functional requirements for my prototype— speed, runtime, weight capacity, strength and whatnot, and meeting those goals would burn through my budget with a single leg (with sufficient motors starting at $3-5k _per_ ) >>28269 Thanks anon, much appreciated. If all goes as planned, I’ll be able to start designing the more waifu-esque parts of the design come next winter… (so, on the 0.5% chance I somehow manage to stay on schedule lol)

Mechnomancer 01/15/2024 (Mon) 02:25:18 No.28446

>>28445 I can appreciate the amount of engineering you're putting into this. Looks like a lot of fancy, machined parts and the end product will look very nice and be quite durable. :) Have you considered making intermediate versions to do testing on? Like a minimum viable product to prove everything plays nice before committing a bunch of time and money, just in case something doesn't work out? In my experience, building is much different from planning and it doesn't hurt to hedge your bets (I'm not trying to discourage you or anything). Vid is an example of the sort of test platform/MVP I'm referring to. Good luck.

Chobitsu 01/15/2024 (Mon) 06:39:46 No.28458

This is remarkable, Lin. At some point I'd like to discuss what you envision for the 'payload' robowaifu (in our cases) body. People want us to share efforts by splitting the workload up. Maybe this is a prime opportunity here? What you're doing here could serve as a great mobility base for our MaidCom group robowaifu project (>>15630). Maybe we can focus on the torso, arms, and head during this year 2024, while you're focusing on mastering construction of your base unit? Regardless, it's really nice to see such quality engineering going into your project, Anon. It's encouraging to us all! Cheers. :^)

Robowaifu Technician 01/15/2024 (Mon) 07:17:34 No.28463

I've got a stroke patient having functionally no motor controls and basically can't locomote at all without some sort of assistance. What I want is an electric wheelchair that has sensors in it like one of those model robot kits, that can avoid obstacles and follow lines drawn on the floor. If such sensors could be made to know what is/isn't an arterial trunk road, and know where is/isn't outside of the battery range to be able to get back, then even a patient without the means for fine control into the joystick would be able to navigate independently in this way. It's not going to alter or to expand the use-case that you have or anything, but I thought the two problems had a degree of convergence that you might find helpful in some way. If you had to go engine-powered I'd try a pit bike Honda/Lifan engine that injects water through the head/exhaust manifold then make the cartridges for it smell of sandalwood or something >>28446 I like how it's angled like a skirt like some sort of Virtual On robot

Kiwi 01/15/2024 (Mon) 20:35:20 No.28487

>>28442 >Low bandwidth wireless communication LoRa (https://lora-alliance.org/) and Meshtastic (https://github.com/meshtastic) are good for this concept. Low power and solid connections over vast distances. >ODroid M series Currently investigating the M1S as the default board for the MaidCom project. I'm hesitant as its NPU is weak. PCIe 2.1x1 isn't exactly ideal for adding an accelerator either. Your machine is essentially a deferentially steered wheelchair, why do you need 3 computers? You could get away with a simple MCU. Some ESP32's and Nordic MCU's can run offline voice and vision processing. May be worth investigation as lower cost option while your refine your system. This could turn into that security/safety overseer which runs realtime in the background and override her computers if something bad could happen. For instance, I'd include bump sensors for emergency stopping upon collision. Sensors will make mistakes, simple bumpers are the least likely to make a concurrent mistake with other sensors. (De-bouncing may be needed.) I've worked with robots, something will go wrong, the most perfect machine to ever exist will falter eventually. https://www.youtube.com/watch?v=3XbnzfBjmZk It's exciting to see how far you've come! Hope to see a physical device this year!

Robowaifu Technician 01/16/2024 (Tue) 18:58:50 No.28539

>>28463 Oh, also on the subject of wheelchair and pit bike information: >I can't speak for foam but solid chunk rubber makes the head of a patient bob around like a fishing float in choppy waters... Suspension on these heavy wheelchairs are less than is desired. Consider putting a bit of give within the axle design itself ex. anti-roll bar bushings if you want to skip having full shocks. >Wheel sizes from the multiple (Chinese) sourced bikes tend to be 17" front x 14" rears for the big MX wheels, in wire spoke only, instead of the 18" mags in the brief... Mags tend to only be 10"-12" size meant for mini-supermoto. Wheels from the Simson S51/Schwalbe are 12" alloy rim/hub & metal spoke design, rears have integral sprocket/cush drive/drum brake. Those are the kinds I've known to be "open source"/multiple makers. I can't remember if the bigger bikes, like the KX250/YZ250 might have had 21" front 18" rears. In any case it's also a list ascending by price with the "big bike" parts tending to be costlier. I don't know enough about auto gearboxes to be able to help there really either but I did see a planetary design I liked the look of once and if I can find it again I'll post the demonstration URL

Robowaifu Technician 01/16/2024 (Tue) 20:11:42 No.28540

>>28539 Simson uses 16"* wheels sorry lost the gearbox demo but I saw a different one called the "bike bum's radial cascade" which looks vastly over-complicated, but very small and light. Not sure the extent of it's patenting over it

Lin 01/29/2024 (Mon) 05:29:44 No.28872

>>28446 That's the neat part... no "real" machining necessary, the entire (mechanical portion of the) design can be built with - drill - circular saw - jigsaw - grinder+cutoff wheel (I do use fillets in the design, but those are all “round this edge so you don’t cut something” instead of “this is a rotating element and must be 99.5% circular”) Everything you see either follows those rules, or can be bought off-the-shelf from multiple distributors (no bushiness/freight shipping arrangement needed) The more irregular parts are similar to what you’d send to a laser cutter (see picrel— doable with hand tools), so I’m not paying any machine shop fees, at least. As for an intermediate/”pre-prototype”, I’m not sure it’s viable… the mechanisms I’m iffy on are ones that require nicer materials in the first place (outer wheelbase plate, battery carriage rails, Bridge legs— all bearing some pretty heavy loads), so the only stuff I’d be able to prove out would be the stuff I’m not too worried about in the first place. For what it’s worth, I’ve done 4-5 robot (team) builds back in HS/college (same scale-ish as the Assistant Platform), and I’ve seen several products through their development cycles since— I’m sure I’ll fuck up in some new and exciting ways this time around, too, but I’m hopeful I can avoid anything that’d kill the project. Worst case, I’ll be able to salvage most of the parts for another build, though I’ll be out $1-2k in machined materials. It’ll sting, to be sure, but as long as I hold my job it’ll hurt my pride more than my pocketbook. Still, thanks man. I’m getting closer to that “leap of faith” point, and I’d be lying if I said I wasn’t nervous… I’ve had a couple of my more senior coworkers check over my design, and I’ve run more simulations than my poor computer can handle— after a few fixes, everything’s come up clean. Anyway, short of building a miniature or ordering + constructing the PR1 in modules, I’m not sure what I can do to hedge my bets further while staying on schedule (Dec. 2024 is my (self-imposed) “deadline” for a fully built assistant platform, so while I’m not behind schedule, I only have time for a first build and a single revision build) >>28487 >LoRa radios Those seemed like the best option based on what little research I did since posting, glad to hear I’m on the right track. Crazy how strict FCC’s ISM bands are… Could’ve sworn there were 433 and 16mhz ranges that’d be better for such low-bandwidth stuff, but I guess Uncle Sam keeps all the cools toys for himself ;-; Thankfully, several LoRa manufacturers provide latency guarantees and fine-grained control over channels and coding. 5ms tx-rx and up to 21kbps is more than sufficient for my project. Might even be able to hit my 100hz heartbeat if I get a bit creative (the less latency to an emergency shutdown, the better ) I was leaning towards the RV-M50 by Raveon, since it… well, it claims 1w, though the datasheet seems to suggest 400mW (26dBm, maybe my math was wrong, or it’s brought up with antenna gain?). Anyway, it out-ranges everything else, and exposes the phy details that hobby “radio kits” I’ve looked at abstract away. Any chance you’ve heard of/worked with the company before? Their docs seem professional enough, the stats they advertise should be good enough for “industry standard”, but their website… I thought “please call our sales department to order evaluation quantities” was something only boomers got to read, like damn, I almost feel bad bothering them to order a few hundred bucks. >re: ODroid M series Yeah, it’s definitely not a powerhouse like the other units I checked out-- I think this is gonna come down to our projects having different requirements and architectures. tbh, I won’t even be using the NPU on those boards, at least not any time soon. In my use case, the 3 different boards are cause the “wheelchair waifu” is actually 3 different, independently functioning robots: the Drive Platform, Sled/Battery Carriage, and Payload/Waifu, which are all controlled in concert by an actual computer. I know, I know-- complete overkill (again). My plan was always to be able to detach the Payload from the Platform, and have the two function independently; for example (in an ideal world), the Payload/”waifu” could order its wheelchair to come pick it up, and once attached, the two could function as a single unit. I’ll spare you the rationale, but I ended up applying the same concept to the Battery Carriage as well (which can be hot-swapped). Although it’s wasteful, all 3 SBCs _and_ the computer run identical software, meaning I can focus the bulk of my efforts on a single codebase. ‘course, I’ll be using either a realtime kernel or tweaked preemption and core shielding so I can keep an upper bound on latency. As for the safety processor/watchdog, I’d like to use an MCU down the road like you mentioned, but at first I'll repurpose the spare "control pendant" instead. It’ll just have some really stripped down firmware, manage the modem and safety sensors, and have a forward kinematics solver that can trigger an emergency stop/shutdown if it predicts a collision (of course, the safety sensors you mentioned will be routed directly to the watchdog unit with an upper bound on latency) Like I said, just trying to cut down on the volume of code I’ll have to maintain even if it increases hardware cost. Only so many hours in the day, after all >I've worked with robots, something will go wrong, Oh, much as I love em, I’m quite familiar with tech's mercurial ways as well-- I’ve been racking up scars and broken bones from one project or another since I was 14— and I’ll have you know that only 80% of em were caused by my own abject stupidity. (worth it)

Lin 01/29/2024 (Mon) 05:59:25 No.28874

>>28458 I love the idea, Chobitsu— seems like an excellent way for /robowaifu/ to collab and show the more skeptical anons that we’re both serious and capable. I’ve “spoken” to several of em with professional experience who could likely be convinced if our projects start to “gain steam” Is there a place for discussion/brainstorming of a torso-up/”Payload” robot? I’m not sure how big of a project you see it being (how many people participating, etc.), but perhaps it’s deserving of a dedicated thread even prior to design work? I’m happy to post my own notes/design goals, and I’m sure other anons will too. ‘course, my own priorities will likely diverge from /robowaifu/’s as a whole, since my idea of a “Payload” was more a modular workhorse that I could quickly swap out parts/mechanisms and prototype with, instead of a final product “waifu” (Naturally, since I won’t be able to contribute much to that project’s development this year, I won’t be offended or anything if the team decides to take it in a different direction from what I’d envisioned) >>28463 It’d be quite the accomplishment if my project could help people with medical issues… Truth be told, several of my design plans were changed after seeing the patients coming out of the russia/ukraine war. Broke my heart to see so many guys my age and younger (hell, some of em looked a decade my junior) coming out with only one or two functional limbs. It’s beyond my abilities right now, but part of me hopes that an assistant-like robot could keep them company and take care of some simple chores/meal prep one day. Anyway, a line-following robot wheelchair with basic autonomous navigation and voice control is absolutely doable in this day and age. If I can make a few “tweaks” to the PR1 build so that robots like it can help people, I absolutely will, but I’m not sure how much I can “advertise” those “alternative uses”— what with all the regulations/liability in ‘Murica, at least. I’ll have to do some research and ask around to see how involved I can be… afaik, you need some regulatory body’s approval and/or a PE cert/employee and several (ten?) million in liability insurance. I’ve seen videos of some pretty advanced robotic wheelchairs, surely some of those companies are eager to “get in on” an application like this? I mean, if they already have proven products and the legal/liability stuff down, they seem both better equipped and more trustworthy than some random anon. Could be worth reaching out to them, if you haven't already... (to be clear, I have almost 0 experience with the legal/regulation side of things- and the experience I do have involved dealing with California- so it’s entirely possible that my speculation re:laws is overly pessimistic. Anons can feel free to correct me, and I don’t wanna discourage anyone from their own projects)

Lin 01/29/2024 (Mon) 06:17:16 No.28875

Anyway, I got stuck traveling this last week, so my apologies for the hasty replies (still catching up on sleep and all) IOU responses on the engine/wheel/gearbox suggestions— much appreciated, anons >>28539 >>28540 I was emailed a copy of the debate that took place, and I’ll try to post my rationale on the wheelchair vs. biped discussion in the appropriate threads (“wheelchair waifu”) when I have time, but most of it is gonna come back to my design priorities in the OP and the weight/speed/energy tradeoffs I mentioned here >>28445 the TL;DR is that I want a “companion” bot with enough power to carry (or “be”) my equipment as I do field work, something that could withstand rougher environments with minimal damage and, when needed, be repaired with duct tape, prayers, and parts from the local hardware store. With those requirements, I simply didn’t see a way to make that happen without switching to wheels. If you’re concerned that my statements here might discourage bipedal development, then I’m happy to retract the $3-5k statement here >>28445 -- that was in relevance to single-stage harmonic/strain wave drives packing a nearly ~200x reduction (with low backlash). fwiw, there’s a “joint” in the Assistant Platform that exceeds human-tier forces (for under $500, too)— the “Bridge” leg motor that runs at 30RPM, is 4”x4”x8”, weighs like 10lbs, and requires a dedicate “brake” mechanism to compensate for backlash and relieve the gearbox. Mind you, I’m sure there are more cost-effective, better, and compact means to go about it, so... … the best way to prove that my decision was wrong is to post results showing otherwise :) (preferably under a FOSS license). roboticist did have some good points, did his stuff ever get reposted in the relevant threads? Didn’t see em in the Bipedal Locomotion general ( >>237 ) Anyway, I just wanted to link over there so that future discussion that can be in that or the wheelchair general ( >>2983 ), since I don’t wanna discourage any fellow robot-building anons. We're all on the same side here, after all

Chobitsu 01/30/2024 (Tue) 06:31:04 No.28882

>>28874 >Is there a place for discussion/brainstorming of a torso-up/”Payload” robot? Well, it's already time for MaidCom #2. We took a breather by all acounts at the end of thread #1. If @Kiwi is agreeble the timing is right, then he can make the next thread. I can then start doing some ruffs to sketch out the concepts back and forth until both you, Kiwi, and other interested anons think it's moving in the right direction. >tl;dr Within a new MaidCom thread, Lin? >‘course, my own priorities will likely diverge from /robowaifu/’s as a whole, since my idea of a “Payload” was more a modular workhorse that I could quickly swap out parts/mechanisms and prototype with, instead of a final product “waifu” Actually from reading your further posts, your priorities are highly-aligned with my other business plans of creating a home health care assistant bot for the elderly, disabled, injured, etc. I've worked with voluteer work at school with paras / quads , and I'd like to devise something opensauce their technically-savvy friends/caregivers can assemble for assisting with their living. As I see things, there's literally no reason whatsoever that those two roads can't 'go on together for several hundred miles' [1]. :^) We can talk about clearances, base attachment points (AKA lower-spine/hips), power & control cabling, unified software control/goalsetting algos for both halves... I'm sure the list goes on to something quite extensive! Once the work has begun on the waist-up ~~totally-not-Aigis~~ torso, both projects can focus together on their similar goals there, AFAICT. Thereafter, your more-neutral needs can work off that baseline for your needed mods, while our MaidCom project can migrate to a bipedal design once we manage that successfully & openly here. Makes sense? 1. >“It's a dangerous business, Frodo, going out your door. You step onto the road, and if you don't keep your feet, there's no knowing where you might be swept off to.” >t. J.R.R. Tolkien, The Lord of the Rings

Kiwi 01/31/2024 (Wed) 00:10:28 No.28896

>>28872 >Raveon Haven't heard of them or used them before. I usually go with low cost options as with LoRa, it doesn't make a big difference. >3 Robots You are overcomplicating things for no tangible gain in functionality. I do understand where you're going with the idea of the wheelchair and payload waifu being independant entities which rely on each other. >Using pendant for security Understandable, given the nature of your project. Your pendant should have plenty of processing overhead to deal with that task is real time. >80% my own stupidity Can relate :^) >>28458 >>28874 >>28882 I'm entirely onboard for pur project working together. I'll start the MaidCom 2 thread soon. I'm interested in how you'd like to be mentioned as our projects collaboration? This goes for both Chobitsu and Lin as I feel you both have important voices to be heard in the OP. Chobitsu is right, we need standards for mating features which include power and data. This would require an agreed upon standard for us both to move forward with compatibility at the forefront. Frankly, I believe the creation of standing mating features that are easy to implement in many projects will help to foster greater creativity. Looking forward to creating great things together.

Chobitsu 01/31/2024 (Wed) 06:09:11 No.28900

>>28896 >I'm entirely onboard for pur project working together. I'll start the MaidCom 2 thread soon. Great! As you're well-aware, please choose your OP pics wisely -- especially the first one. We can always go in and change the OP texts, but not so with the images. >I'm interested in how you'd like to be mentioned as our projects collaboration? I think that this may in fact prove to be an effective approach to 'spreading the workload' out amongst ourselves a bit. I certainly believe that Lin's modular platform project will be an excellent mobility/power-base, and could easily enhance many of the MaidCom project's goals. By actually dividing MaidCom into two 'halves', this approach may very well speed up the delivery of both MaidCom, and Lin's-base projects together. >This goes for both Chobitsu and Lin as I feel you both have important voices to be heard in the OP. Thanks! But while Lin is clearly chief engineer for this project, you yourself are in charge of the MaidCom project. I'm just a motivated assistant in either case! :^) >Chobitsu is right, we need standards for mating features which include power and data. This would require an agreed upon standard for us both to move forward with compatibility at the forefront. My instincts tell me that we'd probably need to support roughly these across the interface: - electrical 24V - 28V, ~30A? - data The 100 Kbit/s - 5 Mbit/s I2C bus? - mechanical-interlock Both of you please pardon my lack of ME vocabulary. I can 'see' the ideas, even if I don't have proper terms yet... If you've ever examined the type of interlocking mechanism on a high-pressure/high-flow liquid hose coupling (say, for aircraft jet fuel hoses, or for firetruck water hoses), then you already know the kind of quick-disconnect/high-service mechanical interlock that I have in mind. This should rest at the very base of the MaidCom waist (say, roughly in the back volume of her not-yet-existent-in-this-coupled-configuration hips), and twist-locks down onto a matching end effector coupling, affixed rigidly onto Lin's modular platform's 'bridgehead' mechanism. The >tl;dr is that at the bottom of MaidCom's spine is a twistable, mechanical-lock quick-disconnect that attaches to a matching fixed connector on the Lin-base. This needs to be very strong, since the inertial/torsional moments out at the ends of MaidCom's hands come through some long & dynamic 'levers' down to the Lin-base's bridgehead's end effector (itself at the end of another dynamic lever system). This connection interface should be physically rated not only for having MaidCom's torso attached there, but also for whatever other multi-purpose contrivances that Lin envisions being installed there as well. And as for MaidCom, later on when we have managed bipedalism for her, the torso won't need to change at all -- an identical lower interlock will be affixed down into her standing hips structure for mating her two halves together! update: It also occurs to me that a somewhat-analogous exemplar for our needs here with this physical interface is the Robonaut2/Canadarm2 power/data/coupling systems, up on the ISS. [1][2] >Frankly, I believe the creation of standing mating features that are easy to implement in many projects will help to foster greater creativity. Sure absolutely. The easier it is to 'play LEGO blocks' with our robowaifu's designs, the quicker something very cool can come together out of it! >Looking forward to creating great things together. This. Thanks, Kiwi. Looking forward to Lin's response. Cheers. :^) --- 1. https://en.wikipedia.org/wiki/Robonaut#Robonaut_2 2. https://en.wikipedia.org/wiki/Mobile_Servicing_System >=== -prose edit -add 'update' msg, hotlinks

Edited last time by Chobitsu on 01/31/2024 (Wed) 08:03:08.

Kiwi 02/04/2024 (Sun) 08:53:03 No.29062

>>28900 Interesting ideas, I particularly appreciate you bringing up the NASA coupling systems. I look forward to seeing Lin's response and brainstorming these ideas further.

Lin 02/06/2024 (Tue) 02:51:14 No.29158

>>28900 >>29062 This’ll be written up in parts, so apologies in advance if I miss/overlook stuff (or butcher the grammar-- no proofreading today, boys!) The design I’d been playing with for a coupler is non-rotating, with a bar-hook mechanism (two parallel plates that “grab” onto eachother) instead of a threaded one: I don’t have anything against a rotating coupler, but I am uncertain of how easily it can be fabricated (unless we find some existing parts that fit our need). Perhaps larger NPT/pipes *could* work, but I personally wouldn’t trust them (or anything not intended to bear a structural load) to hold my multi-thousand-dollar robot The advantage of a bar/hook coupler is that we can easily change the shapes or add reinforcements, and it can be made out of aluminum/mild steel (sheet) stock and bolts/rod stock, both of which are available at the hardware store and can be cut/drilled by any DIY anon. Furthermore, it gives us more “internal” space to work with between coupling faces (by hugging the coupling’s perimeter, instead of restricting it to a circle)-- perhaps even a driveshaft-style transfer (I’ve toyed around with the idea for future arm design). Furthermore, it’s not strictly limited to 2 faces-- you could have a 3D coupler with bars that don’t all lie on the same plane; so long as tension is applied, they’ll still lock The disadvantages (non-exhaustive) would be requires a linear actuator (if only a small one) per coupler ($20-$30 and a possible maintenance concern), lower coupling strength then a rotation-locking coupler of the same size, and significantly more (if easier to acquire/replace) parts per coupler. Furthermore, a tensioning mechanism is absolutely required to eliminate slop for any coupling joint that isn’t passively loaded (potentially a second linear actuator per) Feel free to point out stuff I missed, the coupler is still notebook-stage and hasn’t been fleshed out like the rest of the Assistant platform. Design: = (applicable only to non-rotating coupler) = - “bars” along the perimeter (within coverings, of course) for the male side (likely a pseudo-pentagon for each “leg”, though a triangle/square/etc. could all be possible) - these, alongside the hooks, would be the primary structural elements - “hooks” that will latch onto those bars, and a retaining sheet/bar that keeps them from slipping off even if other “bar/hook” mechanisms fail to latch - should lock passively (with springs) - should be unlocked with a single point of actuation (rotation, linear, …?) with an external manual override (in case the unlocking mechanism fails) - in a perfect world, this would coincide with the “electronic riser’s” dock actuator - a mechanical unlock should be trigger-able from either side, in case of either side failing. Of course, the actuators to do so don’t *need* to be populated, this is just me over-engineering again - “slopes” – basic structural elements (female side only) that guide the male-side’s “bars” into the locking(“hook”) assembly, ideally allowing for 0.5-1in misalignment to be “guided” with only “pushing” force (perpendicular to the coupling faces). - this was made under the requirements of placing a “Payload” robot onto the Assistant Platform’s seat-- I’m hoping I can just “drop” (gently) the robot into the rough area and have it slide into place, instead of having to painstakingly line it up - “tensioner”: a structural element that moves along (with the riser? Opposite it?) (at the center? edges?) that pushes against the other side such that the locked hooks/bars come under tension (try to remove as much slop in the joint as possible) = (applicable to any type of coupler) = - “electronic riser” with numerous plug faces (see below for my own priorities) that can be actuated ½” (12.7, min 12.35mm for RJ45) in/around the center, allowing the robot to “plug itself in”(“dock”) once it verifies the latch) - Basic, (low-voltage?) transfer over the bar/hook assembly (with brushes on the female side, if needed?) - Handshake required before power transmission for safety’s sake, with impedance detection (relative to expected internal impedance) to immediately cut power if shorts or unknown conducting elements ( (you) ) are detected) - Will likely be made out of less conductive materials (aluminum or even steel), but the sheer surface area+volume should allow for lower-current transfer with minor loss/heat. - Data-over-Power (transmitting data over the physical coupler itself like the AD MAX20340, “Power Line Communication”/PLC) - Facilitates the “docking” process, allowing both sides to communicate their lock status and confirm that coupler impedance is as expected - Fairly low bandwidth, would function only as a redundant data pathway during normal operation (ie, if the electronic riser fails to engages or is damaged in use) - Makes more sense for non-self-powered “modules” (like a robotic arm) than a MaidCom/Assistant mate (where each side has some degree of power?), where the power-up process might be started before a completed mate (1-3 seconds), or when the female side is required to actuate something on its side to complete the docking process (driveshaft interlocking, or other mechanisms of physical power transfer?) - In cases where no power transfer is required, this could just be a low-bandwidth, low-power signaling line (I2C or half-duplex UART)

Lin 02/06/2024 (Tue) 02:52:33 No.29160

>>29158 >cont. Types of interfaces that will/may be on the “electronic riser”: - ethernet - general signal lines (including differential/twisted pair? Is there a “standard” plug for this?) - molex power or similar- lower resistance, multiple voltages (for instance, platform might supply both 12 and 48V or whatnot). Suitable for higher current power transfer - USB C - (… whatever else has a plug under ½” length) My reasons for wanting an ethernet port across the coupler is to allow video (or any higher-bandwidth data, really) to be transferred between parts. This is likely overkill for, say, a robotic arm, but it makes more sense between the Assistant Platform (which would be capturing, at minimum, the equivalent of a “backup camera”) I’d hesitate to use any faster non-differential line over such a “long” (by EE standards) coupler, since they’re *very* prone to interference (there’s a reason that serial lines tend to stay in the kbaud range). If you’re hesitant to use something as overkill as ethernet, I’d suggest CANFD, but keep in mind that debugging/sniffing the two are roughly equal in complexity (since there’s so many networking tools available these days, whereas end-user CAN tools are more limited and industry specific (automotive) ) As for “standard” coupler voltage, I was actually thinking 48V (or higher?) for the “Payload” robot’s “primary power”, but I’ll defer to Kiwi and his experience on this (plus, it affects MaidCom way more). My reasoning here was that smaller motors tend to like higher voltages if you want them to be efficient, and we’re already pushing our actuators to the limit. could always have dynamic USB-PD-style negotiation If you guys are interested, I can throw together a rough CAD model of a bar/hook coupler this weekend-- right now I only have a few (physical) notebook pages detailing it Also, worth noting that only one side (male or female) *needs* to be powered; we should be able to decide which ones makes sense (or should the standard be dynamic?) --- >>28896 >>28900 What Chobitsu said, MaidCom is your project as much as the Assistant is mine. I’m happy to collab on specific parts of it, and I’m sure I’ll end up working on modular stuff for it (arms, etc.) down the line, but I’m quite strapped for time as-is this year (I’ll be stuck traveling a bunch thru August) and won’t be able to contribute much. As for the OP, maybe it’d make sense to announce a collaboration between our projects (waifu part and mobility-platform part)? It’s up to you, of course. >>28896 >re: 3 robots and overcomplicating half-disagree-- there’s little benefit, but it actually simplifies things. From a framework standpoint (and with a bus as flexible as ethernet), getting 2 “robots” to share data is little different from 10 robots. That being the case, it’d be a lot more work to integrate+maintain an RTOS for a proper microcontroller than just slapping in an overpowered SBC and running the same exact software with a different config

Chobitsu 02/08/2024 (Thu) 16:50:01 No.29226

>>29158 >>29160 Thanks so much, Lin. Looking forward to seeing Kiwi's responses. BTW, the MaidCom #2 thread is up now : (>>29219) . BTW, if you find the time, some kind of quick sketches for your interlock & riser concepts would be quite helpful to us all. Cheers. :^) >=== -sp edit

Edited last time by Chobitsu on 02/13/2024 (Tue) 20:09:37.

Lin 02/18/2024 (Sun) 23:16:46 No.29642

Update TL;DR: Motors arrive tomorrow (controllers, batteries, wheels, etc. all long since arrived), hoping to begin system testing/integration come March. Planning to build 2 (kinda) “Assistant Platforms”, testing both expensive and cheap design variants. Just under half the design’s sensors selected— I’m designing their control/driving/muxing boards as needed (just basic stuff, I’ll post photos once all the parts arrive and I start breadboarding). Remaining electronics will trickle in gradually, as I’ll be testing/evaluating them before committing. BoM appears to be on schedule “ish” (for end of Feb.) — stock/structural parts might be delayed. Budget: ~$6k / $10k spent (2 sets of parts; high-end and cheap); future purchases will be limited to $2k/month As mentioned in the TL;DR, I’m purchasing 2 sets of parts, one for my stupidly-over-engineered prototype (PR1-alpha) and a cheaper one (~$2k?) with less power and no bilateral redundancy (the PR1-beta). Estimating the PR1-b’s exact build cost could be a bit tricky (it was a last-minute decision in view of coming in under budget), so don’t expect a hard cost number until I hit the design retrospective phase. Also, busy as I am, I can’t promise I’ll build a complete PR1-b, but I’ll try to build/prove out the assemblies that differ (brackets, suspensions, gearing, maybe AGM battery “capacitor bank” substitute?) as time permits. - Ordered all motors; I’ve purchased both my 5HP fancy-pants motors and cheaper ($70) e-bike motors with a similar footprint. If time permits, I’d like to test out the latter as well (save you poor souls from having to design your own mounting brackets lol) - One more expensive motor ($250) will remain (the Bridge’s “leg” motor), as even the PR1-b requires 70-80 N*m to “stand up”. Anons might be able to substitute that with a ~$100 linear actuator if they don’t care about “standing” speed? (speculation) - Electronics for evaluation/testing (only listing the more significant ones, stuff like limit switches, linear encoders, etc. elided) - Intel RealSense Depth camera (only 1 for now; for eval) - RPLider S3 (seems very vulnerable to dY movement while active, might not be as useful as I’d hoped— more eval needed) - Matek 3901-LOX (flow + lidar) for drive wheels (first board arrived cracked, waiting for a replacement) - AMT103-D2048-I6350 (2048 PPR 1/4” (6.35mm) encoder) and the LS7366 counter; 2048 PPR giving 0.7mm resolution on the drive wheels (~1mm was required for “assisted pushing” mode to navigate tight indoor spaces) and Bridge (1.1mm resolution) - generalized amp+ADC board for using (semi) conductive structural elements (aluminum, steel, etc.) as linear potentiometers (or similar) for spatial feedback - I have like 5 different models of LoRa radios to test, may end up going with the easiest one for the first build (time constraints) - Sled design tweaks: - “Centerpost” motor placement with miter gears frees up a bunch of space in the front of the Sled, increases lateral strength/crush resistance, and makes CoM perfectly centered - 2 extra sets of rollers and a retaining rail will allow the PR1-alpha to shift the Sled (battery carriage) by 3 feet total (57in measured tip-to-tip), compared to the PR1-b’s 16in (37in tip-to-tip) - allows irregular/shifting loads to be carried while maintaining balance - more importantly, this *should* allow the PR1-a to stand up while carrying a significantly heavier load in her (payload robot’s) “hands” (Also on my to-do list is a brief post on the state of firmware/software; I hope to use the framework for years/decades, so it’s moving rather slowly for the sake of future-proofing and ease-of-use. It’s intended both for runtime functionality and design/prototyping calculations (replacing all the spreadsheets I had to make for the PR1) )

Lin 02/20/2024 (Tue) 04:41:10 No.29694

>Jeez, Lin, think you got enough motors? Never! Anyway, the primary motors arrived today, I’ll try to find time to test em over the next week or two. Ordered spares and repair kits, too.

NoidoDev ##pTGTWW 03/30/2024 (Sat) 10:07:34 No.30638

>>29694 Hey, what's up? No updates for quite some time, more than a month. I'm not hugely interested in that project, but I'm wondering nevertheless.

Robowaifu Technician 03/30/2024 (Sat) 14:32:54 No.30644

If it interests you I found this. May or may not help give you more ideas > In this paper, a mixed control wheelchair (MCW) is presented to overcome problem related to movement and user command for elderly and paralyzed people. >The MCW comprises of five individual control blocks, which are fed at the main control unit to provide appropriate control actions. >The main feature of this assistive device is that it can navigate by following the eyesight of the user. >The proposed MCW can also be controlled using either joystick or voice command or finger movement or through mobile app or a combination of all. >This system uses multiple sensor networks to measure the terrain condition, users command and translate it into control action. >The proposed control system runs on a Raspberry Pi, which can able to take a proper turn as well as capable to control forward or backward motion. Raspberry Pi, camera module and sensors networks, etc. were all connected into the android mobile system, shortening the physical distance between the disabled person end and the supervisor end and serial communication was used. >Multiple-Layer system architecture with outstanding control functions was constructed that uses android mobile interfacing to realize the automatic control and capture videos of the room remotely. >It is shown that the users can carry out all essential tasks with the proposed MCW, almost as fast as with the traditional controller. >The smart wheelchair can assist elderly people and also improve their quality of life. https://www.sciencedirect.com/science/article/pii/S2090447921002082

Lin 04/01/2024 (Mon) 01:55:28 No.30696

>>30638 Not much to speak of, I took March “off” (from personal projects) to avoid burnout; did some minor firmware work (register-based SPI/I2C chips can be controlled with a json file specifying command/reg addresses) and ordering, though. Currently, I have all the electronics and tools (minus a few specialty bits I still need to select) needed for a build, and I’ve yanked all the non-stock part IDs out of my CAD files (material stock will have to be done manually though, ugh). To stay in budget, I’ll be splitting the pain between April and May, but things are still reasonably on schedule. I’ve got a big day-job deadline by the end of Q2, so that’s where most of my energy is going atm. Current hope is to have all physical parts+materials arriving in May, with the build starting in June (when my team’s responsibilities *should* be complete, and I can focus more on my personal stuff again.) TL;DR: Build starts in June, have to focus on IRL work until then (there’s a reason my goal was winter of ‘24 as per >>28445 ) In the mean time, it’s firmware and electrical prototyping with what free time I have.

NoidoDev ##pTGTWW 04/01/2024 (Mon) 03:22:09 No.30697

>>30696 Good, just wanted to know that things are still moving ahead. Thanks.

Chobitsu 04/02/2024 (Tue) 05:38:02 No.30712

>>29642 >>29694 >>30696 Outstanding news, Lin. Good luck with your other projects. Looking forward to June! Cheers. :^)

Lin 06/09/2024 (Sun) 22:06:37 No.31527

Been a while, my brothers-in-/robowaifu/. As anyone could have predicted, my team’s responsibilities didn’t end as cleanly as our calendar promised, but it’s “within epsilon” and I’ll have a decent amount of free time again starting from this weekend. Other than that, I managed to do a decent amount of physical design testing during the last couple months, which did lead to a few mechanisms being tweaked and one in the process of being redesigned (details next post) Anyway, part orders were delayed a bit-- there’s a few funny stories there, but it boils down to my being spoiled by having access to an ordering department/personnel... I have a newfound appreciation for all they do, let me tell you. Ended up automating most of what I could, which (hopefully) will make ordering less painful in the future. Hoping to get raw material stock (to which I didn’t attach part numbers during design) ordered mid-month. TL;DR: The last major part order should be placed the next week or two? I’ll have an hour or two on weekdays to work on my robot, but... I also have a lot of learning to do when it comes to machining, so I’ve ordered a decent amount of spare stock for when I inevitably screw something up. (another post coming later today or tomorrow detailing design changes) Also, going forward, my posts regarding solo projects will be a lot less detailed unless someone has specific questions/input (anyone here is free to ask, of course.) No deeper reason-- since I’m strapped for time, it’s just a lot more fun to spend my free time designing stuff than talking about it.

Chobitsu 06/09/2024 (Sun) 22:28:06 No.31529

>>31527 Hi Lin, welcome back! >spoiled Heheh, sounds like it. :D For us lowly, inexperienced plebeians any experience/advice you've picked up from more-closely managing your own supply chain(s) would be much-appreciated! :^) >project progress Good luck with your parts orders and any further redesign efforts needed for The Assistant. Looking forward to your incoming post(s). >lower-detail post content As one of your local 'followers' here on /robowaifu/ , I personally look forward to & appreciate any details you share here with those of us planning to attempt creating our own copy of your work. There's also the 'public archive' aspect for the broader Anon community we all share & benefit from by any valuable information posted here on this public IB /robowaifu/ (as opposed to, say, Doxxcord where it's lost to everyone but the Globohomo forever). This ongoing-archive benefit also extends out into the future ofc -- even to those new Anons who haven't even arrived here yet! -- so it's a gift that 'keeps on giving'. I don't want to urge you, but just asking you to consider the issue through other "eyes". :^) --- Regardless, we've all already benefitted from your efforts which you've shared here with us. For that, a hearty thank you (same extended to every other productive Anon here)! Cheers, Anon. :^) >=== -fmt, prose edit

Edited last time by Chobitsu on 06/10/2024 (Mon) 23:41:36.

Chobitsu 09/21/2024 (Sat) 15:32:32 No.33715

Seems like it's been a while since the board has heard from you, Anon? How's things going?

Report/Delete/Moderation Forms

Delete

Password Delete only files (Removes the file reference to the posts) Delete media (Removes the saved files from the server)

Report

Reason Global