/robowaifu/ - DIY Robot Wives

I use a separate laptop to run the AI. I also use a moderately good smartphone.

> (robowaifu brain software -related : >>730 )

1744505330466396.png
[Hide] (192.5KB, 786x907)

Intredasting. We're going to face similar hw & sw data compression/communication challenges/needs here on /robowaifu/ as well, Anons.

Ideas?

>>749
What would the compression be needed for?

those_r_rookie_numbers_bro.jpg
[Hide] (75.1KB, 889x500)

>>750
For exactly the same reason its needed in Neuralink : to manage the required bandwidth, through an oversubscribed medium.

>tl;dr
I2C/CANBUS/etc (as typically-used) won't be sufficient to manage all the data traffic needed in a modern robowaifu's internal C4(C3 + compute) systems.
>

>>752
I should've been more specific. What areas would overwhelm an internal computer? If it's the input, there could be some compromises that we could use (that might also reduce price). If it's output, ie controlling many motors through a few cables, we could use multiplexing. If it's something completely different, feel free to correct me. I'm not too knowledgeable on computer science

>leaderboard: zip
I heard 7z is much better at compression

let_me_guess_you_need_more.mp4
[Hide] (429.8KB, 576x1024, 00:21)

>>753
>I'm not too knowledgeable on computer science
You don't have to be.

Just understanding 'bits (or bytes) per second' is enough. (Plus understanding that data comms is fundamentally just a stream of electronic highs/lows -- regardless of whatever other information-encoding overlays you may situate [via idiomatic protocols; eg. ASCII, or Morse (lol)] on top of that purely 1s & 0s stream.)
>vid-related; each key-tap is an electronic high (a '1'), each release a low (a '0') -- the protocol is Morse code.

<--->

Imagine the plethora & variety of data generators/consumers all going on in realtime, in both directions, inside an 'in-action' robowaifu simply pottering about your flat. It's yuge. A measly 5Mbps would be quickly overwhelmed. And multiplexing at the hardware level (more chips, power lines, connectors/carriers, data cables, etc.) will quickly add up in cost & mass. Far better IMO to use compression on both ends, if feasible.

<--->

>I heard 7z is much better at compression
There's a fundamental limit (ie, mathematically) to how much lossless compression one can actually do. And yes, I think the LZMA2, et al algorithm(s) is probably pretty close to this theoretical limit. It then becomes a matter of finding stable libraries for 7z that fit on tiny chips inside sensors, etc., and balancing the memory & compression-performance needs at runtime.

>tl;dr
Zip is possibly already the best all-around compromise in this domain, and it's well supported by available libraries (since it's so old).

Screenshot_(1973).png
[Hide] (1.9MB, 1152x1459)

Brain_map.png
[Hide] (45.7KB, 2288x1200)

>>755
I see.

Some ideas
-Lower Resolution Cameras, this will reduce the amount of visual data, as well as make it cheaper.
-Separate Computers, you have different computers/microcontrollers doing different things, just like how a brain operates. It would cost more, but it frees up a lot of computing power and bandwidth*
-Numbing, your brain ignores constant input, and only notices if something is different. This is why you don't smell your own house, see your nose, and the classic "you are manually breathing" prank.
-And ofc using Zip.

How do commercial humanoid robots do it?

*Some examples include
-A visual processing unit
-A motor control unit. When you reach for something, you don't think about "move your arm up, extend elbow 40 degrees, open fingers", you just automatically do it

I made a brain map for an architecture that could work. It's partially based on how roleplay AIs vocalize physical actions, such as "*touches you*", "*reaches out*", "*feels you touch her hand*", *"sees your new outfit*"

OIP_(73).jpeg
[Hide] (25.5KB, 474x474)

>>756
Imagine this, but with 3 instead of 4.

>>755
https://news.accelerationrobotics.com/tesla-optimus-robot-brain-computer-architecture-hardware-software/

1735063692918960.png
[Hide] (240KB, 868x895)

>>756
Short on time r/n. Will plan to reply more-fully later.

>>758
While ROS is a good idea at the conceptual level, I consider it a non-starter for /robowaifus/ 's needs.
a)  I've tried (and failed) repeatedly over the years to setup an optimized ROS system that might work for our needs. No doubt a skill-issue on my part!!  :D
b)  I've tried (and failed) repeatedly over the years to setup an optimized ROS system that might work for our needs. No doubt because it's mostly a hodgepodge of Python contributions (with often-conflicting rereqs, etc.)
c)  I've tried (and failed) repeatedly over the years to setup an optimized ROS system that might work for our needs. No doubt because it is dependent on Ub*ntu distro -- an inherently unsecure, pozz'd distro (especially today!)

>tl;dr
ROS? Just say no, /robowaifu/ !  :D

>>756
You've got the right idea IMO, Anon. The basic approach here is to create dedicated 'processing enclaves' as parts of an interconnected tree of them. For example:
*  Vision
Have dedicated, optimized processing for vision. This would have high-bandwidth connections directly from the hi-def stereo (& possibly other) cams themselves, and relatively-high in power needs as well. The OpenCV (re-)contextualizations would then be sent up to the higher-order compute cores simply as streams of text (so, low-bandwidth on that leg of the overall Robowaifu Vision system).

Similar approaches for other core areas (planning, kinematics, sensor-fusion, etc., etc.) Make sense, Anon?

>>757
Not sure what you mean here, GreerTech. Have less machines in the brain b/c why?

>>756
To represent bodily sensation, maybe you could train the Visual LLM to interpret a specially formated image. Start by taking the 3d surface and mapping its position to cords on the 2d image. (Basically a UV unwrap like in a 3d modeling software) Then you can map the surface/skin Tempature and pressure to different color channels.

PlayStation_2_-_Half-Life_-_Gordon.png
[Hide] (188.1KB, 260x648)

>>799
Makes sense. Seperate parts for different functions, just like the human brain.

>>800
My theoretical system had 3 computer cores, but the image has 4.

>>801
Interesting idea! Reminds me of Half-Life NPC skins