The original thread can be found here: https://trashchan.xyz/robowaifu/thread/595.html --- Welcome to the Lemon Cookie thread, The goal of Lemon Cookie is to create a framework where a synthetic "mind and soul" can emerge through a "LLM as cognitive architecture" approach. This thread exists to collect feedback, ask for help & to document my progress. First I am going to try to give a high level overview of how this cognitive architecture is envisioned and the ideas behind it. I have spent time looking at cognitive architecture work, in the field there is now a consensus on how the mind works at a high level. An important mechanism is a "whiteboard", basically a global temporary memory that all the other systems read in and out of. Then there is different long-term memory systems that react to and add content to the whiteboard. Along with memory pattern matcher(s)/rules work on the content of the whiteboard. A key thing to consider is the difference in philosophy that cognitive architecture projects have, the intelligence is considered to emerge from the entire system. Compare this to LLM agent work where it's considered the intelligence is the LLM. My feelings on the general LLM space are conflicted, I am both amazed and really disappointed. LLMs possess an incredible level of flexibility, world knowledge and coherence. But everything outside of the model is stagnant. It's endless API wrappers & redundant frameworks all slight permutations on RAG & basic tool calling. I will believe that LLMs are misused as chatbots, simply put their pattern matching and associative power is constrained by chat format and shallow tooling. In the Lemon Cookie Cognitive Architecture so far here are the important aspects: 1. Memory is difficult. I do not think there is a singular data structure or method that is able to handle it all, several distinct types of memory will be needed. So far I plan for a PathRAG like system and a "Triadic Memory" inspired system for external associations (this is missing in most LLM solutions). 2. LLM as Kernel, The LLM's context window is the Whiteboard and has a REPL like mechanism. It holds structured data and logic in scripting-like format so it's both LLM & Human readable while staying easy to parse & allows for expressive structured data. The LLM's role will be to decompose data and make patterns and associations explicit as executable statements. 3. The language has to be LLM/CogArch-centric. There is a thousand ""agents"" that give LLMs a python interpreter as a tool. The two need to be more tightly coupled. Scripted behavior via pattern matching, The whiteboard is a bag of objects, this allows for programmable pattern matching (think functional programming like Haskell). It's also important to allow the LLM to observe code execution and to be able to modify state and execution flow. Data in languages have scoping rules, so should LLM context. Etc... I will go into more depth about the language in another post. 4. Another important system is the "GSR" Generative Sparse Representation and it will be a first class language & runtime type, This also needs its own post. But in general I am inspired by two things, "Generative FrameNet" paper where an LLM & an embedding model is used to automatically construct new FrameNet frames. The second source is "Numenta's SDRs"/"Sparse distributed memory" this representation has a lot of useful properties for memory (Please watch the videos under the "What the hell is an SDR?" segment in my links list for an easy introduction.) I think SDR unions & SDR noise tolerance will be especially useful. 5. A custom model, For all of the above to work well, a model will need to be fine tuned with special behaviors. I do want input on this. Baking facts & behaviors into LLM weights is costly, creating bloated models that are hard to run or train (why memorize all the capitals?), while letting authors gatekeep truth and impose "safety" detached from context. Blocking role-play "violence" or intimacy isn't protection: it's authors hijacking your AI companion to preach at you. Externalizing behaviors via whiteboard pattern matching shifts control: stabbing you in-game can be funny, but a robot wielding a knife isn't. Maybe you want intimacy privately, but don't want your AI flirting back at your friends. When put together I think this will be able to host a kind of synthetic "soul", In a living being what we call a personality is the accumulated associations, learned behaviors, beliefs and quirks molded by a unique set of experiences. I hope this will be true for this system too.

>Why organize IRL? This community is great and many individuals are already making progress on their prototypes. However this endeavor is not a one man job and organizing IRL would give better opportunities for collaboration and skill sharing/development. >Where should we organize? I propose we organize within a seven hour radius of Chicago. This would include the major cities of Milwaukee WI, St Louis MO, Detroit MI, Indianapolis IN, Louisville KY, Cleveland OH, Cincinnati OH, Columbus OH, Pittsburgh PA, Nashville TN, and Minneapolis MN. There are plenty of opportunities for jobs and universities in these cities. In particular Chicago has a booming tech industry with Google even moving their HQ to the city and the electronics manufacturing and biotech sectors are pretty good too and Detroit MI has pretty good robotics industry although it might not be the best place to live. Another wonderful thing about this area is that most of these homes have basements that could be turned into workshops. >How would this all be organized I propose a fraternity system. A fraternity would help build community and give us a vehicle to recruit others from STEM and skilled trades (machinists especially) The organization could also host a scholarship to help us build talent. Anons with enough money for a down payment could buy homes in the area and rent to below market rate to anons moving in. Different homes could specialize on different projects and collaborate and share equipment and skills with others nearby. What do you think /robowaifu/?

Robotic control and data systems can be run by very small and inexpensive computers today. Please post info on SBCs & micro-controllers. en.wikipedia.org/wiki/Single-board_computer https://archive.is/0gKHz beagleboard.org/black https://archive.is/VNnAr >=== -combine 'microcontrollers' into single word

Hi anons! After looking at the introductory comment in >>2701 which mentions the use of the MIT licence for robowaifu projects. I read the terms: https://opensource.org/licenses/MIT Seems fine to me, however I've also been considering the 3-clause BSD licence: https://opensource.org/licenses/BSD-3-Clause >>4432 The reason I liked this BSD licence is the endorsement by using the creator's name (3rd clause) must be done by asking permission first. I like that term as it allows me to decide if I should endorse a derivative or not. Do you think that's a valid concern? Initially I also thought that BSD has the advantage of forcing to retain the copyright notice, however MIT seems to do that too. It has been mentioned that MIT is already used and planned to be used. How would the these two licences interplay with each other? Can I get a similar term applied from BSD's third clause but with MIT?

Power & Energy Robots require some form of energy to power them. We need to understand how to store energy in a way that will provide her with all the power she’ll need. To clarify, “energy” is a system's capacity to do work over time. This is measured by Wh, or Watt hour. Closely related is “power” the rate at which work is done. This is measured as W, or watts. As an example, we could have a robot with a 80Wh Lithium Ion battery and two DC gear motors that consume 10W when working. You do not need to rely solely on batteries and motors. We can use other methods of storing energy. This can include compressed fluids, thermal energy, and light, among other things. For instance, glow in the dark paint is useful for storing energy to use at night for safety. Solar panels or a generator can provide power through the energy of long distance nuclear fusion or extracting energy from some reaction. Being part of a robot means we need to consider safety, mass, and volume. How will her energy and power system fit inside her? How will she deal with the mass? What happens when she runs out of energy? How can you minimize her energy use? What alternatives can be used to lower her cost of production and ownership? These rhetorical questions are all important when contemplating how to build a robot.

We want our robowaifus to speak to us right? en.wikipedia.org/wiki/Speech_synthesis https://archive.is/xxMI4 research.spa.aalto.fi/publications/theses/lemmetty_mst/contents.html https://archive.is/nQ6yt The Taco Tron project: arxiv.org/abs/1703.10135 google.github.io/tacotron/ https://archive.is/PzKZd No code available yet, hopefully they will release it. github.com/google/tacotron/tree/master/demos

Alright mathematicians/physicians report in. Us Plebeians need your honest help to create robowaifus in beginner's terms. How do we make our robowaifus properly dance with us at the Royal Ball? >tl;dr Surely in the end it will be the laws of physic and not mere hyperbole that brings us all real robowaifus in the end. Moar maths kthx.

Since we have no thread for hands, I'm now opening one. Aside the AI, it might be the most difficult thing to archive. For now, we could at least collect and discuss some ideas about it. There's Will Cogleys channel: https://www.youtube.com/c/WillCogley - he's on his way to build a motor driven biomimetic hand. It's for humans eventually, so not much space for sensors right now, which can't be wired to humans anyways. He knows a lot about hands and we might be able to learn from it, and build something (even much smaller) for our waifus. Redesign: https://youtu.be/-zqZ-izx-7w More: https://youtu.be/3pmj-ESVuoU Finger prototype: https://youtu.be/MxbX9iKGd6w CMC joint: https://youtu.be/DqGq5mnd_n4 I think the thread about sensoric skin >>242 is closely related to this topic, because it will be difficult to build a hand which also has good sensory input. We'll have to come up with some very small GelSight-like sensors. F3 hand (pneumatic) https://youtu.be/JPTnVLJH4SY https://youtu.be/j_8Pvzj-HdQ Festo hand (pneumatic) https://youtu.be/5e0F14IRxVc Thread >>417 is about Prosthetics, especially Open Prosthetics. This can be relevant to some degree. However, the constraints are different. We might have more space in the forearms, but we want marvelous sensors in the hands and have to connect them to the body.

This thread is dedicated to the study, design, and engineering of a cute face for robots.

I made a generator to generate nandroid images. You can use it in browser, but a desktop version (that should easier to use), will be available. https://soaringmoon.itch.io/nandroid-generator Not very mobile friendly unfortunately, but it does run. I made a post about this already in another thread, but I wanted to make improvements and add features to the software. >If you have any suggestions or ideas other than custom color selection, which I am working on right now, let me know.