/waifu energy source general/ What do you think that our waifus will use for energy?And how much energy it needs to use?From my rough calculations if will need about 2kw for the computer plus 500w for the mechanical part(although I am not sure about the last part because I am not very familiar with the mechatronics ). Surely we don't want to use something like an engine because of the noise ,vibrations and the exhaust.The current state of the battery is not suitable for our goals because of the low energy density (energy per square meter).I think that PEM battery will be a good choice because of the lack mechanical parts , huge energy density , the energy is in the form of electricity.The only downside , for now , is the fact that the PEM layer is VERY expensive ,at least for now . What do you think?What kind of energy source our waifus will use? >=== original Batteries & Power thread >>23

Post your prototypes and failures. We fail until we win. From now on with even more madness, while the prototypes are starting to look cute and have extras. Don't forget looking through the old threads here >>418 and here >>18800 to understand how we got to where we are now.

Decided it may be best to place my 3D digital modelling efforts in a separate thread to my work on 'Elfdroid Sophie'. I think this thread will still belong under "Personal Projects". At the moment the 3D modelling begins over on her thread: >>11644 >>11657 I'm using some source material from Masamune Shirow's 1987 OVA "Black Magic - M66" (which itself was based off his 1983 manga). However, as a child of the late eighties/early nineties, I loved 'Transformers', and I was also a big fan of the 'Heavy Gear' series (similar to MechWarrior), and Armored Core. So I often get the urge to create battle-ready robowaifus, but I can only create them virtually. Because obviously I cannot get hold of machine-guns, explosives, tank cannons, and rocket launchers IRL. Good thing, too, since if I were given access to live ammunition I would almost certainly blow myself into a flying streamer of giblets. But I digress. This thread may also be a good place for any equally deranged anons who wish to post images of military-grade robowaifus, either found online or their own creations? --- >lock cf. (>>30234)

Here we have Maslow's hiearchy of needs. A psychological theory that basically breaks down what a man needs and what he can seek out in life. This seems like a good framework to identify what niche your robowaifu can address in her function, and how exactly to accomplish that. I think the third tier up is what most of us seek from a robowaifu. No matter how inert your robowaifu is in function, even motionless plastic can give you a sense of connection if you project a personality onto it. What do you think? Does Maslow's hierarchy of needs as a theory relate to you and your projects? Is there anything to this at all?

Welcome all Nandroids fans to the Emmy thread, for discussing and posting about EtR. Please refrain from posting off-topic or non-Nandroid related things. --- Also, be sure to check out Emmy-Pilled's project thread! (>>25306) >=== -minor edit -add project crosslink

I realize it's a bit grandiose (though probably no more than the whole idea of creating a irl robowaifu in the first place) but I want to begin thinking about how to create a working robowaifu 'brain', and how to create a special operating system to run on her so she will have the best chance of remaining an open, safe & secure platform. OS Language Choice C is by far the single largest source of security holes in software history, so it's out more or less automatically by default. I'm sure that causes many C developers to sneer at the very thought of a non-C-based operating system, but the unavoidable cost of fixing the large numbers of bugs and security holes that are inevitable for a large C project is simply more than can be borne by a small team. There is much else to do besides writing code here, and C hooks can be generated wherever deemed necessary as well. C++ is the best candidate for me personally, since it's the language I know best (I also know C too). It's also basically as low level as C but with far better abstractions and much better type-checking. And just like C, you can inline Assembler code wherever needed in C++. Although poorly-written C++ can be as bad as C code in terms of safety due to the necessity of it being compatible with C, it also has many facilities to not go there for the sane coder who adheres to simple, tried-and-true guidelines. There is also a good C++ project already ongoing that could be used for a clustered unikernel OS approach for speed and safety. This approach could save drastic amounts of time for many reasons, not the least of which is tightly constrained debugging. Every 'process' is literally it's own single-threaded kernel, and mountains of old-style cruft (and thinking) typical with OS development simply vanishes. FORTRAN is a very well-established language for the sciences, but a) there aren't a lot of FORTRAN coders, and b) it's probably not the greatest at being a general-purpose language anyway. I'm sure it could be made to run robotics hardware, but would probably be a challenge to turn into an OS. There are plenty of dujour SJW & coffee languages out there, but quite apart from the rampant faggotry & SJWtardism plainly evident in most of their communities, none of them have the kind of industrial experience and pure backbone that C, C++, or FORTRAN have. D and Ada are special cases and possibly bear due consideration in some year's time, but for now C++ is the obvious choice to me for a Robowaifu OS foundation, Python probably being the best scripting language for it. (1 of 2) >=== -fmt cleanup

(Original thread >>406) Kiwi back from the dead with a thread for the discussion of actuators that move your waifu! Part Two! Let's start with a quick refresher! 1. DC motors, these use a rotating magnetic field created through commutation to rotate a rotor! They're one of the cheapest options and are 30 to 70 percent efficient usually. The bigger they are, the more efficient they tend to be. 2. Brushless motors, these use a controller to induce a rotating magnetic field by turning electromagnets on and off in a sequence. They trend 60 to 95 percent efficiency 3. AC motors, Though there are many different type, they function similarly to brushless motors, they simply rely on the AC electricity to turn their electromagnets on and off to generate their field. Anywhere from 15 to 95 percent efficiency. 4. Stepper motors, brushless motors with ferrous teeth to focus magnetic flux. This allows for incredible control at the cost of greater mass and lower torque at higher speeds. Usually 50 to 80 percent efficient but, this depends on control algorithm/speed/and quality of the stepper. 5. Coiled Nylon Actuators! These things have an efficiency rating so low it's best to just say they aren't efficient. What they are though is dirt cheap and easy as heck to make! Don't even think about them, I did and it was awful. 6. Hydraulics! These rely on the distribution of pressure in a working liquid to move things like pistons. Though popular in large scale industry, their ability to be used in waifu's has yet to be proven. (Boston Dynamics Atlas runs on hydraulics but, it's a power guzzler and heavy) 7. Pneumatics, hydraulics lighter sister! This time the fluid is air! This has the advantage in weight. They aren't capable of the same power loads hydraulics are but, who wants their waifu to bench press a car? 8. Wax motors, hydraulic systems where the working fluid is expanding melted parafin wax! Cheap, low power, efficient, and produce incredible torque! Too bad they're slow and hard to control. 9. Explosion! Yes, you can move things through explosions! Gas engines work through explosions! Artificial muscles can be made by exploding a hydrogen and oxygen mixture in a piston, then using hydrolysis to turn the water back into hydrogen and oxygen. None of this is efficient or practical but, it's vital we keep our minds open. Though there are more actuators, most are derivatives or use these examples to work. Things like pulleys need an actuator to move them. Now, let's share, learn, and get our waifu moving! >--- < add'l, related links from Anon:

So I'm thinking about design and realize some mistakes I made. There is likely no better short cut to advancing design than these fundamental principles as stated by Elon Musk. 1. Make The Requirements Less Dumb “Step one: Make the requirements less dumb. The requirements are definitely dumb; it does not matter who gave them to you. It’s particularly dangerous when they come from an intelligent person, as you may not question them enough. Everyone’s wrong. No matter who you are, everyone is wrong some of the time. All designs are wrong, it’s just a matter of how wrong,” explains Musk. 2. Try And Delete Part Of The Process “Step two: try very hard to delete the part or process. If parts are not being added back into the design at least 10% of the time, [it means that] not enough parts are being deleted. The bias tends to be very strongly toward ‘let’s add this part or process step in case we need it’. Additionally, each required part and process must come from a name, not a department, as a department cannot be asked why a requirement exists, but a person can,” says Musk. 3. Simplify Or Optimize “Step three: simplify and optimize the design. This is the most common error of a smart engineer — to optimize something that should simply not exist,” according to Musk. He, himself, has been a victim of implementing these steps out of order. He refers to a “mental straightjacket” that happens in traditional schools where you always have to answer the question regardless of whether the premise makes any sense at all. 4. Accelerate Cycle Time “Step four: accelerate cycle time. You’re moving too slowly, go faster! But don’t go faster until you’ve worked on the other three things first,” explains Musk. Here he uses another example of how these steps should occur in order. During a wrongheaded process you should simply stop, not accelerate. He says, “If you’re digging your grave, don’t dig it faster.”

The biggest hurdle to making quick progress in AI is the lack of compute to train our own original models, yet there are millions of gamers with GPUs sitting around barely getting used, potentially an order of magnitude more compute than Google and Amazon combined. I've figured out a way though we can connect hundreds of computers together to train AI models by using gradient accumulation. How it works is by doing several training steps and accumulating the loss of each step, then dividing by the amount of accumulation steps taken before the optimizer step. If you have a batch size of 4 and do 256 training steps before an optimizer step, it's like training with a batch size of 1024. The larger the batch size and gradient accumulation steps are, the faster the model converges and the higher final accuracy it achieves. It's the most effective way to use a limited computing budget: https://www.youtube.com/watch?v=YX8LLYdQ-cA These training steps don't need to be calculated by a single computer but can be distributed across a network. A decent amount of bandwidth will be required to send the gradients each optimizer step and the training data. Deep gradient compression achieves a gradient compression ratio from 270x to 600x without losing accuracy, but it's still going to be using about 0.5 MB download and upload to train something like GPT2-medium each optimizer step, or about 4-6 mbps on a Tesla T4. However, we can reduce this bandwidth by doing several training steps before contributing gradients to the server. Taking 25 would reduce it to about 0.2 mbps. Both slow and fast computers can contribute so long as they have the memory to hold the model. A slower computer might only send one training step whereas a fast one might contribute ten to the accumulated gradient. Some research needs to be done if a variable accumulation step size impacts training, but it could be adjusted as people join and leave the network. All that's needed to do this is a VPS. Contributors wanting anonymity can use proxies or TOR, but project owners will need to use VPNs with sufficient bandwidth and dedicated IPs if they wish that much anonymity. The VPS doesn't need an expensive GPU rental either. The fastest computer in the group could be chosen to calculate the optimizer steps. The server would just need to collect the gradients, decompress them, add them together, compress again and send the accumulated gradient to the computer calculating the optimizer step. Or if the optimizing computer has sufficient bandwidth, it could download all the compressed gradients from the server and calculate the accumulated gradient itself. My internet has 200 mbps download so it could potentially handle up to 1000 computers by keeping the bandwidth to 0.2 mbps. Attacks on the network could be mitigated by analyzing the gradients, discarding nonsensical ones and banning clients that send junk, or possibly by using PGP keys to create a pseudo-anonymous web of trust. Libraries for distributed training implementing DGC already exist, although not as advanced as I'm envisioning yet: https://github.com/synxlin/deep-gradient-compression I think this will also be a good way to get more people involved. Most people don't know enough about AI or robotics enough to help but if they can contribute their GPU to someone's robowaifu AI they like and watch her improve each day they will feel good about it and get more involved. At scale though some care will need to be taken that people don't agree to run dangerous code on their computers, either through a library that constructs the models from instructions or something else. And where the gradients are calculated does not matter. They could come from all kinds of hardware, platforms and software like PyTorch, Tensorflow or mlpack.

This thread is for the sharing of robo waifu banners. As per the rules, fallow these requirements: >banner requirements: File size must be lower than 500 KB and dimensions are 300x100 exactly. Allowed file formats are .jpg, .png, and .gif. >=== -fmt cleanup