/robowaifu/ - DIY Robot Wives

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

Happy New Year!

Max message length: 6144

Drag files to upload or
click here to select them

Maximum 5 files / Maximum size: 20.00 MB

Captcha
no cookies?
More

(used to delete files and postings)


“Perseverance, secret of all triumphs.” -t. Victor Hugo


AI Design principles and philosophy Robowaifu Technician 09/09/2019 (Mon) 06:44:15 No.27 [Reply] [Last]
My understanding of AI is somewhat limited, but personally I find the software end of things far more interesting than the hardware side. To me a robot that cannot realistically react or hold a conversation is little better than a realdoll or a dakimakura.

As such, this is a thread for understanding the basics of creating an AI that can communicate and react like a human. Some examples I can think of are:

>ELIZA
ELIZA was one of the first chatbots, and was programmed to respond to specific cues with specific responses. For example, she would respond to "Hello" with "How are you". Although this is one of the most basic and intuitive ways to program a chat AI, it is limited in that every possible cue must have a response pre-programmed in. Besides being time-consuming, this makes the AI inflexible and unadaptive.

>Cleverbot
The invention of Cleverbot began with the novel idea to create a chatbot using the responses of human users. Cleverbot is able to learn cues and responses from the people who use it. While this makes Cleverbot a bit more intelligent than ELIZA, Cleverbot still has very stilted responses and is not able to hold a sensible conversation.

>Taybot
Taybot is the best chatbot I have ever seen and shows a remarkable degree of intelligence, being able to both learn from her users and respond in a meaningful manner. Taybot may even be able to understand the underlying principles of langauge and sentence construction, rather than simply responding to phrases in a rote fashion. Unfortunately, I am not sure how exactly Taybot was programmed or what principles she uses, and it was surely very time-intensive.

Which of these AI formats is most appealing? Which is most realistic for us to develop? Are there any other types you can think of? Please share these and any other AI discussion in this thread!
348 posts and 116 images omitted.
>>24677 threads already share the same file descriptors and memory they only get a new stack, theres no reason to do this unless you want to literally dump the entire file to ram which does make reading faster but you cant say its using less memory, theres no hidden trick to time complexity where you can magically get faster reads using less memory theyre always inversely related and mapping gigantic files that dont even fit in ram will just end up causing excessive page faults and thrashing, theres something clearly wrong with either the claim or the original code
>>24678 OK I'd say just prove it for yourself Anon. The PR is linked above ITT.
>>24686 im not going to read through their code you can just test it yourself, mapping gigantic files bigger than ram with a random access pattern causes ridiculous thrashing, and you can see mapping files reduces the amount of free ram more than double what the io cache uses, pages only perform better when you have the ram to back it up again theres something wrong with their claim or the original code has a bug or is leaking or something, maybe iostream is just tarded who knows heres the test #include <stdio.h> #include <string.h> #include <unistd.h> #include <stdlib.h> #include <fcntl.h> #include <time.h> #include <sys/mman.h> #include <sys/stat.h> int with_io( int fd, size_t items ) { char buf[8]; int youWillNotOptimizeMeAway;

Message too long. Click here to view full text.

>>24689 Thanks Anon. Seems the thread is autosaging now. OP if you're still here, time for another thread please :^)
NEW THREAD (Cognitive Architecture): >>24783 NEW THREAD (Cognitive Architecture): >>24783 NEW THREAD (Cognitive Architecture): >>24783 NEW THREAD (Cognitive Architecture): >>24783 NEW THREAD (Cognitive Architecture): >>24783

Open file (80.65 KB 980x550 0705060925488_1_jpg.jpeg)
Ricky Ma General Robowaifu Technician 09/12/2019 (Thu) 03:00:06 No.153 [Reply]
Can we talk about the man who DID IT? Seriously he did it, he achieved our dream and started a project to help all those who want their own robowaifu, then, why does not anyone support him in TWO FUCKING YEARS?
9 posts and 2 images omitted.
>>153 can anyone explain how he made the mask/face? i want one for a robowaifu im designing
>>21561 >can anyone explain how he made the mask/face? i want one for a robowaifu im designing Thread on faces >>9
>>21532 That's good news to hear NoidoDev, thanks! >tfw his robowaifu's in her 6th year Nice, didn't realize that tbh. >>21561 He wrote a full book on his project Anon. I imagine he probably explains the process in that.
He did it again, with Wonder Woman now: https://youtu.be/l-p26hSkOhc
>>24613 Neat! Godspeed Ricky Ma. :^) Thanks for the headsup, NoidoDev.

Hold onto your papers Robowaifu Technician 09/16/2019 (Mon) 05:59:19 No.269 [Reply]
It's hard to keep track of all the developments that are happening in artificial intelligence and related areas. Perhaps we could share our favourite research papers to get a better feel for all the progress happening and what we need to do next to make robowaifus a reality.

I'm mostly focused on general intelligence but this thread can be for anything that has captured and held your attention for long periods of time, whether in speech synthesis, creativity, robotics, materials, or anything else.
34 posts and 6 images omitted.
>>24256 >If true, this'll probably solve the robowaifu battery problem. If true, and also 'super easy' to manufacture, as you indicate, will revolutionize many things in the world. Robowaifus may get much lighter also, due to much slimmer, much lower-mass actuators. OTOH, it's unlikely IMO that the GH will ever allow this out onto the open market anytime soon. There are far too many vested interests this would effectively collapse. Even if true, it likely to be scuttled (as least to the public's eye) 'Oh sorry guise, we were off by a decimal point LOL!'. Watching with great interest. :^)
>>24256 >>24258 Figured we might want to keep this here on the board, just for archival safekeeping.
>>24258 This'll help the globohomo with their green energy goals too. Remember the plan to put up solar panels in the Sahara, which would generate enough electricity to meet the demands of the whole world? Well, that was kind of inviable because of the giant transmission losses from transporting electricity over the large distances to MENA and European countries. But this makes its much closer within grasp, although there's still work to be done on the solar panels themselves and energy storage. I too, am watching this with great interest. If we finally get free energy, training and running AI becomes that much cheaper and easier. Also, this might probably help the robowaifu recharging and solar charging part too. One of the downsides of making your robowaifu solar chargable is that the density of charge is very less for solar power, especially on a humanoid body, which will make it either impossible or take a really long time to charge. With this, it's easier to charge way faster and store much more energy. Although, like I said before, there's still work to be done on solar tech before we reach that level. >>24262 yeah, I probably should have done that. The Twitter and Reddit API lockdown has me woondering and goncerned, so I'm downloading as many datasets as I can. This might not be the place to ask, but does anyone have a torrent of the Raiders of the Lost Kek /pol/ dataset? Direct download takes forever.
>>24265 >does anyone have a torrent of the Raiders of the Lost Kek /pol/ dataset? Here's a GPT-J 6B model generated from it. https://archive.org/download/gpt4chan_model_float16/gpt4chan_model_float16_archive.torrent >=== -add comment
Edited last time by Chobitsu on 07/27/2023 (Thu) 02:24:58.
> potential paper -related : (>>24648)

Open file (686.85 KB 2764x2212 Prima_Doll.jpg)
Open file (174.99 KB 720x960 Trash_Press.jpg)
Open file (359.85 KB 1200x675 ChatGPT_hustle.png)
Open file (29.42 KB 622x552 LLaMA02.png)
General Robotics/A.I./Software News, Commentary, + /pol/ Funposting Zone #3 NoidoDev ##eCt7e4 03/06/2023 (Mon) 18:57:17 No.21140 [Reply] [Last]
Anything in general related to the Robotics or A.I. industries, and any social or economic issues surrounding it (especially of robowaifus). === -note: This OP text might get an update at some point to improve things a bit. -previous threads: > #1 (>>404) > #2 (>>16732) >=== -edit subject
Edited last time by Chobitsu on 07/08/2023 (Sat) 13:10:41.
351 posts and 84 images omitted.
Open file (329.39 KB 850x1148 Karasuba.jpg)
Open file (376.75 KB 804x702 YT_AI_news_02.png)
Open file (423.49 KB 796x706 YT_AI_news_01.png)
Suggestions for the new thread pics. I picked someone from Prima Doll again, but maybe the new tradition should rather be to pick one from the newest good related anime. I think this might still be Prima Doll. At least the newest I've seen. I was thinking about using the girl from ATRI. Maybe next time. The other idea here was the relation between reading the news and having some coffee. In that case we would mostly be stuck with Prima Doll, at least if the girl serving is also supposed to be a robot.
>>24077 They look fine Anon. I'm perfectly fine with animu grills as the opener pic. I'd personally suggest leaving your options of choice wide open. Just that the opener have great waifu appeal, which your choice here does. >tl;dr Go for it NoidoDev! :^)
Open file (449.75 KB 2048x2048 1687959908288867.jpg)
>>24080 Thanks. If people have suggestions for future opener pics I'm listening. Picrel might be it at some point. But currently it's hot in many places, so the pic of Karasuba with some iced drink fits very well.
New Thread New Thread New Thread >>24081 >>24081 >>24081 >>24081 >>24081 New Thread New Thread New Thread
>>24082 > Picrel might be it at some point. I think that's fine tbh.

Open file (363.25 KB 1027x1874 MaidComRef.png)
MaidCom Development Kiwi 03/16/2022 (Wed) 23:30:40 No.15630 [Reply] [Last]
Welcome to the /robowaifu/ board's project. Together, we will engineer a modular robot that will serve and provide companionship to their Anon faithfully. See picrel for details on the current design. This robot will begin with a basic maid robot then move forward towards more capable robots with functionality approaching Chii/2B/Dorothy. First goal is to have a meter tall robot which functions as a mobile server bearing an appearance that approximates her owners waifu. This should be completed by December 2022 with further major updates happening yearly until Anons can build a PersoCom class robot with relative ease and affordability.
347 posts and 172 images omitted.
>>23238 Because polygons are triangles. When you delete vertices you're left with pointy triangles. :^)
>>23391 Neat. Thanks.
Open file (64.61 KB 715x1365 New.jpg)
>>23393 New one, going to be Copyleft once finished.
Seems its time for a new thread Kiwi
NEW THREAD NEW THREAD NEW THREAD >>29219 >>29219 >>29219 >>29219 >>29219 NEW THREAD NEW THREAD NEW THREAD

/robowaifu/meta-7: Hanging down at 7-eleven Chobitsu 02/18/2023 (Sat) 11:00:31 No.20356 [Reply] [Last]
/meta, offtopic, & QTDDTOT General /robowaifu/ team survey (please reply ITT) (>>15486) >--- Mini-FAQ >A few hand-picked posts on various /robowaifu/-related topics -Why is keeping mass (weight) low so important? (>>4313) -How to get started with AI/ML for beginners (>>18306) -"The Big 4" things we need to solve here (>>15182) -HOW TO SOLVE IT (>>4143) -Why we exist on an imageboard, and not some other forum platform (>>15638, >>17937) -This is madness! You can't possibly succeed, so why even bother? (>>20208) -All AI programming is done in Python. Why are you using C++ here? (>>21057, >>21091) -How to learn to program in C++ for robowaifus (>>18749)

Message too long. Click here to view full text.

Edited last time by Chobitsu on 04/09/2023 (Sun) 12:12:18.
361 posts and 77 images omitted.
Here my current plan for AI hardware: - I ordered a used K80 with 2x12 GB recently, a used one of course, for 100$/95€ shipping included. It's an old GPU, only supported by older CUDA versions and might not run quantified models. Uses much energy, but it's two GPUs with 12GB each. I plan to pair this one after a while with a RTX3060 (12GB, 300€ used or 400€ new I think) in one home server. Context: https://technical.city/en/video/Tesla-K80m-vs-GeForce-RTX-3060 - That one, will then run my 12GB models. For fine tuning, or models which don't run on the K80, I would use the 3060. I don't know yet if I can somehow joint them together and use 3x12GB through the bus. It just seems to need some software support in these programs for running models at home. - I plan to use online services like Colab to learn about how to run these things, but have the K80 for more private data and learning how to do these things at home. - Then I'll get some SBCs, most likely Orange PI's, which can run small models of Whisper (speech regocnition). Also, another small home server with a Intel Arc380 (140-160€), which is fast enough to run the big and better model of Whisper at the speed of one fast human speaker. It does this quite energy efficient. These devices will not run anything else, for security reasons, and be connected to microphones which will be always on. The server will receive the audio through the SBCs from all rooms using the home network (likely on a VPN using Tinc). All of them will send the transcripts to some server in my network which can then decide how to respond. Most likely filtering first for which data is more sensitive than others. - Some small device, like a Raspi, will maybe handle responses based on AIML or using some small model. - Questions which don't contain private information might be send to OpenAI or another service. - The next step up will be getting a M40 (180€) and then a used RTX3090 (700-800€ right now I think), putting them in another home server at some point. Of course I might use this one for gaming till I get even the next GPU. These can handle the models which need 24 GB. The 3090 will do the fine tuning if I want to do that, since it has more power, while the M40 doesn't need as much energy. Context: https://technical.city/en/video/GeForce-RTX-3090-vs-Tesla-M40-24-GB - Then the next step might be getting a AMD XTX (1k-1.2k€) if it's supported well enough for AI by this time. I can use this one for gaming and then put the 3090 in a home server with the M40. If it's possible to combine cards using PCI express, then it might be interesting to think about getting another XTX later, and have 48GB vRAM. - But I hope that either Intel or AMD will come out with a prosumer or consumer card for AI at home, which is rather slow but has 48GB and is not too expensive. (If you buy K80 or M40 on Ebay make sure not to buy the 12GB versions by accident while only looking at the price. They aren't much cheaper. K80 should have 2x12GB and the M40 24GB.)
>>23346 I hope the K80 works for you. I was thinking of getting two but the support for them seems abysmal. They used to be $200 used before shipping. Colab isn't what it used to be either. The free version will boot you off in 30 minutes sometimes or a few hours into training with Pro unless you pay big for compute credits. You're much better off running your own JupyterLab notebook or renting an instance off vast.ai or runpod.io if you don't have access to a GPU.
>>23351 >support for them seems abysmal. I think you need old versions of the software, but I also remember some people taking care of that, to support old GPUs. I might need to compile some of it myself, though. I hope it works out, but the risk isn't very high. >They used to be $200 used before shipping. They're down to $60-70 before shipping now. Some recommend to go straight for the M40, which is much newer, but $120-130 before shipping. >JupyterLab notebook or renting an instance off vast.ai or runpod.io if you don't have access to a GPU. Right, I forgot about those while writing this.
>>23346 Good luck, NoidoDev!
NEW THREAD NEW THREAD NEW THREAD (>>23415) (>>23415) (>>23415) (>>23415) (>>23415) NEW THREAD NEW THREAD NEW THREAD

Open file (3.22 MB 3120x4160 Hello_Anons.jpg)
Sophie Bot STL Files Uploaded Robowaifu enthusiast 07/15/2020 (Wed) 20:08:20 No.4198 [Reply]
I need to sort out her CAD files more before uploading them, but the .STLs are ready. Link to Google Drive shared folder: https://drive.google.com/drive/u/0/folders/1xWilMfWDZnrt30E1Uw7hlWe6JmaigKQF
15 posts and 2 images omitted.
not sure what this link was, but without any context and using a url shortener im assuming its cp if this was something on topic, my apologies, but with all these cp bots trying to advertise here we have to be careful
Edited last time by gator on 06/06/2023 (Tue) 15:02:46.
>>22974 Its literately google drive
>>22974 I take it you rm'd a link for us? That's fine if it was suspicious looking, thanks! :^) So, if you were a legitimate poster from our board, please at least explain what a link is, if it's otherwise unclear to an uninitiate. Thanks. >>22975 >Its literately google drive Not having seen it, I can't confirm this one way or another. But I'm uncertain that 'it's G*ogle' is a solid validation Anon.
>>22975 If it was, my bad, since it was behind a link shortener I couldn't tell. Just a single line of text explaining what it was would have been enough for me to tell it was human though. >>22978 Yeah just a single link run through a link shortener, many of which we've outright filtered at this point simply because of how badly the cp posters abuse them. While we obviously won't ban link shorteners, if you're gonna use them making clear it's posted by a human is a good idea, since otherwise it looks nearly identical to the cp bots.
Edited last time by gator on 06/06/2023 (Tue) 22:30:43.
>>22979 Got it. Thanks Gator. :^)

Embedded Programming Group Learning Thread 001 Robowaifu Technician 09/18/2019 (Wed) 03:48:17 No.367 [Reply] [Last]
Embedded Programming Group Learning Thread 001

Greetings robowaifufags.
As promised in the meta thread, this is the first installment in a series of threads where we work together on mastering the basics of embedded programming, starting with a popular, beginner-friendly AVR 8-bit microcontroller, programming it in C on linux.

>why work together on learning and making small projects that build up to the basis of a complete robot control system instead of just posting links to random microcontrollers, popular science robot articles, and coding tutorials and pretending we're helping while cheerleading and hoping others will do something so we don't have to?
Because, dumbass, noone else is going to do it. You know why in emergency response training they teach you to, instead of yelling "somebody call an ambulance!," you should always point to or grab someone and tell that person to do it? Because everyone assumes someone else will do it, and in the end, noone does. Well, I'm talking to YOU now. Yeah, you. Buy about 20 USD worth of hardware and follow the fuck along. We're starting from zero, and I will be aiming this at people with no programming or electronics background.

>I suppose I could get off my ass and learn enough to contribute something. I mean, after all, if all of us work together we can totally build a robowaifu in no time, right?
No, the final goal of these threads is not a completed robowaifu. That's ridiculous. What we will do though, by hands-on tackling many of the problems facing robot development today, is gain practical and useful knowledge of embedding programming as well as a more grounded perspective on things.

>so we're just going to be blinking a bunch of LEDs and shit? lame.
Not quite. We will try to cover everything embedded here: basic I/O, serial communications, servo/motor control, sensor interfacing, analog/digital conversion, pulse-width modulation, timers, interrupts, I2C, SPI, microcontroller-PC interfacing, wireless communications, and more.
125 posts and 16 images omitted.
>>22890 >pages are now execute only or no execute. For the uninitiate you could say that this helps keep corrupt (ie, 'hacked') code from executing. So Nagisa, off-topic; but what do you think would be involved in a practical sense of creating a robowaifu system based on OpenBSD? Remember that we have several hard-real-time constraints (though most isn't under this restriction). By this question I mean primarily her onboard systems, not just a home server setup.
>>22891 OpenBSD is the worst OS for real time among the ones I've used, its task scheduler has really bad fairness guarantees and big locks in the kernel can cause most of the kernel's functionality to block while one program uses it. The audio system defaults to 160ms latency and still gets audio drops, on Gentoo Linux I could get ~17-19ms with ALSA and no realtime tweaking. We all have much to gain from portability though. OpenBSD's strong memory protections can catch memory bugs that go unnoticed on every other OS. And while doing that, it's still fast enough that you can actually run your program and test it, you can't use e.g. Valgrind on a typical video game because then it will run at sub-1fps. OpenBSD's pthreads implementation catches destroying mutexes with waiters, mpv has that bug all over, Linux libcs don't do this. This goes for other platforms too, for instance, the diet libc for Linux warns when you use a libc function that makes binaries large, it's good for when you're optimizing binary sizes. I've fixed bugs in programs that I found because I ported the program to MSVC and Microsoft's compiler correctly warned where no other compiler warned.
I'm going to make the flashing leds either tomorrow or the day after tomorrow again.
>>22892 Thanks Anon! Yes that makes sense about realtime. I'm sure we'll figure things out in the end, but r/n it's a big giant puzzle. >We all have much to gain from portability though. Excellent point. It's certainly something to strive for in all our code, to the extent feasible. Certainly during R&D prototyping, I'd say it's a high priority to attempt testing on a wide array of systems. >I ported the program to MSVC and Microsoft's compiler correctly warned where no other compiler warned. They do have a really good debugger system. Ofc some would claim they needed to heh. :^)
>>22895 Please let us know how it goes Anon! :^)

Robowaifu references Anonymous 09/09/2019 (Mon) 00:09:49 No.1 [Reply] [Last]
My favorite robowaifu is Chii. I'd like to see yours.
114 posts and 116 images omitted.
>>21953 There's an amazing variety of cute Emmys!
>>21954 there really is
>>22450 Second image appears to be from a different artist?

R&D General Robowaifu Technician 09/10/2019 (Tue) 06:58:26 No.83 [Reply] [Last]
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)
https://www.seas.harvard.edu/news/2017/02/long-lasting-flow-battery-could-run-for-more-than-decade-with-minimum-upkeep

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.
359 posts and 146 images omitted.
>>22178 Sorry, but I can't work on this. Maybe in two or three weeks.
>>22178 >>22288 That's really good advice Noidodev, it would make for a really good new OP. Maybe the original OP will return in the meantime, but if not, then by all means give it a shot if you're willing! Cheers. :^)
>>22286 That might work. My goal would be making a non electric one. I would need to figure a way to make a clock work movement with enough torque to move the pump and install the self winding system used on rolex for when you move your watch so that it self winds every time robot chan moves.
New thread New thread New thread (>>24152) (>>24152) (>>24152) (>>24152) (>>24152) New thread New thread New thread
>>22032 >fibergrid That has got to be one of the most brilliant ideas ever. You could use a cheap ESP32 CAM Camera Module Kit. They sell them with cameras on them already for $10 USD. Then you have up to 1622×1200 sensor channels. WOW! what a great idea. Do them in a sort of X'Y' grid and then you have what part of a finger and how far up. You could use this for position sensors also. Have a rotating bump or wheel press on an array of fibers. So with a little work you could have every single touch sensor and position sensor in one $10 camera. Some ideas are so good they are just...stupendous and this is one.

Report/Delete/Moderation Forms
Delete
Report