/robowaifu/ - DIY Robot Wives

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

The canary has FINALLY been updated. -robi

Server software upgrades done, should hopefully keep the feds away. -robi

LynxChan 2.8 update this weekend. I will update all the extensions in the relevant repos as well.

The mail server for Alogs was down for the past few months. If you want to reach out, you can now use admin at this domain.

Max message length: 6144

Drag files to upload or
click here to select them

Maximum 5 files / Maximum size: 20.00 MB


(used to delete files and postings)

He was no longer living a dull and mundane life, but one that was full of joy and adventure.

R&D General Robowaifu Technician 09/10/2019 (Tue) 06:58:26 No.83
This is a thread to discuss smaller waifu building problems, solutions, proposals and questions that don't warrant a thread. Keep it technical. I'll start.

Liquid battery and cooling in one
Having a single "artificial blood" system for liquid cooling and power storage would eliminate the need for a vulnerable solid state battery, eliminate the need for a separate cooling system, and solve the problem of extending those systems to extremities.
I have heard of flow batteries, you'd just need to use a pair of liquids that's safe enough and not too sensitive to changes in temperature.
This one looks like it fits the bill. The downside is that your waifu would essentially be running on herbicide. (though from what I gather, it's in soluble salt form and thus less dangerous than the usual variety)

How close are we to creating artificial muscles? And what's the second best option?
Muscles are perfect at what they do; they're powerful, compact, efficient, they carry their own weight, they aren't dependent on remote parts of the system, they can be controlled precisely, and they can perform many roles depending on their layout alone.
We could grow actual organic muscles for this purpose already but that's just fucking gross, and you'd need a lot of extra bloat to maintain them.
What we need are strands of whatever that can contract using electrical energy. Piezo does the trick at small scales, but would it be enough to match the real thing? There have been attempts, but nothing concrete so far.
What are some examples of technology that one could currently use instead?

High level and low level intelligence emulation
I've noticed a pattern in programs that emulate other computing hardware.
The first emulators that do the job at acceptable speeds are always the ones that use hacks and shortcuts to get the job done.
It comes down to a tradeoff. Analyzing and recompiling or reinterpreting the code itself on a more abstract level will introduce errors, but it is a magnitude of order more efficient than simulating every part of the circuitry down to each cycle. This is why a relatively high level emulator of a 6th gen video game console has close system requirements to a cycle-accurate emulator of the SNES.
Now, I want to present an analogy here. If training neural networks for every damn thing and trying to blindly replicate an organic system is akin to accurately emulating every logic gate in a circuit, what are some shortcuts we could take?
It is commonly repeated that a human brain has immense computing power, but this assumption is based just on the amount of neurons observed, and it's likely that most of them probably have nothing to do with intelligence or consciousness. If we trim those, the estimated computing power would drop to a more reasonable level. In addition, our computers just aren't built for doing things like neural systems do. They're better at some things, and worse at others. If we can do something in a digital way instead of trying to simulate an analog circuit doing the same thing, that's more computing power that we could save, possibly bridging the gap way earlier than we expected to.
The most obvious way to handle this would be doing as many mundane processing and hardware control tasks as possible in an optimized, digital way, and then using a GPU or another kind of circuit altogether to handle the magical "frontal lobe" part, so to speak.
>>10051 No worries, done. It's not based on post recency (AFAICT), but is based on your IP. Your address probably changed since. Happens with Tor frequently, or with phoneposting from time to time. >I think I figured out how link correctly now. It's easy if you just click on the little post number at the end of a post's headline (if you have JS enabled). BTW, thanks Anon.
>>10623 Sounds good, done. >No one needs more work. No worries it's fine. It's literally in everyone's interest to have things well-organized Anon.
>>9272 >My original idea was just to use text but Plastic Memories shot down that idea fast. If you're still here Anon, I'm curious if you could spell out your reasoning here. Just as a preface a) I'm very familiar with Plastic Memories, and b) I wrote BUMP & Waifusearch to use only the filesystem+textfiles, specifically because they are more archivable/distributable/durable that way. At least that's my take on this issue. I'd be glad to hear yours though.
>>16476 >I'm bursting now, with so many things that were fun or made me happy... >Too many for me to write down in my diary English is a lossy and inefficient way to encode information. One has to be articulate and verbose to encode a memory into text, and then that text has to be decoded later into a useful format but most of the information is actually missing. Only the most valuable points get encoded and the amount of information they can contain is constrained by the language they're in. It's not just text with that problem either. Similar problems arise trying to express a sound as a picture or a walk through a forest as audio. Books, logs, articles and messages have their place but words have limited usefulness in an intuitive long-term memory. Feelings in particular contain so much information because the soup of different hormones and chemicals in the body are exciting certain memories and inhibiting others. This causes a unique behaviour and thought process to emerge that can never be exactly reproduced again, even with the same ingredients, because the memories change. Remembering these feelings is not something that can be done in text.
>>16479 All fair points, and no debate. But, knowing a little bit about how databases actually work, I'm not yet convinced that they offer a priori some kind of enhanced capability for solving this expansive problem. From my perspective that's really more an issue in the domain of algorithm, rather than data store. Isn't basically any kind of feasible operation on the data, doable in either form? It's all just operations on locations in memory ultimately AFAICT. So, a 1 is a 1 whether it's in a DB or a text file on the filesystem. My primary motivation for relying on text files in this type scenario would be complete openness and visibility of all data themselves. As mentioned, this approach also brings a boatload of other benefits for data safeguards and management. I hope I'm making sense Anon.
>>16480 Both have strengths and weaknesses. Being able to upload files into a robowaifu and automatically index them would be convenient and using a file system would speed up creating incremental backups with rsync too and also offer system file permissions to use. You could have different file permission groups to prevent strangers or friends from accessing personal data and be able to store sensitive data in encrypted files or partitions. Being able to efficiently search and retrieve metadata across different indexes and joined tables will also be invaluable. For example, to store research papers for semantic search one table might contain the papers and another contain sentence embeddings for each sentence in a paper. Then the sentence embeddings can be efficiently searched and return which paper and page the match is found on and do other stuff like finding the top-k best matching papers or searching certain papers within a given date span or topic. Another table could contain references for papers so they can be quickly retrieved and searched across as well with constraints like only searching abstracts or introductions. Other things could be done like counting how many papers cite a paper multiplied by a weight of how interesting those citing papers are to suggest other interesting popular papers. These embeddings wouldn't be limited to only text but also images, animations, 2D and 3D visualizations of the text and other modalities if desired. Transformers are quite good at translating natural language questions into SQL queries so a robowaifu would be able to quickly respond to a large variety of complex questions from any saved data in her system, given the database has proper indexes for the generated queries. I'm expecting robowaifus will have around 4 to 128 TB of data by 2030 and being able to perform complex searches on that data in milliseconds will be crucial. The metadata database could be automatically built and updated from a file system. A book could have a JSON metadata file and various text files containing the content, making it a lot easier to modify, merge and delete data and manage it with git. This database would be completely safe to lose (though costly to rebuild) and just be for indexing the file system. It could also be encrypted, hidden behind file permissions, and take into account system file permissions to prevent access to metadata.
>>16485 Thanks for the thoughtful response Anon. >The metadata database could be automatically built and updated from a file system. A book could have a JSON metadata file and various text files containing the content, making it a lot easier to modify, merge and delete data and manage it with git. This database would be completely safe to lose (though costly to rebuild) and just be for indexing the file system. It could also be encrypted, hidden behind file permissions, and take into account system file permissions to prevent access to metadata. Well, I feel you understand where I'm coming from. It's not too difficult to devise a table-based (say 3rd Normal Form) using nothing but flat-file CSV textual data. Obviously, using binary-style numerical data representation is significantly more compact than ASCII, etc., but is, in essence, still open-text. Additionally, as you clearly recognize, the filesystem is a nearly-universal data store that has decades of support from OS designers going back (effectively) to the literal beginnings of all computing. Philosophically, the first rock, the second rock makes the marks upon. :^) >tl;dr The long heritage of filesystem support for text data can't be ignored IMO. OTOH, rapid indexes, etc., are also obviously vital for practical runtime performance, etc. As mentioned elsewhere (and fully recognizing that the data itself is relatively small by comparison) Waifusearch's textfile-based system can generally return tree-oriented search responses in a few hundred microseconds -- often less than 100us (and that with no particular effort at optimizations, rather simply using standard COTS STL libs in C++ in a straightforward manner). I realize that the systems that need to underlie our robowaifu's runtimes are vastly more complex than just database lookups, but my primary point is that these are mostly questions of algorithm, not data store. Anything we can do to go back to basics + reduce as many dependencies as feasible, then the better & safer it will be for both Anon and his robowaifus.
>>16485 I've been giving your excellent practical-vision post here more thought Anon. Having a "RWFS" idiom mechanism for structure/naming/contents/etc could be a big help here. In all likelihood (particularly in this beginning), this scheme should ride on top of a traditional 'real' *NIX filesystem. We can evaluate the performance characteristics of various OS/FS platforms further along in time, but for starters I'd suggest something like Alpine Linux + EXT4. -Regarding filesystem directory structures: If you don't mind directories having non-human-readable (ie, nonsensical) names, then we can gain some nice optimizations for searches by simply using the hashing bin codes as the directory names themselves. -These hashes can actually encode pre-computed lookup data, in a fashion similar to that used by the package manager nix. -The entire tree structure can be indexed into a very compact metadata (as embeddings or any other format) in advance, and a daemon process can continually keep this index updated as new information streams into the storage from higher-level robowaifu processes. -The exact path to any specific data of interest would simply be the calculated path to it, composed merely of it's hashtree. The filesystem's structure will always mirror this hashtree, so the location on the disk is known precisely the instant it's hash is calculated. -Multi-indexes can be supported by virtue of using symlinks back to a data's primary tree location, and can be scattered anywhere in the system roughly for free (cf. data's sz itself). -Some form of low-impact, nearline/offline backup scheme (marshaled rsync?) daemon can be used for queuing up updates for sneaker-netting over to external storage, etc. Thence to git, platter-based, w/e. There's more to say on this set of related topics to your ideas, but this is enough to go on with for now. I now plan to carve out some time for filesystem optimizations studies. Hopefully some kind of prototype of this could be ready in two months or so. Cheers. >=== -add 'symlinks' cmnt -add 'nearline/offline backup' cmnt
Edited last time by Chobitsu on 05/30/2022 (Mon) 11:24:13.
>>16519 >Regarding filesystem directory structures: If you don't mind directories having non-human-readable (ie, nonsensical) names, then we can gain some nice optimizations for searches by simply using the hashing bin codes as the directory names themselves. Yeah that would be fine. The indexed data could be kept separate from unindexed human-readable data. Directory depth would have to be limited though since they cost an inode and block (4 KiB). Once every bin is occupied a 24-bit hash would cost about 70 GB in directories alone or 0.5 GB for 16-bit. This will be an issue creating multiple indexes. >Multi-indexes can be supported by virtue of using symlinks back to a data's primary tree location, and can be scattered anywhere in the system roughly for free Symlinks use up inodes. For indexes it would be better to use hard links. One concern is ext4 only supports 32-bit inodes which limits the max to 2^32. For now up to a 1 TB drive should be fine since I estimate the ratio of inodes to file system capacity will be around 1:256 bytes in a worst case scenario, but this isn't a big issue to worry about right now. Another issue is each inode itself costs 256 bytes. This could be worked around though by storing multiple memories per file. All the memories in a bin and possibly nearby bins need to be read anyway so keeping them in one file would save lookup and read time too. >Some form of low-impact, nearline/offline backup scheme (marshaled rsync?) daemon can be used for queuing up updates for sneaker-netting over to external storage, etc. Thence to git, platter-based, w/e. Changed files could be added to a list and copied in the next incremental backup with the rsync --file-from option or to an archive file. I don't think git will be ideal for millions of files or even usable for billions of files. Backups will need an absolute minimum of overhead. They will likely be binary files as well since storing tokens as 16-bit integers saves both read time and space.
>>16536 >This could be worked around though by storing multiple memories per file. All the memories in a bin and possibly nearby bins need to be read anyway so keeping them in one file would save lookup and read time too. Yeah, that general idea was floating around in my head as well. I would suggest we adopt some type of DoD as used with gaming systems as a further optimization approach too. I'm not sure what optimization strategies will prove optimal for the disk's electronics ATM, but ultimately every needs to get into processor/cache memory. Keeping cache lines full is the key to perf. >Backups will need an absolute minimum of overhead. Very much so. Still, a vital need IMO. >They will likely be binary files as well since storing tokens as 16-bit integers saves both read time and space. I'm not sure if bfloat16 is your plan, but they seems to bring a lot to the table for us?
Open file (51.17 KB 1080x683 Imagepipe_40.jpg)
Crush ribs for inserting ball bearings into plastic parts, without falling out and without the need for printing the part very precisely: https://youtu.be/0h6dCeATkrU
>>16707 Important concept for manufacturing tbh.
Video about which smells men prefer relating to women, including Estradiol (Estrogen): https://youtu.be/QXkkaqANM8I - aside of that one, most interesting seem to be Rose oil, Vanilla, fresh Oranges, and Black Licorice (which allegedly has a strong physical effect on a certain blood flow), doughnuts and other food, Peppermint, combination of Lavender and Pumpkin pie (most attractive), and Jasmine. Vetiver and Musk were also mentioned, but those are more general and ambiguous. - Full article with more links: https://www.thelist.com/149560/scents-that-surprisingly-make-women-more-attractive-to-men/ - Study on hormones in the odor: https://royalsocietypublishing.org/doi/full/10.1098/rspb.2018.1520 - Study on how the scent of roses makes women more attractive: https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0098347 - Study on "Human Male Sexual Response to Olfactory Stimuli" - Black Licorice and others: https://aanos.org/human-male-sexual-response-to-olfactory-stimuli/
What if ran cooling fluids through big elf/fox/cat ears or structures that looked like wings? We could use a lot of surface area without compromising her appearance. Maybe wing like structures could be used to help with balance too or a tail.
Open file (471.64 KB 656x717 OtomediusMiniWings.jpg)
Open file (165.72 KB 920x920 Swerzer.png)
>>16766 Wings with wheels would serve many functions admirably. They'd provide a large surface area that's often exposed to moving air as you mentioned. The balancing aspect would allow for her to be a quadruped while maintaining the aesthetics of a biped. I also have a thing for wings
Open file (60.09 KB 796x945 Lambda.jpg)
>>16767 Her wings could be folded to look like a dress while they provide balancing points of contact.
>>16767 You don't need to make her a quadruped to get better balance. The point of the "wings" would be to spread mass away from the pivot point thus increasing her moment of inertia. It's just like when you spread your arms out to help you balance.
Multifunctional flexible and stretchable graphite-silicone rubber composites: >>17202
I had an idea on how to make some of the prototypes more profitable. Early models could be geared towards the elderly or PTSD victims to help them integrate back into society. Even an AI with very limited intelligence could be useful here. I know they give baby dolls to people with Alzheimer's disease because even though they lose their minds they don't forget how to love. A strong durable companion could be very valuable for treating soldiers with PTSD because if they snapped it wouldn't be able to hurt the robot.
>>17468 Excellent insights, Anon. Yes, I too think that the medical field is an excellent domain to target some of our interests here on /robowaifu/ towards. Japan in particular is already working towards this issue full-bore (and has been for decades), and this likely explains why they are leaps and bounds ahead of the (now-dead) West in the sub-domain of robowaifus. >tl;dr Everyone still has a long way to go yet, but the medical arena will produce companion robots pretty soon IMO.
>>17479 The "cripple bots" idea could be especially useful here because those robots could both help the elderly and help the rest of society change their views on the disabled.
>>17480 >robots could both help the elderly and help the rest of society change their views on the disabled. Agreed. Imagine these older hikkis having robowaifus (or even just companion kibo-like puppers). I think their outcomes would have been quite different tbh. >Dying Out of Sight: Hikikomori in an Aging Japan https://www3.nhk.or.jp/nhkworld/en/ondemand/video/4001383/
>>17481 >yet another victim blaming documentary written and narrated by a cunt who has never had a genuinely bad day in their entire life.
>>17497 It is, but if you'd care to contribute here then please stay on topic, or at the least address the point of my post friend, kthx.
Maybe interesting, long term at least. >We introduce damage intelligent soft-bodied systems via a network of self-healing light guides for dynamic sensing (SHeaLDS). Exploiting the intrinsic damage resilience of light propagation in an optical waveguide, in combination with a tough, transparent, and autonomously self-healing polyurethane urea elastomer, SHeaLDS enables damage resilient and intelligent robots by self-healing cuts as well as detecting this damage and controlling the robot’s actions accordingly. With optimized material and structural design for hyperelastic deformation of the robot and autonomous self-healing capacity, SHeaLDS provides reliable dynamic sensing at large strains (ε = 140%) with no drift or hysteresis, is resistant to punctures, and self-heals from cuts at room temperature with no external intervention. As a demonstration of utility, a soft quadruped protected by SHeaLDS detects and self-heals from extreme damage (e.g., six cuts on one leg) in 1 min and monitors and adapts its gait based on the damage condition autonomously through feedback control. https://www.science.org/doi/10.1126/sciadv.abq2104
>>18088 Very nice find, Anon. Yes I'd predict this could be useful in numerous ways, not the least of which is resilient controller networks in future robowaifus. The materials themselves are probably of interest to us even sooner, in the context of soft coverings over a typical robowaifu's internal exoshells--particularly as self-healing ones.
Open file (1010.98 KB 2158x2190 2020TSlot.jpg)
Designed an easy to print 20202 t-slot compatible bar. Print using vase mode/spiralize outer contour with a line width of .6 mm (nozzles between .4 and .6 mm work) using the thickest layer height available to maximize strength.
>>18276 >>18277 Nice! These are invaluable for structural protoyping, easy to adjust things on the go.
English translation of the Uncanny Valley essay, vetted by the man who coined the term. https://spectrum.ieee.org/the-uncanny-valley
>>18688 And here again the critique of it: https://www.youtube.com/watch?v=LKJBND_IRdI - Just make them cute, problem solved for most people here.
Open Emag - Make your own electromagnets: https://www.youtube.com/watch?v=GED3Qu_hf9Y - I had the same idea, found it by accident here: https://www.thingiverse.com/thing:1371831 >Why electromagnets? >Electromagnets are important in modern life. The average person in modern society relies on electromagnets daily. They have been out for long over a century, and electromagnets are key to all electric motors, all speakers, and all magnetically locking doors, for a small set of examples. There probably are many more inventions that could be created to benefit the world using electromagnets but the public is generally unaware of them. If more people know about this century old idea, people will understand much more about what's going on around them and people could even make new things. It is very likely that the plethora of conveniences from electromagnets is not even close to being realized yet. Electromagnets are the only magnets that can turn off or reverse themselves or change strength on demand. I get excited just thinking about that !! >Why use the machine? >Good electromagnets have hundreds, or thousands of turns. We want to push the limits. No one (in their right mind) wants to count hundreds or thousands of anything. Also, this offers repeatability. You can make 10 electromagnets with 600 turns each, and it would ideally take a little over 30 minutes with this machine (at 200 rpm), that's 3 minutes per electromagnet. Doing that same task by hand?-- well, that's the alternative.
I collected some pictures of necks mechanisms to look at and take inspiration from. And one video from the Dara robot: https://www.youtube.com/watch?v=pWmEGxusrdE - We had this mechanism here somewhere before, but I forgot the name, and he doesn't mention it, so no one can find it and anyone would think it's his idea. I'll probably use the most silly looking one, the Dodge neck to design my own, since it gave me some ideas. That I will again post in the prototype thread. I just thought this collection would better fit in here.
>>18844 Ah, interesting. Five pictures are the maximum for postings, but it just ignores the additional ones without any warning. Anyways, the Dodge neck mechanism I mentioned above is the second picrel here.
>>18744 Neat! Combined with anon's SRM research (>>18776, ...) the idea of DIY actuators from scratch becomes more and more plausible seemingly. >>18844 These are very interesting Anon. I'd suggest that for now most anons just focus on the minimal viable neck function for economy & simplicity's sake. Fun problem to think about though.
>>18850 >the minimal viable neck function for economy & simplicity's sake. Yeah, on a second thought I came to the conclusion that something like the Hasbro action figure approach might be better as a fast and easy solution, if we combine it with a "joystick" functionality. I first thought of making it itself out of some kind of silicone it would simply conflate if strings would pull on the head. But now I think more of one rubber string and springs. - The head falls automatically forward if the neck string is loose enough. - Can be moved by outer force in all directions at any time. - Can tilt forward fast through some weak but fast motor in the front, and because the string holding it back up would be elastic and just strong enough to hold it in place without any additional force involved. On a string below, or bit higher doesn't matter. It will snap back automatically and fast as soon as the front motor stops pulling, because of that neck string which is elastic or there's a spring involved. - Sideways movement only by overcoming some relatively weak springs holding the head in the middle, so it will snap back automatically. These automatic snap back functions might be fine for a rather simple waifu, but keep in mind humans can sit in various ways without a string or spring is loaded the hole time and also slowly deteriorating that way. That said, I don't see the importance of having her head tilted sideways for a longer period of time and the elastic string the backside could be loosened through a servo and allow her head to stay tilted forward for longer. Looking upward might require the backside motor to pull it back and then hold it there, but that depends on how much force the head would have and what kind of servo would be used. Anyways, didn't have much time today, because some other things I had to do.
>>18862 Thanks Anon. If you find time, maybe you might make a sketch of your idea in this post to help us all understand things a bit better.
>>18865 I'll work on this in CAD soon, not sure if it's worth to make a sketch first.
>>18872 Even better! Looking forward to it Anon.
Before someone has the same idea as myself, and maybe even patents it as novel: Animated dolls, possibly sex-enabled companion dolls with any mechanics and electronics inside, or similar devices, could use tattoos on their skin which are only visible under a special light (e.g. UV) or internal LEDs under the skin to indicate ... - a point in their body to use a syringe for adding some internal liquid to their body, e.g. for lubrication or perfumes for later use. This point would be a internal tube or tank. The hole could be closed after use by applying a little bit of silicone to the skin, but there might also be a internal software-controlled mechanism to open the top of the tank before adding the liquid. - a line or more complex pattern to make a cut for internal repairs or replacing parts. This would be to minimize damage to the aesthetics or to avoid to damage important mechanisms. - a hidden plug for a cable to connect to an internal device of the "doll", which can only be reached by cutting the body, probably as a special emergency measure, e.g. to flash some firmware. - any mechanism to help disassemble the body, e.g. by loosing a screw which is not visible from the outside with the skin intact. >>18879 Crosslink: I posted the prototype here >>18887
>>19009 Excellent idea Anon! While I love a good robowaifu shell-seam as much as the next anon, tbh a one-piece, fully-enshrouding 'full bodysuit' skin is actually better (as in; safer, more-maintainable) for both the Master and the robowaifu. Your invisible dye idea is a wonderful enhancement to that basic premise.
Open file (121.05 KB 717x1600 AncientMaidKnight.jpg)
There's much to learn from the past. DaVinci's knight is a fascinating automata that could achieve some interesting motions with one actuator. https://blog.salvius.org/2014/01/a-history-of-robotics-da-vincis.html
>>19340 Excellent point, Anon! Old Italian Dude is one of my heros, actually, and I've been fascinated with his (manifold) works since I first discovered them in boyhood. I'll try to dig into this idea further soon.
blogpost discussing the progress by micro-robotics researchers in creating tiny flying robots, and the importance the study of biomimicry played in their successes. https://reasons.org/explore/blogs/todays-new-reason-to-believe/saving-lives-and-exploring-frontiers-with-bioinspired-tiny-flying-robots
>SimpleFOClibrary - Simple Field Oriented Control (FOC) library >A Cross-Platform FOC implementation for BLDC and Stepper motors based on the Arduino IDE and PlatformIO https://github.com/simplefoc/Arduino-FOC C++ 94.5%. C. 5.5% Like I keep saying, better get to studying C++ if you wanna engineer in the new Robowaifu world, Anon! (>>18749) :^)
Open file (393.93 KB 2000x2000 blind-rivet-5x6mm.jpg)
I bought something called Rivet. I hope I can use these inside bigger rollers as axis, shaft or pivot. Or in some cases to join parts together without needing to add screws and nuts. Gluing one side into a hole might be good enough. In other cases only one direction needs to be constrained.
>>19398 Get the rivet gun that will set these for you also. With these, you can tack together sheets of stuff w/o needing a substrate support at that spot (eg, a wood strut for a screw or nail to drive into. you won't need that).
Open file (217.50 KB 1044x1392 Spring.jpg)
Open file (77.52 KB 853x775 Ex.png)
When 3D printing, some designs require really tight tolerances. Due to the nature of different brands of filament and colors of filament behaving slightly differently, it can be ideal to use built in clamps to ensure a tight fit. picrel includes a test to prove effectiveness and the CAD design to help inspire Anons when they make their own.
>>19408 That looks pretty sophisticated, actually. Can you break the ideas out a bit further for the uninitiate, Kiwi? How is the 'built-in clamp' acting in the dynamics of your pic-rel, for instance?
>>19408 Looks like a great idea. Though, I would like to add that this should then be done in PETG, not PLA (bc creep). Also I'd still prefer something relying on metal to make sure this will hold up over time.

Report/Delete/Moderation Forms