/robowaifu/ - DIY Robot Wives

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

Downtime was caused by the hosting service's network going down. Should be OK now.

An issue with the Webring addon was causing Lynxchan to intermittently crash. The issue has been fixed.

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)


Anon and Vera collaborated closely, with Vera helping Anon refine and improve his code and algorithms.


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.
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.
Open file (237.99 KB 486x699 ClipboardImage.png)
> 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.
>>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.
You guys are completely neglecting the sex aspect of the waifu. Are you monks?
>>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.
>>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...
>>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".
>>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.
>>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
>>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
>>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.
>>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.
>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.
>>25012 Ah, okay, thanks for the explanation.
>>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
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)
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.
This is remarkably-good work, Lin. Keep it up! :^)
>>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?
Open file (1.99 MB 1000x1100 anim_2023-09-24.gif)
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.

Report/Delete/Moderation Forms
Delete
Report