>>16226 Finally got some somewhat successful prints after aggressively sanding my print bed. (Anyone know of a good brand of PETG? NOVAmaker and Duramic have similar failures/smell to ABS.) Glad to report everything from plastic thicknesses affecting material properties, my clipping machanism (I just have the clip on the otherside as it's way easier to print with trash PETG.), and tying things together works almost exactly as intended. Will add stabilizers to the mating surfaces of the mesh and nexus blocks as they wiggle too much. Also reducing the number of holes to two as you honestly only need one knot. Pictures were taken on an open notebook for a sense of scale. Looking forward to more tests soon.

>>16227 Neat! Nice work Anon. Once everything's assembled and the skin is in place maybe some of the cosplay LARPfoam + thin prosthetic-grade silicone cured/powdered overcoat? this kind of structural form will be very /comfy/. Good for huggles! :DD

Crosspost from foundations: >>16230 Threw together a few libraries into a one-pager talking chatbot. Needs work, but it's a proof of concept.

>>16231 >Threw together a few libraries into a one-pager talking chatbot. Needs work, but it's a proof of concept. Thanks! I'll have a look at it over the weekend sometime Ricardo. Lol sorry but I'll have to spoiler your graph. :^)

After careful examination of MaSiRo (https://www.masiro.cafe/tipping), I've realized that they essentially made a robot very similar to what MaidCom will be. I labeled much of her internals to give other Anons guidance on how she functions on an electronics level. Our MaidCom will be much cheaper and lighter mechanically but, nearly identical electrically.

>>16222 Checking in while I'm out of town and have a minute. I like these ideas, thanks!

>>16212 My crude prototype specifically allows for this with a rear hard point to attach a backpack type shape - which could accommodate extra battery, storage, tools, etc) A "back" module is never a bad idea, I would like to keep this feature in the plans.

>>16247 Sauce on pic? Can't seem to locate via the link. I assume those are two linear-screw actuator struts in the central volume? Also, no wonder they need such a massive locomotor system, this thing is built like a piece of light-duty industrial gear. I have high, high hopes that our meshtegrity based approach will afford us much-lighter, much-cheaper robowaifu systems, as you suggest. OTOH, I notice that they have vaguely adopted a loosely-hexagonal floor layout of the 2 driven-wheels and the 4 follower swivel-wheels. Good thinking. Much like the Fuchikoma/Tachikoma legs, this geometrical arrangement brings as many benefits to locomotion stability as it does to meshtegrity frames & shells. I hope we can a) greatly simplify the electronics needed (possibly moving some of that complexity over into the software side of the house), and b) clean up that dang wiring mess! :^) Srsly tho, good cable management is actually far more important for our robowaifu engineering than it is for say, a big data center. Data center wiring messes are simply a nuisance for the networking techs. Bad wiring in our robowaifus could spell disaster. Nice pic & labeling Kywy, pls provide many more like this.

>>16252 >A "back" module is never a bad idea, I would like to keep this feature in the plans. Agreed. However it's not without cost (as is the case in any engineering there are trade-offs always to be considered). Specifically, in this case, we have to engineer unproved tensions for the so-called 'floating chest' of the meshtegrity system in MaidCom (>>16108, >>16222). Additionally, any extra mass up on the back also has effects on the general kinematics of the systems. To wit: you're placing that mass further-out on the 'lever-arm' of the geometry, from the central-mass point (virtually in the pelvis volume). Any such emplacement of mass (not just this specific case) increases the thrown-weight problem that all actuators have to deal with. This necessarily increases all cost calculations involved. >tl;dr It's (almost) always a good idea to keep mass as nearly on the central-mass point as possible (from a mechanical/structural engineering-economics purview). >=== -add the single word 'almost' -add 'mechanical/structural' cmnt

>>16132 >>16165 Truly a man of many talents! :^) I've been concerned repeatedly about pinching in the various externally-exposed mechanical joints. Your old-school 'bellows' design seems a good fit for our low-cost approaches we're attempting here. I wonder if these can be obtained in some fashion already pre-manufactured and cut to our needs? Automotive aftermarket suppliers perhaps? I suppose we'll contrive our own molds, etc., for this kind of thing in our own factory efforts one day tbh. But for now, at this point in time, front-loading as much as possible of that is practically always going to be a big benefit to us here.

>>16228 A foam padding would work well. Especially with an outer fabric skin like picrel 1. >>16231 Adding you to the software team, thanks for your contribution. >>16251 >>16252 Thanks for your check in. Both I and Chobitsu have started brainstorming ways for a backpack to work. Which we've been referring to as a Rondoseru as they are the cutest variant of backpack (to me). >>16258 Found it on 4chins, no idea where they found it. Those are linear actuators used to adjust her height. I recently came across a tutorial for designing your own which could be helpful for us. https://youtu.be/-C9e--3nvro MaSiRo robots are built for working in cafe's so they have fundamentally different needs. Though, more points of contact are better for stability, rocker bogie mechansims being a good example. I'm striving to keep her electronics as simple as possible. Part of the reason for the 5/6 connector being developed is to ensure clean simple wiring. I plan to post more infographics to help our mission. >>16259 We were very recently talking about using her tail to help with this dilemma. I'll lower her backpack expansion area to the lowest it can go as you're correct about how the thrown mass would affect her dynamics. Squaring this backpack expansion with her lightweight frame goals is no simple task. I'd appreciate any and all suggestions. >>16260 Bellows can be 3D printed though, I'm just going to use stretchy fabric and good engineering to prevent pinching.

>>16264 >Squaring this backpack expansion with her lightweight frame goals is no simple task. Agreed. >I'd appreciate any and all suggestions. Well, I think I'd suggest you don't attempt to make it part of the chest (front or back) at all. Instead I'd suggest a couple of L-shaped frame rails extending back from her hips. They would extend slightly posterior (say, <= 5cm) on the 'base' of the L, and then turn basically 90' upwards for say 10-15cm. Secure a narrow-profile rondoseru (sans straps) in place to them (or even something in form like one of those little 'bundles' I don't know what they're called lol that are at the rear of the waist sash in traditional kimono garb). Then you can balance that static lever-force moment out with an appropriate counter-mass of batteries near her belly's frontal volume. This arrangement should keep the masses reasonably closer to ground level, near her central-mass point, stay mostly out of the way for her day-to-day activities, and (importantly) not impact the dynamic loads of her chest complex. >tl;dr Just attach massive things to her hips, not her chest. These items can also be removed as needed -- by design (including their support-frames, which should probably just slide down into keyed attach-points in her shell). >rocker bogie, et al <plus a tail, too! I like it! Good thinking Anon. Hey, if it's good enough for the Mars Rovers, then it's good enough for MaidCom too, right? :^) >Bellows can be 3D printed though, I'm just going to use stretchy fabric and good engineering to prevent pinching. Sounds good. Certainly anything we can do to reduce costs while still maintaining sound design & engineering aesthetics/integrity is very likely to also be a good choice in general Kywy. Onward! :^) >=== -minor clarification re. hips frame loc'n -minor sp, grmr, fmt edit -add 'ground level' cmnt -add 'support-frames' cmnt -add 'chest complex dynamics' cmnt

>>16258 >Sauce on pic? https://www.masiro.cafe/masiro

>>16267 Great, thanks Anon! I certainly wish them great success both with their Meido Cafe endeavor, and also with their robowaifu designs. Maybe they'll visit /robowaifu/ one day. :^)

>>16260 It's flexible pipe. You can buy it at Home Depot. It's often used for drainage pipes, drain hoses on RVs and protecting electrical connections.

>>16270 Great thanks Anon! After I made that post the thought 'Well maybe something like dryer hose?' came to my mind, but I decided immediately it was too fragile durability-wise and dismissed it. But if there's something like that readily and inexpensively available (I think I've seen it on an RV-type vehicle now you mention it), then that's a very handy thing if needed. However, I think Kywy is already planning for this (important) issue, so the pipe probably won't be needed. Still, good to know. :^) Thanks again Anon.

>>16265 Hm, good ideas on how to achieve balance. The Rocker bogie was just an example, it's patented so we can not use it aside from designs people make at home. (We will be making a version with notation that it is strictly DIY.) >>16267 Thanks >>16270 Huh, didn't even consider that but it is a good material to use. Any updates on designs? Do we need another extension?

>>16165 Hi, I'm currently not part of the specific MaidCom project. But, since everything seems to now being discussed here I wanted to mention that I wanted to include regular Linux programs in the robowaifu AI. If something has been solved already, then there's no reason to reimplement it. There's a program called Taskwarrior for the console. Changes require commands in the console, which could also be coming from another program and of course being logged into a logfile or database.

>>16274 >good ideas on how to achieve balance. I don't need to tell you of all people that we really have to take a systems approach to the study of mechanical dynamics of robotics -- particularly something with such complex kinematics as a mobile, humanoid form such as MaidCom (and even much more complex systems to come). But using simple tricks like counter-weights can go a long way for us to simplify the general problem. >The Rocker bogie was just an example, it's patented so we can not use it aside from designs people make at home. (We will be making a version with notation that it is strictly DIY.) Ah, I see. Good to know, and even better still there's someone leading the project who looks into this kind of thing! :^) >Any updates on designs? Do we need another extension? I realize that I'm not directly part of that division, but I admit I'm somewhat confused Kywy. Haven't we already gotten a couple of nice ideas from Meta Ronin (>>16163) & RobowaifuDev (>>16132)? You yourself have generated a ton of good ideas obvs. And even a number of the rest of us have contributed in our way. So, I'm unclear what's needed further? Admittedly I'm quite ignorant of many design requirements needing to be addressed, and so I'm probably missing things that are obvious to you and others. Can you please spell out in more detail for us what's required? It might help out everyone to be on the same page.

>>16275 Hi Anon, welcome! >Hi, I'm currently not part of the specific MaidCom project Well, please join up! (>>15486) Hey, you can't expect us to carry all the load, right!? :^) >I wanted to mention that I wanted to include regular Linux programs in the robowaifu AI. >If something has been solved already, then there's no reason to reimplement it. These are certainly fair points. Indeed, prior-art forms the basis of the vast ocean of advances men achieve in practically every domain. The extraordinarily eminent scientist Isaac Newton made this very clear in his 'boy on the seashore' quote. Many would claim he was literally the single most intelligent man in history, yet he made it plain all his works were dependent on other luminaries preceding himself. So yeah. OTOH, we have an unusually complex and sensitive set of systems and requirements we're all working towards together here. Privacy, safety, & security not being the least of these concerns. We've talked about these topics in general the board-over, but we have one of particular import to your suggestion, Security (>>10000). Unrestricted access by the uncounted number of possible applications running on a Linux (or any other OS for that matter) system is plainly a big no-no. To put it another way; would you really want Syst*md to be any part of a operational system that controlled the fluttering of the wingtips on a commercial airliner? If you were flying on it? Your grandma? I would suggest that what we are tackling here is at least as complex and delicate in the end, in some ways moreso. Throwing applications helter-skelter at our robowaifus, with no vetting whatsoever, is a sure recipe for disaster -- both for Anon and for his robowaifus.

>>16275 I plan to make a conversational user interface where people can define their own commands, tasks and events. So if you want to use a tasklist manager through your robowaifu you can do so after a dev sets it up with the CUI API. >>16277 Robowaifu security will follow the principle of least privilege. A tasklist manager has no need to access her memories, camera, microphone, servos or decision making process and can be restricted from accessing those, including having memory and bandwidth limits, network and file restrictions and lower process priority. Simply blocking all applications will make it difficult to do anything useful with robowaifus and block other devs from contributing. Updates to critical applications though will require vetting so we don't have a node-ipc malware incident or something similar. Applications could also run in a virtual machine or separate device entirely to prevent zero-days in the operating system from being used.

>>16290 >Applications could also run in a virtual machine or separate device entirely Yep. In fact I sort of indicated this direction in my Robowaifu OS/Brain-cluster thread from back in the day (>>201). Massed-unikernels running on hypervisors offer us an unusually-simplified potential solution to both the security and stability problems. Thanks RobowaifuDev, that input is very appreciated.

>>16276 Meta Ronin's contribution was more of an outline describing his prototype of a design. I shared some of my design ideas to help them crystalize their ideas. Now we await their actual designs. RobowaifuDev's contribution is noted and great but, I want to ensure everyone who wishes to contribute their voice is heard before anything is finalized. Also, you requested a deadline extension on your own design submission >>16159 though, I'm confused by this since you're on software. >>16277 >Syst*md Not in my waifu! :^) Think we should use Antix Linux as our base distro with ROS on top? >>16290 >>16292 Good to see the software team working together. Authentication and isolation principles will indeed be important.

>>16293 >Also, you requested a deadline extension on your own design submission >>16159 though, I'm confused by this since you're on software. Heh, my apologies. That was in relation to your request for a sketch related to my "OP'd crystallization" post. We immediately launched into a long back-and-forth thereafter that resulted in your well-coined "Meshtegrity" concepts we are now pursuing the design of. I considered that 'extension' immediately resolved by that discussion? >Not in my waifu! :^) Poor Lennart Poettering! He'll never have a robowaifu now. How will glowniggers ever cope!?111 >Antix Linux <"Proudly anti-fascist "antiX Magic" in an environment suitable for old and new computers." Heh, I think not fren. Filthy-Commies and Leftists are no friends of us or our goals here tbh. It's not even about their politics, etc., per se, but simply put: they hate free men being free from those selfsame politics & ideologies (>>15728). >tl;dr These types and their cronies/simpathizers are our greatest human threats. I mean to all men everywhere, not just anons on /robowaifu/. That I would willingly use a product of which they boast about this? Heh... :^) How about the incredibly lightweight plug-in-exactly-what-you-need-and-nothing-else Alpine Linux? https://www.alpinelinux.org/ Actually, I'm basically opposed to using Linux in general. If we have to use a full-blown OS at all, then I'd much, much prefer OpenBSD. https://www.openbsd.org/ But hopefully, we won't need to use anything more than a 'barely above the raw metal' approach similar to what I just touched on with RobowaifuDev. OTOH, I realize this is a progressive effort spanning years of time. Pragmatics will require interim compromises until we obtain the funding needed to devise robowaifu-hardened systems of our own. >Good to see the software team working together. Authentication and isolation principles will indeed be important. Indeed it is good! I think RobowaifuDev's CUI (command user interface) is a brilliant conception tbh. I hope we manage many more back-and-forths between us ITT. >=== -minor sp, grmr edit -add 'years of time' & 'hardened systems' cmnts

>>16277 >>>Hi, I'm currently not part of the specific MaidCom project >>Well, please join up! (>>15486) Hey, you can't expect us to carry all the load, right!? :^) Sorry, I'm working on my own project, but I want to keep it compatible where possible and also to go on sharing ideas. That's why I was writing that.

>>16300 Ahh, I see. Well I wanted to extend the offer to you. :^) I assume your project is robowaifu? If so, good luck with your project Anon. We all hope you'll share your progress with us here on the board somewhere. Cheers.

>>16294 What do the other members think of the Alpine idea? >>16300 As an open source project, your project being compatible with shared ideas is very much welcomed. The more compatible projects there are, the more entrenched our waifu standards become. On that note, if you have any questions, want any advice, or want to know any dimensions to ensure compatibility, feel free to ask.

Some interesting ideas that could help us. https://hackaday.com/2022/05/18/3d-printed-linear-actuator-is-cheap-and-strong/ https://hackaday.com/2022/05/18/natural-language-ai-in-your-next-project-its-easier-than-you-think/ >=== -minor fmt edit

>>16308 Thanks for the NLP HaD link Anon.

>>16306 >What do the other members think of the Alpine idea? Never used it before but it looks pretty good.

>>16313 I thank it is wise to use the lightest, most specialized operating system possible. I might even suggest making our own custom distro. >PS testing trip

>>16315 Alright, tripcodes look stupid on this board. Lesson learned.

>>16316 Hello SoaringMoon, Welcome! Are you just visiting or do you plan to work on a robowaifu? We have an Embassy thread (>>2823) if you'd like to introduce yourself. >Alright, tripcodes look stupid on this board. Lol. While I agree that tripcodes aren't so great here, that's entirely due to the programmer of LynxChan and has nothing to do with /robowaifu/ per se. Anyway, make yourself at home Anon.

>Structure material First off, my go to material for the structure would be pvc pipes. They are readily available and rather cheap. They could be interconnected with 3D printed joints. >Tachikoma legs Wheels are good for the inital phase 1 prototype as a way to get around, maybe wheels on 3 or 4 legs. >Simplify the electronics Raspberry Pi and Arduino are rather cheap and readily available, easy to set up but can still accomplish a lot. Raspberry Pi is compatible with ROS; http://wiki.ros.org/ROSberryPi Its preferable as it takes a lot less space than a laptop The cables could potentially be run through the pvc pipes >3D printing The hands, face and structure joints should preferably be 3d printed or injection molded These are my initial ideas, I kind of skimmed the thread so I might not be fully up to speed on the current status but I get the gist of it. I'm okay with coding but leave that to others with more experience for this project

>>16356 >PVC pipes I fully welcome and will help with the parallel development of a version based on PVC pipes. The main branch will remain 3D printed. >Raspberry Pi If you know of a place to get them near MSRP, please do share as I've only seen the sky high scalped prices recently. For now, cheap used laptops running ROS on Alpine Linux is the cheaper and more accessible option. I would have liked to make her based on a small cheap SBC if it was sensible. >Injection molding I fully intend to make molds for much of MaidCom's parts to be able to sell kits and enable others to do so as well with permission from the group. Thanks for your input Hik, glad to have you on the team

>>16360 My concern is that it may take a long time to print every structural part for a 1 meter version (if that's what we're going for) but if that works then its fine. I'm not sure about the meshes In my area, even the latest model of Raspberry Pi (4b) is 5 times cheaper than the very cheapest laptop. I don't know about used ones. My old laptop is incredibly slow to start. The Raspberry Pi has pins (GPIO), so it should be easy to connect up to control stuff. I'm currently starting a project to test that out. Were you Kiwi before? Your pic and the fact you have a name resembling that reminds me of someone from New Zealand I've sometimes chatted with

>>16361 Meshtegrity allows for high speed printing of very large structures with minimal assembly. I'm still developing the technique. Expect more examples within a week as I've recently made some breakthroughs worth sharing but design takes time. I'm in the process of designing a meter tall doll that should be easily printable as a demonstration. >Are you Kiwi? Indeed I am old friend, I changed my name to distance myself from existing entities. Y is because I'm a major fan of Clockwork Planet and in that series, Y is a man that created robot woman that changed the world.

>>16362 > I changed my name to distance myself from existing entities No, It's because he is an edgelord who will take advantage of generous anons and flake as soon as you put your foot down and expect him to do what he said he'd do. Like he did with both Madoka.mi and Pandora. >>15331

>>16442 I share your weariness with Canonical. From what I understand, ROS is bloated and inefficient but, in a way that's supposed to make it easy for the lay-man to use. I'm not the biggest fan personally but, the other members seemed interested. I had no idea it was so bad. Do you think it would be worth going for a different framework then? An open invite for anyone to offer alternatives. Thus far the software is going to be Alpine Linux, we still need a framework for our software that's fast, light, extensible, and ideally FOSS. ROS was the choice but, is now in contention due to its flaws which could be detrimental to the project. >=== -patch crosslink to relocated post

>>16388 I mean, I'm actually also wary of Canonical because of stuff like ads in the MOTD https://news.softpedia.com/news/canonical-under-fire-for-putting-ads-in-the-ubuntu-motd-530372.shtml, but I mean I'm wary of ROS' way of doing things, their way of writing C is misguided, their way of writing portable programs is just going to lead to more unnecessary and lower quality work too (#ifdefs for every platform), and it only took me skimming 2 files to find a buffer overread in code that shouldn't exist (turns out that extra byte can be beyond the end of the buffer in some cases, I already sent a PR). I don't believe they have the minimal competence necessary to write a working system. Alpine is probably the best choice as far as distros go, but we don't have to be married to a distro or even Linux. It's not too hard to make a program portable and even if the program is ported to a system nobody uses, that will help with finding a bug sooner or later. OpenWRT can produce even smaller installs than Alpine due to supporting root on squashfs (a compressed, read-only filesystem) and being more customizable (i.e. it's easier to cut out unnecessary parts) which helps with cost cutting and anything with less parts is more reliable. The whole setup should be portable to both either way because you can't use OpenWRT as a dev machine. I think Linux is the best free Unix system for real time stuff, I've used quite a few and ported programs to all of them. NetBSD is worth a try too. For now, it would be best to revisit all the robotics frameworks and use the best one. Bit by bit, if any component turns out to suck, it can be replaced. This is more work but actually a good thing, as it's hard to gauge what the programming interfaces should look like until after you use them, so we can mooch off from the fact that tools for doing what we need to do already exist, and then we can use the experiences acquired through hindsight to replace them after seeing what they do well and what they do badly. What I think is the best design is to simply write portable programs. Let the operating system be your framework for providing an unified interface to all sorts of hardware. Don't use a custom allocator, if it turns out the system's allocator is bad for real time, then replace the system's allocator, that way it affects not just the robotics-related programs but also the entire rest of the system, all without writing any extra code to add an allocator parameter to functions. For portability between operating systems, create a library that abstracts the operating systems. This design works rather well, we already have this for instance with audio: operating systems each implement their own drivers for audio devices and their own unified APIs for operating on all those devices, and people came along and wrote a libraries like OpenAL for doing audio on many operating systems. Ideally, there would be a library for moving arms, another for speech, another for sensors, and so on. This facilitates development, as it's easier to complete smaller pieces, changes to one component do not affect others, and pieces can be developed independently.

>>16391 Thanks for your input. I believe Chobitsu has mentioned portable libraries before. Would like to hear more from the other members who specialize in software, this could go somewhere promising.

>>16366 Lol, chillax bro. Your own crosslink shows conclusively that Kiwi did in fact apologize to you. Along with him, I hope you'll accept that. We all have room to grow here, right Anon? :^)

>>16077 >>16163 Great stuff Meta Ronin. Hope your trip is going well. Godspeed Anon, look forward to hearing from you again soon.

>>16360 Gumi a cute! I still think papercraft may have some place for the poorfag Anons out there Kywy. If we can do something along the lines of Indian Foamcore Anon (>>10315) using paper + an RPi + a few MC + a few cheap servos I think that would greatly, greatly expand the potential reach of moebot/fairybot Headpat Waifus :^)

>>16395 >a few MC <just realized the acronym conflict ITT Lol, MC==microcontroller :P

Kywy, Anon just posted a video clip that could have a potential for our meshtegrity approach for robowaifus: > (>>16415 >Tendon-driven leg -related)

>>16374 ROS has a lot of "documentation" but it actually says very little. I only found the source code because I looked at the Ubuntu compilation instructions which suggested adding a source repository to Ubuntu and the repository was hosted on Github. I'm wary of that organization. I jumped on the source code of one of their C projects and I see a load of useless wrappers around stdlib functions https://github.com/ros2/rcutils/blob/master/src/strcasecmp.c https://github.com/ros2/rcutils/blob/master/src/strdup.c Every line of code has a cost, adding lines of code to add argument checking to the callee isn't worth it. Programmers will have to lose time learning those wrappers, using them will tie programs to ROS, and they don't actually provide any benefit: you still have an error you have to check if you pass null pointers to those stdlib wrappers. The other thing that code does is let the caller specify the memory allocator. I doubt they found an use for a custom memory allocator in their stdlib wrappers. Most likely they're just losing memory and performance by adding more parameters and layers of pointers to dereference to functions. If you check at the callee, you still have to check at the caller, because then you have to check if the callee returned error. Worse, the errors are only going to pile up, and you'll have to come up with increasingly complex mechanisms to signal what kind of error happened. As errors from one part of the program are propagated to increasingly distant places, it will become impossible to handle them. If there is no way to signal what kind of error happened as is the case here, error checking paradoxically becomes impossible because someone added error checking to a function. If you check at the caller, the callee doesn't have to check anything, and every function it passes the argument to doesn't have to do any checking either. The errors aren't allowed to snowball, keeping error checking to a minimum, and errors are only checked where they might be acquired, keeping them close to their source. All of this without letting any error go unchecked. This is also way less lines of code, so it results in less code to maintain, smaller binaries, and less chances of bugs cropping up because you can't have bugs if you don't have code. Errors should be checked where they might be acquired. Also, type names ending with _t are reserved by POSIX: creating one such type is UB, though it's unlikely to cause trouble. And this memcpy call https://github.com/ros2/rcutils/blob/master/src/strdup.c#L52 copies 1 extra byte unnecessarily. I would send patches to remove all that stuff to them but I doubt they'd accept the patches. Someone decided that poor design was the design for him. === >note: This is relocated ITT, and technically belongs above this post (>>16388)

>>16231 How are you doing, Ricardo? You still with us bro? Just checking up on you, seems like it's been a couple weeks since the team has heard from you. Cheers.

>>16394 Thank you and not so much. My connection got cancelled due to freak snow and I was stranded in Denver for 4 days. Made the most of it but only the other night just arrived back home and still have the remainder of a full workweek. What can I say when it rains it pours (snows?)

>>16484 4 days? Wow, that sucks. Anyway, glad you're back safe and sound Meta Ronin.