/robowaifu/ - DIY Robot Wives

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

Site was down because of hosting-related issues. Figuring out why it happened now.

Build Back Better

Sorry for the delays in the BBB plan. An update will be issued in the thread soon in late August. -r

Max message length: 6144

Drag files to upload or
click here to select them

Maximum 5 files / Maximum size: 20.00 MB

More

(used to delete files and postings)


“I am not judged by the number of times I fail, but by the number of times I succeed: and the number of times I succeed is in direct proportion to the number of times I fail and keep trying.” -t. Tom Hopkins


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.
>>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.
>>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.
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.
>>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. :^)
>>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
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.
>>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…
>>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. :^)
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.
>>26950 wait, is this tiny boy the wheel transmission
>>26950 Really looking good, Lin! Keep up the good work. Cheers. :^)
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 )
>>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. :^)
>>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.
Open file (657.79 KB 1917x1216 00.png)
Open file (314.19 KB 1071x971 02_cargo-mode.PNG)
Open file (464.19 KB 1612x923 03_pickup-mode.PNG)
Open file (462.25 KB 1709x854 04_pickup-mode_bowing.PNG)
Open file (268.85 KB 954x1104 mpa2_r0-10c_ortho-00.PNG)
(actual post coming up later) Happy New Years, everyone!
>>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.
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) )
Open file (365.39 KB 653x1081 PR1-Payload_concept.png)
>>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)
>>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).
Open file (85.64 KB 886x1024 Fiore.jpg)
>>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.
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!
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
>>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)
Open file (8.19 MB 540x960 Robodonuts.mp4)
>>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.
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. :^)
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
>>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!
>>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
>>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
>>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)
>>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)
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
Open file (1.97 MB 3072x3072 1705433358869069.jpg)
>>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
Open file (409.59 KB 960x540 MechaHandshake.png)
>>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.
>>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.
>>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.
>>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)
>>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
>>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.
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) )
>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.
>>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.
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
>>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.
>>30696 Good, just wanted to know that things are still moving ahead. Thanks.
>>29642 >>29694 >>30696 Outstanding news, Lin. Good luck with your other projects. Looking forward to June! Cheers. :^)
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.
>>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.
Seems like it's been a while since the board has heard from you, Anon? How's things going?

Report/Delete/Moderation Forms
Delete
Report