# Cognitive Architecture - Separating it from conversational AI is probably impossible, since we need to use it for inner dialog and retrieval of data from LLMs - I'm not sure if optimizations for conversations, like faster understanding and anticipation where a conversation goes, should also go in here or in another thread - We need to approach this from different directions: Lists of capabilities humans have, concrete scenarios and how to solve them, configuration optimizations - The system will need to be as flexible as possible, making it possible to add new features everywhere # Definitions of conscience which we might be able to implement - ANY comment on conscience has to make clear to which definition it refers or make the case for a new one which can be implemented in code (including deep learning) - <list, it's five or so> # List of projects working on Cognitive Architecture or elements of it - Dave Shapiro: https://www.youtube.com/@DavidShapiroAutomator - OpenCog - Some guys from IBM Watson worked on it - LangChain - - ... <there are more, we need a list>

RoMeLa is working on replacing restaurant workers and chefs working for food delivery companies, without using humanoid robots. I think this will be good for developed countries with worker shortages, and also rather wealthy guys who want to live in more rural areas while having something that can prepare a lot of different meals: https://youtu.be/8SsgzCbYqc8 >Introducing Project YORI, a flexible and expandable cooking robot system prototype being developed by RoMeLa in collaboration with Woowa Brothers. YORI stands for “Yummy Operations Robot Initiative” but it also means “cooking” in Korean. >Unlike most other cooking robot systems, YORI is designed to be expandable to cook almost any type of dishes. At this point, YORI can cook steak frites, fried chicken, pasta, and brownies to name a few. With its proprioceptive actuators, the robot can perform tasks that other conventional robot arms cannot, such as kneading dough which requires force control, or tenderizing meat by pounding which requires impact mitigation. Instead of trying to mimic how humans cook, we approached the problem by thinking how cooking would be accomplished if a robot cooks. Thus the YORI system does not use the typical cooking methods, tools or utensils which are developed for humans. For example, the YORI system utilizes unique chemical sensors to make sure the food is cooked to perfection and the ingredients are fresh. The system does not have hands either - it uses custom tools for each tasks which are automatically installed at the end of the robot arm via a tool changer mechanism.

>>25529 but i pay for the service, you cant verbally abuse a machine into a discount for not understanding your special definition of what medium rare means

>>25523 I can’t understand why retards hype worst Korea so much. It easily eclipses even the west in terms of cruelty towards men and it’s just an American copy. Imagine circumcising your sons because sherrers do It

>>25530 That's awful socially destructive behavior. If you seriously wanted to keep that up, then you would have to pay for it through taxes, since people below a certain income cost more than they pay taxes. Robots are the solution. If you want cheap food, make it yourself at home.

>>25557 I might not know for certain, but I'm pretty sure that's a joke.

>>25550 Lol. That actually was attempted before, I believe. My browser cookie saved me. :DD

>>25550 8Banned for 1 second for cringe :^) Test worked

>>25553 Haha. I actually tried a 1-second before, but somehow either I screwed it up, or it doesn't work. It turned out as a perma. :P I've settled on 1-minute ( 1m , lowercase) now for jest bans.

>>25554 I'll keep that in mind, thank you for the advise.

>>25555 >digits You can always lift bans on the bans page as well. Cheers. :^)

Now that I've taken some time and come back to look at my ideas, it's occured to me that I may have been operating under some faulty assumptions and less than adviseable ideas. First and foremost, I've kinda just been assuming that Orchid's power supply would need to be somewhere inside of her frame, but it really doesn't need to be. I mean, she's already going to be on a cable harness, so the only real loss there'd be from moving the power supply out of her would be a thicker cable harness and having to do a bit more math to account for voltage drop. And if making that work with DC motors ends up being too much of a pain in the ass for whatever reason, I can just switch to AC motors instead. I could probably just move those motor controllers out as well, and have those hooked up to a microcontroller that's connected directly to the server. If I take all that out of the equation, then the only heat producing objects will be the motors themselves, and a few electronic components. Practically a rounding error in comparison, especially since none of the motors will be operating full-time. This way, I can consider going back to a design with a higher number of motors. Second, I've been using way too many hinges and cramming too many small components into the joints, when I can just take the idea I was already planning on using for the head, and copy-paste it everywhere (with some modifications), an idea that's literally just sitting on my desk: ball joints. Of course, taking this route fully commits me to making Orchid a motorized marionette but luckily that just so happens to be my fetish and running paracord everywhere, but it's no more complicated than anything else and the loss in precision is acceptable for my purposes. Essentially, Orchid will be held together entirely by cable tension, and I'll have to apply material to lower the friction on her joints (Kiwi mentioned powdered graphite, which I may likely end up using), but at least I won't have to worry about hinges wearing out (I can just reprint any joints that fail instead). I still intend on using pipes for the bones, since it seems like the lightest and most efficient way to go. Also, it makes limb maintenence easier than ever. All I need to do in theory is open up the back panel, unhook the cables, and the limb will fall right off. The plush layer should be able to come off like a sleeve, as well (the head will be more complicated, but I can't think of a good way around that).

Fits perfect. Now for the rest.

>>25532 Does your print bed have four posts? I've had this problem in the past, where the print bed would flex a bit if each screw wasn't set just so and I'd end up with a messed-up print.

>>25535 the printer itself is fine its just that the plastic was moving with the nozzle so it wouldn't draw a square. But I got some stick glue on the bed and that worked kind of.

>>25532 >>25533 >>25534 Looks like you Anons are all making great progress.

>>25510 >hope you're excited for the new hands, Yep, very much so. Looking forward to next week Emmy-Pilled.

>>25513 >>25516 wish I knew how any of that stuff worked, maybe I´ll hire some people to figure that out the day Emmy v.2 rolls out haha

>>25513 >Google's RT-2 It will be interesting to watch what happens in the opensauce communities regarding this platform. Of course, no anon wants to 'trust' his waifu into the """tender mercies""" of G*ogle! :DD >>25516 With all due respect Anon, it's much harder than any of us can even imagine ATM. No doubt the shell is a complex and difficult engineering endeavor. But the clear consensus is that the 'ghost' is much more difficult still -- indeed of entirely unfathomed depths as yet. But let's move this topic to the Cognition discussion thread, thanks. (>>24783).

>>25513 >What have you considered for the "brains" of the nandroid? Are you going to put some kind of LLM there like Google's RT-2, or will it be a much narrower ranger of tasks hardcoded? Local language models exists now. Maybe use one of them for the nandroid?

>>25525 I´ll consider getting my electrician friends on that case, thanks Anon. Always planning for the far future day project v.2 should launch (but before talking about such matters maybe I should finish my actual project first lmao)

Reposting from other thread. So I know it’s a shot in the dark but have any of you thought about reaching out to clubs/people who are interested in robotics? I’m kinda lonely lately and I’d like some robo buddy with me. Anyone got some experience to share?

>>25497 is that even a thing, i only remember an after school activity at my school, it was supposed to be robotics with those programmable legos but once were in the computer lab, after school, it became a cs1.6 party no one gave a shit about legos

>>25497 >Anyone got some experience to share? I used a Lego Mindstorms kit years ago to show others some basic robotics stuff to other guys in school. A couple of them were interested, most weren't.

>>25497 Unless you live in a big city, I wouldn’t hold much hope for an organized club (assuming you’re post-college-age). I’ve heard that cities tend to have “Maker-Spaces” or whatnot, and some of em have clubs/focus groups, but I don’t have any experience there. That said, my experience in both HS and college was a bit disappointing. Probably only 25% of the people had any real interest in robotics, and of those, less than half had either the talent or the determination to do something serious with them. The rest were, as my mentor would have said, “groupies”— people who only wanted to “network” or pad out their applications/CV, instead of actually making stuff Now, for less pessimistic, more actionable stuff: - Drone hobbyist clubs might be your best bet— there are bound to be a few guys DIY’ing. It’ll give you pretty lopsided lessons on robotics (rel focus), but the fundamental concepts and understanding of physics will transfer over just fine, and it’s great introduction to control systems (I’m assuming you’re somewhat new to the field; my apologies if it’s otherwise) - Mechanics-oriented “clubs” (they tend to be informal, often competition-centric) are also helpful for this sort of thing (if you’re aiming to learn mech or intro elec engineering), like racing or flying. Lots of very knowledgeable people in these groups, but you need to either have $$$$$, connections, or a particularly uncommon skill (or a really high CHR stat, but I know nothing of that). A lot of the guys there are more than happy to talk about their specialties, provided the other person shows interest AND can show they understand what they’re being told (the latter tends to be more important lol) Those are really the only experiences I have to offer— if you find something better, by all means, let us know— a lot of us are probably looking for the same thing. >>25503 Those things were pretty great. Sure, their “programming” was a joke, but that sort of trial-and-error is great for learning spatial reasoning and application-oriented design. Shame they haven’t changed much over the years— the kits I saw coworkers’ children playing with looked almost identical to the sets I used over a decade ago.

>>25503 >>25515 Thanks for the tips guys. Like I said I just want to find some new comrades in this grand quest.

>>25500 >“Well no, but actually yes.” You absolutely can, but it’ll look like you’re passing around pointers when you override the operator[] just due to how C++ works. That said, there won’t be any overhead due to it, cause under the hood, the opcodes were always going to be passing that row pointer around; all your data is still contiguous. Also, it’s worth noting Row-major vs. Column-major— always organize your datasets in a way that doesn’t “fight the cache” when you access them. Implementing it is basically allocating a single array and then adding helper functions to abstract how you slice into it: template<typename T> class SimpleMatrix { public: using dim_t = unsigned; using idx_t = unsigned; SimpleMatrix(); SimpleMatrix(dim_t rowCount, dim_t rowSize); ~SimpleMatrix(); inline T* operator[](const dim_t &x) {//row access

>>25500 >can you make a multidimensional vector like a [ ][ ] matrix? an actual matrix though not a vector of pointers to other vectors like *[ ] Yes. >matrix.cpp // compile & run : // g++ matrix.cpp -std=c++11 && ./a.out #include <iostream> #include <vector> using namespace std; int main() { // a 3x3 matrix of ints vector<vector<int>> mat{{00, 01, 02}, //

>>25501 Nice work Anon. I'd suggest you look ahead in our textbook to see where we're going with this idea. Cheers. :^)

>>25506 My bad— didn’t realize the question was in relation to the lecture lol Ah well, ‘least I already had the code sitting around and only spent a few minutes simplifying/de-template’ing it Worth noting that >>25502 *is* effectively a vector of pointers (vectors holding a pointer to their dynamic data region) as far as optimization is concerned (double-deref with dependent lookup), but as they always say: >premature optimization is the root of all evil

>>25517 >My bad— didn’t realize the question was in relation to the lecture lol Heh, for your case in particular, I meant skip ahead to ch 24 of the book (and indeed on through to the end of it). :^) >Worth noting that >>25502 *is* effectively a vector of pointers (vectors holding a pointer to their dynamic data region) as far as optimization is concerned (double-deref with dependent lookup) Yep, you're right. Though Anon's question was primarily about value-semantics (C++), versus reference-semantics (C); in the context of a baseline mathematical matrix. My example type given is the most direct solution for that, code-wise. A std::vector is in effect a general (as in can contain any type, even user-defined ones), flexible (as in can grow & shrink, and be passed cleanly across interfaces), 'intelligent' C-array-like type that: * always knows it's own size, * won't decay into a pointer at the drop of a hat, * is always strongly type-checked (both inside & 'out'), * is quite efficient in general, * and cleans up properly after itself. You can also spend run-time bounds checking (ala Ada, et al) directly if you care to do so, but it's not required of course [1]. In real production systems you'll typically want to optimize the std::vector's memory storage footprint as well, if/when you know the specific requirements [2][3]. There are numerous other benefits with std::vector in addition (particularly in the contexts of thread-safe concurrency/parallelism usage). BTW, any anon who actually works through this lecture and the next two, will thereafter understand how to build a mostly-complete Vector -alike from scratch with no more understanding of memory needed than that of a C-array. This kind of knowledge is really powerful for a beginner, and the std::vector is exactly the right type to thus intently train upon. Very wise of Bjarne Stroustrup to do so IMO.

TL;DR: Selected and modeled final wheel+gear parts (minus derailieur), which revealed that my rough design for wheelbase struts was too wide; halfway through redesigning it now. Settled on a DIY double-sided linear actuator for Bridge Clutch engagement, which sounds scary, but is only ($30 in parts) + motor. Help wanted: I’m using a bike derailier (shifter) to change gears, which is fine going forward, but will self-derail* if I try to drive it in reverse. The obvious solution would be to use an actuator to lock the tensioner, but my intuition is telling me that I can add an idler and angle the thing to put it at a mechanical disadvantage (so that, while the robot can’t shift gears in reverse, it still drives fine). * self-derails because the tensioner is pulled to max while the chain on the now “far” side of the derailieur slacks, then falls off the drive gearing (2nd picrel is a cutaway of the lower drive leg, with the transparent cone-thing being a 51t sprocket cassette [convex hull]) Also, I feel like someone has already solved this… some weirdo has gotta have wanted to pedel backwards on his geared bike at some point, right? (I don’t have enough X-axis room for a second cassette, like that British dude used…) - Selected a specific Primary Wheel for use in the prototype (and first design revisions) - BMX 20in / ISO 406mm, 1.75in rim width, <= 2.25in tire width (OD ~= 20in, measures 19.6in diameter x 2.0in wide for specific wheel+tire chosen) - Opted to use a composite/polymer wheel, since modifying it will be significantly easier than a conventional, aluminum+spoke bike wheel design. - Conversion requires removal of the cartridge bearing in wheels, replacing it with a keyshaft between 1/2in and 1in. - Shimming will likely be required- my plan is to purchase rod stock of the wheel’s ID, then boring out the keyshaft hole with a standard drillbit. - Of course, that’s in the case I can’t simply buy a sleeve/pipe with the appropriate dimensions in the first place, or enlarge them to fit the keyshaft. - Rationale: Bike wheels expect support on both sides of “axle” (just a structural support). For a one-sided support structure to be viable (with the prototype’s forces and shaft >= 5/8in), one needs over 2in of axle (beyond the wheel), supported on both “near” and “far” sides (forming a lever; fulcrum is the first support strut+structural bearing, load-bearing wheel on one side with another supported bearing opposite it. - Will look into acquiring a set of wheels so I can figure out exact procedure and design for wheel conversion. No surprises expected, but then again, are they ever?

Progress Summary: - Mocked-up the “Wheelchair Seat” that transforms into a cargo bed. - Got a physical set of the composite wheels I plan to use, only to discover that the cartridge bearing’s sleeve appears to have been “casted in”, and can’t be punched out without destroying the wheel; currently re-designing the “hub”/keyshaft receptacle around the aluminum bearing sleeve (I was going to have an analogous part anyway, so it’s not a major shift) - After watching several videos of robots being trashed by ne’er-do-wells, I’ve made some minor adjustments to my design to mitigate it. Nothing drastic at this stage, mainly just adding some extra frame around critical areas, reinforcing the load-bearing portions, and lowering the center-of-gravity where possible. - In an emergency, the robot can “drop” (quickly lower, while still retaining) its Sled (battery carriage) to increase its stability and ideally survive being tackled (optimistic, I know) - Made a deal to get some help with the design’s suspension— I might have to fight him a bit to keep my robot from being turned into a racecar, but it’s nice to have an uber-specialized professional’s input. - Until that’s wrapped up, the linkage/suspension between the Drive Platform and the Wheelbase will only be a placeholder, so don’t expect to see anything there till mid-October. Future Considerations: - Looking into compressible epoxies to reinforce the wheel’s hub, since with a full load of “cargo” the robot tips the scales at 450lbs. - (the rated 200lbs of cargo capacity comes from the owner being able to use their robot as an ad-hoc means of transportation) - Haven’t started designing the shell/enclosures yet, but I’m playing around with the idea of fiberglass/aramid/nomex phenolics on a 3D-printed backing. Notes: Going forward, unless there’s an aspect of my design that’s being discussed or that people have questions on, I’ll be shortening these write-ups to just be a TL;DR list, as above.

This is remarkably-good work, Lin. Keep it up! :^)

>>25381 i saw in the tard olympics that their wheelchairs had the wheels at an angle, maybe you get better turning or tokyo drifting like that, could be a consideration?

Picrel: Timelapse from proof-of-concept; thought it could be interesting to illustrate the 80/20 rule in action— the first revision (r01) took the same time to develop as r03 - r05, despite the latter revisions looking nearly identical Progress Summary: Ran into an issue with the dérailleur (not) fitting within the allowable wheelbase, so I’ll have to mount it quite differently than a bike. Worst-case I’ll have to design my own dérailleur, which would be a massive PITA (moreso cause it’s losing an off-the-shelf part + complicating the design than any technical challenge.) Other than that, pretty boring week, starting frame revisions across the entire robot (finally taking bolts/other fasteners into account). Also did mounting hardware for the Bridge brake/clutches well as the clutch caliper (LA head) itself Feels like I’m actually on schedule for my New Year’s design goal— I almost can’t wait to see what unforeseen detail will go horribly wrong Also, I’m traveling for IRL stuff again (no CAD workstation), so next week’s update will likely be short or skipped altogether. >>25384 Thanks for the input— I’d considered something like that earlier on in the design, too. After a bit of research, the rationale for it (in wheelchairs) seemed to be (in order of importance): 1. improve ergonomics 2. widen wheelbase 3. increase contact area between tread and ground As for my own design, (1) doesn’t apply at all (just robot problems, amirite?).

>>25462 Yes mate, that's me. I only got as far as testing two robotic arms and an animatronic head. I am no longer working on Sophie for the foreseeable future as I have to concentrate on paid employment and just looking after myself better. But I kinda suspected I wouldn't have the resources or time to build a fully-mobile robowaifu, which is why I open-sourced everything I could for future builders/inventors to use how they want. After all, I myself took and modified, free open-source CAD models from Will Cogley and Ryan Gross in order to craft Sophie. Just glad I could contribute some maybe useful first-gen robowaifu parts. As for links to all of the parts, I had to delete the Google Drive link because of work (they know about my robowaifu and my manager was actually impressed, so I am lucky to work with based individuals). I will try to keep the MEGA and Mediafire links alive so that more people can download the C.A.D.

>>25472 Okay, thanks again.

>>25472 one must imagine SophieDev happy...

rest easy knowing your contributions will help many anons out there, godspeed

>>25472 God bless you, SophieDev. Thanks for all the help & inspirations! Cheers. :^)