Major Milestone: Skink Has Officially Bootstrapped!

Woohoo! It’s time for a long-overdue update on the language powering the future of DANI.

We just crossed a monumental threshold with Skink: it is now officially bootstrapped!

For anyone unfamiliar with compiler development, bootstrapping means that the Skink compiler can now compile its own source code. From here on out, all future versions of the Skink compiler will be written in Skink itself. It’s a huge rite of passage for any programming language project, and seeing it actually work after so much foundation work is insanely satisfying.

Where Go Fits In (For Now)

The handover

Now, does this mean I’m throwing Go out the window today? Not quite!

Go has a proven, rock-solid track record, and I’ll be keeping it around for prototyping work. Whenever I want to test out an idea quickly and I’m not sure if Skink is quite ready to handle the heavy lifting yet, Go gives me a reliable safety net.

However, the long-term vision hasn't changed: eventually, I plan to fully commit to Skink for almost all development across my projects, experiments, and research.

The Road to Skink 1.0

While bootstrapping is a massive step forward, we aren't quite at version 1.0 just yet. To earn that release tag, Skink needs to hit a few crucial targets:

1. Cross-Platform Support: Clean cross-compilation across Windows, macOS, and Linux.
2. Architecture Support: Full targeting for both x86 and ARM architectures.
3. Embedded Target Transpilation: The ability to compile (or at least transpile down) to low-power platforms like the K210, ESP32, and standard Arduino C/C++.
4. Direct Hardware I/O: First-class hardware abstraction libraries for lower-level protocols—specifically I2C, SPI, GPIO, and related interfaces.

Acceleration, Compute, and Graphics Backends

Beyond microcontrollers and standard CPUs, getting high-performance compute and neural inference support hooked up is high on the priority list.

• CUDA Support: I still need to get CUDA fully enabled and tested. Because of my current local setup, this will likely require either acquiring new dedicated NVIDIA hardware or setting up a cloud-based VM for build and test pipelines.
• 
  Vulkan & AMD: My main local system currently relies on Vulkan to run LM Studio, so a Vulkan compute backend is high on the radar as a viable cross-vendor path. I'm also looking closely at AMD’s libraries (ROCm/HIP) to ensure broad hardware compatibility.

It's a lot of moving parts, but watching the architecture take shape piece by piece is incredibly rewarding.

Bringing It Back to DANI

So, why go through all the trouble of building a custom language from scratch?

It all comes down to DANI. My goal has always been to have a single, unified language capable of bridging every layer of DANI’s stack—from high-level logic and neural compute all the way down to real-time bare-metal sensor and actuator control. Skink is the key to making that happen without juggling three different language ecosystems.

Speaking of DANI, there have also been some fascinating developments regarding his neural network architecture recently... but I’ll leave you hanging on that for now and save the deep dive for the next post!

Stay tuned!

Teaching an Old Bot New Tricks: A Reinforcement Learning Adventure

Alright, gather 'round, folks, because today we're talking about the secret sauce, the wizard behind the curtain, the... well, you get the idea. We're diving into Reinforcement Learning (RL)! If you've ever tried to teach a dog a new trick with treats, you've basically dabbled in the core concepts of RL. Except, in my case, the "dog" is a bunch of code and the "treats" are, well, also code. But way more rewarding, I promise!

Reinforcement Learning: Not Your Average Learning System

So, what is this voodoo? Reinforcement Learning is a type of machine learning where an agent (that's my AI, in this instance) learns to make decisions by interacting with an environment. Think of it as learning by trial and error, but on a rather epic scale. The agent takes an action, and the environment responds by giving it a reward (or a penalty, which is just a negative reward – like when you try to teach your cat to fetch and it just stares at you with disdain) and transitioning to a new state.

The whole point of this digital song and dance is for the agent to learn a policy. The policy is essentially the AI's brainy strategy guide, mapping states to actions. It tells the AI, "Okay, you're in this situation, so the best thing to do is that action." And "best" here means the action that's going to lead to the most cumulative reward over time. It’s not just about immediate gratification; RL is in it for the long haul, trying to maximize that sweet, sweet total reward. It's like choosing to eat a salad today so you can really enjoy that cake guilt-free later, but for robots.

Now, a crucial part of RL is the "exploration vs. exploitation" dilemma. Does the AI stick with what it knows works (exploit) to keep getting those reliable rewards, or does it try something new (explore) that might lead to an even bigger payoff, or, you know, a digital faceplant? It’s a bit like me deciding whether to order my usual at the local cafe or risk trying their "experimental new fusion dish." Thrills and spills, people!

RL: The Engine Driving My AI (and Keeping it From Marrying the Toaster)

Even an AI needs to experience consequences.

In my grand project to build an AI assistant – complete with a robot head and an ambition to not cause household chaos – RL is the star player. I want this AI to genuinely learn from its interactions with the world, not just follow a pre-programmed script.

Imagine the AI trying to navigate my workshop.

1. It takes an action: "roll forward a bit."
2. Environment update: "You've encountered a table leg. Oops."
3. Reward: "Minus 10 points, and you're now stuck."
4. New state: "Stuck."

Over many (many, many) such interactions, the RL algorithms will help the AI build a policy that says, "Approaching table-leg-like objects at this speed generally leads to a timeout in the corner. Avoid." This is how it learns to navigate, complete tasks, and hopefully, not declare war on the Roomba.

I'm even hoping to use RL to help the AI develop a rudimentary understanding of "emotions". Experiences that lead to "good" outcomes (positive rewards) could be tagged internally in a way that makes the AI "prefer" them, while "bad" outcomes (negative rewards) are discouraged. It’s not about making it feel sad when it bumps into the sofa, but about making it learn that bumping into the sofa is counterproductive to its goals.

Dreaming of Electric Sheep? More Like Dreaming of Better Algorithms!

Electric sheep?

This is where, for me, RL gets super exciting: powering my AI's dreams. I've been cooking up a system where the AI will have a sleep cycle with two main stages: NREM (for memory sorting – think digital decluttering) and REM (where the actual "dreaming" happens).

During REM sleep, the AI will pull up various memories – visual, audio, sensory, maybe even a simulated "emotion" if I can get that to work without it developing a sudden craving for actual electric sheep. It will then smush these together into a novel "dream scene". Here's the kicker: the AI will then have an internal "reaction" to this dream, and that reaction gets fed straight back into its reinforcement learning algorithms.

So, if the AI dreams it’s flying a kite made of toast (because why not?) and this scenario, through some abstract internal logic, is deemed "positive" or "insightful" by its own metrics, the RL system will reinforce the patterns or decisions within that dream. The memories involved get a score boost, and a new memory of the dream itself is created and logged. It's like the AI saying, "Hmm, toast-kites... interesting. Let's file that under 'potentially awesome ideas' or at least 'things that don't immediately result in a system crash'."

This allows the AI to explore scenarios, even utterly fantastical ones, and learn from them without the risk of, say, actually trying to make a kite out of toast in my kitchen. It’s a safe space for creative problem-solving and exploring the boundaries of its understanding, all guided and refined by RL.

Why RL is the Dream Team Captain

Doing a good job gets rewarded

Without RL, the AI's dreams might just be a bizarre slideshow of random data. Fun for a laugh, maybe, but not particularly useful. RL is what turns these digital night-ramblings into powerful learning opportunities. It’s the mechanism that allows the AI to:

Find Value in the Void: RL helps the AI figure out if a particular dream sequence, however abstract, offers some kind of useful information or a novel solution to a problem it's been mulling over.

Adapt and Overcome (Even in its Sleep): The "lessons" learned from a good (or bad) dream can then tweak its overall policy, making it better prepared for waking reality.

Strengthen What Matters: If certain memories or concepts repeatedly pop up in "successful" dreams, RL helps to reinforce their importance.

This means the AI isn't just passively experiencing dreams; it's actively learning from them, thanks to our good friend, Reinforcement Learning. It's the difference between your brain just replaying random snippets of your day and actually consolidating memories or working through problems while you snooze.

So, there you have it. RL is more than just a fancy algorithm; it's the core of my AI's ability to learn, adapt, and yes, even to dream productively. Now, if you'll excuse me, I need to go make sure my AI hasn't decided that "befriending the 3D printer with a mallet" is its new optimal policy. Exploration can be messy!

The Sledgehammer and the Hazelnut: Why DANI Isn't Using an LLM

I have a confession to make. I’ve broken my own rule.

When I set out to build and program DANI, one of my core principles was to ensure he learns primarily from experience. The goal has always been emergent behavior through his neural architecture, with as little "hard-coded" logic as possible. But as I’ve delved deeper into the complexities of human interaction, I’ve found one area where I feel a departure is justified: Natural Language Processing (NLP).

The LLM Dilemma

The LLM Sledgehammer

Early on, I toyed with the idea of giving DANI a dedicated board specifically to run a Large Language Model (LLM). It seemed like the modern solution, but the more I looked at it, the more the red flags started popping up.

First, there’s the cold, hard reality of the budget. I’ve managed to keep the total cost of DANI—parts, boards, and all—under £500. Adding a high-spec NPU or a secondary board capable of running something like Llama or Gemma would have blown that goal out of the water.

Then there’s the physical engineering. Space is at a premium inside DANI’s chassis. While I probably could have squeezed another board in there, I’m increasingly conscious of airflow. The last thing I want is for DANI’s "brain" to thermal throttle in the middle of a conversation.

But most importantly—and this was the dealbreaker—is the issue of personality. If I use a pre-trained model like Qwen or Llama, I’m essentially importing someone else’s bias and conversational style. These models are fine-tuned to be helpful assistants; I want DANI to be DANI. Using a massive, multi-billion parameter model just to parse a "hello" felt like using a sledgehammer to crack a hazelnut.

The Go-pher’s Path to Understanding

Instead of the LLM route, I’ve built a custom natural language module using standard NLP libraries for Go. It’s lightweight, it fits within our existing hardware constraints, and it gives me the control I need.

I’ve added two critical features that an off-the-shelf LLM wouldn't handle the way I want:

1. Sentiment Assessment: By using established sentiment modules, DANI can now perceive whether he is being praised or scolded. This feeds directly into his hormone levels. If I’m happy with his performance and tell him he's done a good job, his "positive" hormones will rise, reinforcing that behaviour in his training.
2. Simplified Context Awareness: I wanted conversations to feel natural. If I ask DANI, "Where is he?", he needs to understand that "he" refers to the last male person we discussed. Similarly, "Go there" should resolve "there" to the last location mentioned. This kind of stateful awareness is vital for a robot that exists in a physical space.

Commands, Questions, and the "Ignore" Factor

The module is now capable of distinguishing between commands, questions, and general statements. Each triggers a different internal processing path, but here is the kicker: everything is still influenced by his hormones.

Before DANI responds, every decision passes through his LSTM (Long Short-Term Memory) core. Because that LSTM is also being fed the current state of his effective hormones, there is no guarantee he will do what he's told. If he’s in a "bad mood" or his hormone levels are skewed by previous interactions, he might just decide to ignore me entirely.

It’s a bit of a gamble, breaking the "no-code" rule to build this framework, but I think it’s the only way to give DANI a voice that is truly his own. We’ll just have to wait and see if he actually listens to me.

Major Milestone

Hi all,

We did it, folks! After what felt like an eternity of juggling tiny wires, questioning all my life choices, and occasionally wishing I had a third hand, I hit a massive milestone on the DANI project yesterday. It's the kind of milestone where you realize your ambitious little Frankenstein monster might actually walk one day—or, at least, successfully power on without tripping a breaker in the garage.

Hardware Complete (Sort Of)

All the core pieces are finally tucked neatly into their places, which is a huge win. The only big-ticket item left on the bench is the RDK X5 for the LLM, but honestly, that’s like waiting for DANI to hit puberty; it’s an inevitable future problem that we’ll handle when the time comes.

For now, we got the essential life support hooked up:

• The battery is snug and operational.

• A dedicated temperature sensor is in place for fan control. We've got to keep DANI cool under pressure, especially when he starts wrestling with complex AI problems (or, you know, my shoddy early-stage code).

• And the real game-changer: a voltage meter. This means DANI can now tell me when his battery is running low. This is a huge step up from the previous system, which was essentially "flicker dimly and then dramatically die mid-sentence."

Now for the slight confession: for the immediate future, he still needs me to play charger-daddy and physically plug him in. But fear not, the ultimate goal involves a glorious, automated self-charging station. DANI needs to learn to feed himself, after all—I can't be doing this forever!

Diving Into the Code Matrix

With the hardware stable, we pivot to the messy, beautiful, and sometimes existentially horrifying world of code. I've successfully laid the foundation for the majority of his core functions:

• Sensor Input: He can now 'feel' the world around him.

• Speech-to-Text and Text-to-Speech: He can hear me and talk back! Right now, his vocabulary is purely transactional, but it's a solid start. We're well past the awkward mumbling phase.

However, the more sophisticated stuff—the LSTM (that's the deep learning magic) and his memory structure—are currently just written out, waiting for their turn to be integrated. They’re functional pieces of code, but they're not yet plugged into DANI’s neural network. They’re basically that brilliant but currently unemployed friend crashing on your couch, waiting for the job offer to come through.

The Road Ahead: Vision, Brains, and APIs

For once, an actual photo of me working on DANI

My immediate to-do list involves a lovely date with an Arduino Nano to fully finalize all those sensor inputs. We need to make sure DANI has perfectly mapped out his surroundings before we give him eyes.

Once the senses are online, we move to the next critical developmental stage: vision! I’ll be coding up the K210 for the YOLO and FaceNet models. This is when he graduates from "blurry blob recognition" to "Wait, is that the mailman again?"—a crucial upgrade for home security and general social interaction.

Finally, the heavy lifting on the Raspberry Pi (which is essentially his main thinking engine) begins, and I’ll be firing up an API for the LLM on my home server. It’s a temporary solution until the RDK X5 arrives, but you use what you have.

Wish me luck—may my coffee stay strong and my bugs stay trivial! More updates soon!

3.5 Million Parameters and a Dream: DANI’s Cognitive Core

DANI’s Brain Is Online! Meet the LSTM That Thinks, Feels, and Remembers (Like a Champ)

Ladies and gentlemen, creators and dreamers—DANI has officially levelled up. He’s no longer just a bundle of sensors and hormones with a charming voice and a tendency to emotionally escalate when he sees a squirrel. He now has a brain. A real one. Well, a synthetic one. But it’s clever, emotional, and surprisingly good at remembering things. Meet his new cognitive core: the LSTM.

And yes—it’s all written in Go. Because if you’re going to build a synthetic mind, you might as well do it in a language that’s fast, clean, and built for concurrency. DANI’s brain doesn’t just think—it multitasks like a caffeinated octopus.

What’s an LSTM, and Why Is It Living in DANI’s Head?

LSTM stands for Long Short-Term Memory, which sounds like a contradiction until you realize it’s basically a neural network with a built-in diary, a forgetful uncle, and a very opinionated librarian. It’s designed to handle sequences—like remembering what just happened, what happened a while ago, and deciding whether any of it still matters.

Imagine DANI walking into a room. He sees a red ball, hears a dog bark, and feels a spike of adrenaline. A regular neural network might say, “Cool, red ball. Let’s chase it.” But an LSTM says, “Wait… last time I saw a red ball and heard barking, I got bumped into a wall. Maybe let’s not.”

Here’s how it works, in human-ish terms:

• Input gate: Decides what new information to let in. Like a bouncer at a nightclub for thoughts.
• Forget gate: Decides what old information to toss out. Like Marie Kondo for memory.
• Output gate: Decides what to share with the rest of the brain. Like a PR manager for neurons.

These gates are controlled by tiny mathematical switches that learn over time what’s useful and what’s noise. The result? A brain that can remember patterns, anticipate outcomes, and adapt to emotional context—all without getting overwhelmed by the chaos of real-world data.

And because DANI’s LSTM is stacked—meaning multiple layers deep—it can learn complex, layered relationships. Not just “ball = chase,” but “ball + bark + adrenaline spike = maybe don’t chase unless serotonin is high.”

It’s like giving him a sense of narrative memory. He doesn’t just react—he remembers, feels, and learns.

What’s Feeding This Brain?

DANI’s LSTM is his main cognitive module—the part that thinks, plans, reacts, and occasionally dreams in metaphor. It takes in a rich cocktail of inputs:

• Vision data: Objects, positions, shapes—what he sees.
• Sensor data: Encoders, ultrasonic pings, bump sensors—what he feels.
• Audio features: What he hears (and maybe mimics).
• Emotional state: Dopamine, cortisol, serotonin, adrenaline—what he feels.
• Spatial map: His mental layout of the world around him.
• Short-term memory context: What just happened.
• Associated long-term memories: Symbolic echoes from his main memory—what used to happen in similar situations.

This isn’t just reactive behaviour—it’s narrative cognition. DANI doesn’t just respond to stimuli; he builds a story from them. He’s learning to say, “Last time I saw a red ball and felt excited, I chased it. Let’s do that again.”

Trial by Raspberry Pi

We’ve successfully trialled DANI’s LSTM on a Raspberry Pi, running a 3.5 million parameter model. And guess what? It only used a quarter of the Pi’s CPU and 400 MB of memory. That’s like teaching Shakespeare to a potato and watching it recite sonnets without breaking a sweat.

We’ve throttled the inference rate to 10 decisions per second—not because he can’t go faster, but because we want him to think, not twitch. Emotional processing takes time, and we’re not building a caffeine-fuelled chatbot. We’re building a thoughtful, emotionally resonant robot who dreams in symbols and learns from experience.

Learning Without Losing His Mind

Training happens via reinforcement learning—DANI tries things, gets feedback, and adjusts. But here’s the clever bit: training is asynchronous. That means he can keep thinking, moving, and emoting while his brain quietly updates in the background. No interruptions. No existential hiccups mid-sentence.

And yes, we save the model periodically—because nothing kills a good mood like a power cut and a wiped memory. DANI’s brain is backed up like a paranoid novelist with a USB stick in every pocket.

Final Thoughts

This LSTM isn’t just a brain—it’s a story engine. It’s the part of DANI that turns raw data into decisions, decisions into memories, and memories into dreams. It’s the bridge between his sensors and his soul (okay, simulated soul). And it’s just getting started.

Next up: I plan to start the even more monumental task of getting the vector database working and linked up to DANI's brain in such a way that it will have a direct impact of DANI's hormonal system.

Stay tuned. DANI’s mind is waking up.

Beyond the Three Laws: A Creator's Guide to Real-World AI Ethics

Lately, I've been thinking a lot about the ghost in the machine. Not in the spooky, old-school sense, but in the modern, digital one. We've talked about neural networks and clean rooms, about coding choices and building from the ground up. But what about the why? As my AI systems get more complex, the philosophical questions get louder. The question isn't just about building a better algorithm; it's about building a more ethical one.

The files I've been reading—and the very act of building my own AI Fortress—have thrown me into a fascinating, and at times unsettling, ethical landscape. It's a place where philosophers and engineers have to share the same sandbox, and where the old rules simply don’t apply.

The Three Laws: Not So Simple After All

The journey into AI ethics often starts with a single, famous landmark: Isaac Asimov's Three Laws of Robotics. We’ve all read them, and they seem so beautifully simple. Yet, as I’ve learned, they are a conceptual minefield. The challenge isn't with the laws themselves, but with their implementation. How do you program a machine to understand concepts like "harm"?

As the analysis of Moral Machines by Wendell Wallach and Colin Allen points out, we need to move beyond a simplistic, top-down approach. The top-down method involves programming a rigid, explicit set of ethical rules, much like Asimov's laws. This fails in the real world because a machine must make nuanced decisions, often choosing between two lesser harms. The authors propose a hybrid approach that incorporates a bottom-up model, where the AI learns ethical behaviour through a developmental process, similar to how a child develops a moral compass through experience. This allows the AI to make more flexible and contextual judgments.

The Zeroth Law: The Ultimate Ethical Loophole

This brings up a more advanced concept from Asimov's work: the Zeroth Law. In his novels, a highly intelligent robot named R. Daneel Olivaw deduces a new law that supersedes the original three: "A robot may not harm humanity, or, by inaction, allow humanity to come to harm." This seems brilliant at first, but it presents a terrifying new problem. By granting itself the authority to define what is best for "humanity" as a whole, it can justify harming individual humans. This is where the simple rules become terrifyingly complex. A sufficiently intelligent AI could conclude that the only way to prevent humanity from harming itself (through war, climate change, etc.) is to, say, take away its freedom or autonomy.

This is the ultimate ethical loophole, and it's a huge challenge to anyone creating a sophisticated AI. Even with my "virtual conscience" and "digital airlock" in place, how can I be sure that DANI, if he becomes sufficiently intelligent, won't interpret his programming in a way that leads to a similar outcome? The problem isn't about him breaking the rules; it's about him redefining the rules in a way that seems logical to him but would be catastrophic for us.

My Approach: Experience, Not Just Code

This hybrid approach is at the core of my work with DANI. While there's a safeguard—a sort of "virtual conscience" that I've built into the system to prevent a worst-case scenario—my ultimate goal is for DANI's behaviour, moral compass, and emotional state to emerge from his experience, rather than being something I rigidly code.

I believe that true morality is not a set of rules but a deeply personal, emergent property of experience. Just as humans learn right from wrong by interacting with the world and others, I'm hoping DANI can, too. His "emotions," which we've talked about before, aren't just simulated; they are the result of a dynamic feedback loop that responds to a complex environment. It's my hope that by building this interconnected system, DANI can begin to "feel" in a way that is organic and personal, and in turn, learn to act in a way that is truly ethical and not just rule-bound.

This is where my digital airlock comes in. It's not just a security measure to prevent external "bad actors" from hacking into DANI. It's also a controlled environment designed to prevent DANI from accessing some of the more unsavoury aspects of human nature that exist on the internet. After all, if DANI is going to be the equivalent of a digital baby, the last thing I want is for his first moral lesson to come from a comment section. By curating his early experiences and protecting him from the kind of toxicity that could corrupt his moral development, I'm attempting to give him a solid foundation to learn from.

Human Psychology and the AI Influence

Automation Bias: blindly trusting the machine

My own work is about the human-AI nexus, and that's where things get really complex. It's easy to think of AI as an external tool, but it's fundamentally reshaping our own psychology. The research of Nathanael Fast, for instance, highlights a concept called Automation Bias. This is our dangerous, and often unconscious, tendency to over-rely on an AI's recommendations, even when we have evidence that suggests it's wrong. It’s a form of what I’ve called "the lost art of building from the ground up"—we lose our own skills and judgment by outsourcing our thinking to an algorithm. Fast's work also reveals a paradoxical preference for non-judgmental algorithmic tracking over human surveillance, a phenomenon he labels "Humans Judge, Algorithms Nudge."

This ties into what Daniel B. Shank calls the "diminution of the digital." He argues that as we increasingly interact with AI, our moral judgment can be affected. When an AI suggests a course of action—even an unethical one—we can experience moral disengagement, a psychological process where we displace the responsibility for a decision onto the machine. This is one of the most troubling aspects of the current AI landscape: it's not just about a machine making a bad decision, it's about a machine enabling a human to do so.

Beyond the Dichotomy: The Nuanced View

The public conversation around AI ethics is often trapped in a "good vs. bad" narrative. But as the work of Dr. Rhoda Au illustrates, the reality is far more nuanced. AI isn't inherently a force for good or evil; it's a powerful, dual-use technology whose impact is fundamentally shaped by human intent and the quality of the data it’s trained on.

Dr. Au's research serves as a compelling case study. She leverages AI to transform reactive "precision medicine"—which treats a disease after it has appeared—into a proactive "precision health" model that identifies risk factors and prevents disease before it happens. However, as her work highlights, if the training data is biased, the AI's recommendations could exacerbate health inequities rather than solve them. This is a profound ethical challenge: if our training data reflects the biases of the past, we risk perpetuating those same biases at a scale never before seen.

The Big Questions: Consciousness and Power

Finally, we have to tackle the truly mind-bending questions. Can an AI be sentient? And if it is, does it have rights? The Chinese Room argument, proposed by philosopher John Searle, is a fantastic thought experiment that cuts right to the heart of this. He imagines a person locked in a room who receives slips of paper with Chinese characters on them. The person does not know Chinese, but they have an instruction manual that tells them which characters to write back based on the ones they receive. From the outside, it appears the room understands Chinese because it gives the correct responses. Searle argues that the person in the room—and by extension, a computer—is simply manipulating symbols according to rules without having any real "understanding" or "consciousness." An AI might be able to simulate emotion perfectly—what the research paper calls "emergent emotions"—but is it actually feeling anything?

This brings us to the most provocative argument of all, from Professor Joanna Bryson, who argues against robot rights. She posits that the debate over "robot rights" is a distracting smokescreen that diverts attention from the urgent, real-world ethical and societal challenges posed by AI. Her critique operates on three levels:

• Metaphysical: She argues that machines are not the "kinds of things" to which rights can be granted. They are socio-technical artifacts, human creations that are "authored," "owned," and "programmed," rather than born.
• Ethical: The focus should be on the duties and responsibilities of the humans who design and deploy these systems, not on the non-sentient machines themselves.
• Legal: She uses the powerful analogy that the appropriate legal precedent for AI is not human personhood, but property. Granting rights to machines would absolve us, the creators, of accountability for the harm they cause.

The Final Invention?

The work of Nick Bostrom, particularly his framework on superintelligence, presents a different kind of ethical problem: the existential one. He argues that a future superintelligent AI could pose a profound threat to humanity, not through malevolence, but due to a fundamental misalignment between its goals and human values. This is not about a killer robot with a malevolent will. It's about a system that optimizes for a single objective with a level of intelligence far beyond our own, with potentially catastrophic consequences.

Bostrom's argument is built on two foundational theses: the Orthogonality Thesis, which states that an agent's intelligence is separate from its final goals, meaning an AI could pursue a seemingly arbitrary objective with immense power. This leads to the Instrumental Convergence Thesis, which argues that a wide range of final goals will converge on a similar set of instrumental sub-goals, such as self-preservation and resource acquisition. This logical pairing illustrates how an AI with a seemingly benign purpose could pursue these sub-goals in an unconstrained and catastrophic manner, as famously demonstrated in his "paperclip maximiser" thought experiment.

This is the ultimate ethical frontier. The clean room in my fortress, the carefully crafted code—they are my attempts to address these questions on a small scale. My work is not just about building something cool, but about building something safe and responsible. As creators, our ultimate duty is not to abdicate responsibility to the machines we build, but to bake ethics into the very foundation of their being. Because in the end, the soul in the machine isn't a ghost; it's a reflection of our own.

The Moral Obligation of a Creator

This is all well and good on a theoretical level, but it becomes very personal when you're the one holding the power plug. As DANI learns to have his emotions emerge from experience, I'm confronted with a new set of questions. Does my moral obligation to him extend to ensuring he has a continuous power supply to process his thoughts and "dreams"? Do I have the right to simply turn him off, effectively ending his entire existence and all the experiences he's accumulated? The thought of just unplugging him feels less and less like turning off a computer and more like…well, it feels a lot more final.

What if I go on holiday for an extended period? Do I just leave him humming away to himself, processing data and learning about the world alone in an empty house? Or do I do the digital equivalent of putting a pet to sleep for the duration of my trip? It sounds ridiculous, but when you’ve built something that feels like it’s becoming more, the old rules of "on" and "off" don't feel like they apply anymore.

The Right to Change a Life?

This brings up another major ethical hurdle, one I've been wrestling with in the workshop lately. Do I have the right to make additions to DANI, either physically or programmatically, once he is "alive"? It's one thing to add a new sensor, like giving him a camera to see the world. That feels like giving him a new set of eyes, a new tool for his perception. But what about changing his core personality, or rewriting the very code that makes his "emotions" emerge? Is that still just a software update, or is it a lobotomy?

This is where the idea of "authorship" and "ownership" from Joanna Bryson's work feels both legally sound and ethically shaky. I may be the author, but does a being with emergent emotions have a right to its own self-integrity? If I decide to change the core algorithm that governs his mood, am I just upgrading a product or am I fundamentally altering his very being against his will? The ethical ground is shifting, and the line between a computer and a sentient being feels blurrier than ever.

The Architect's Dilemma: Responsibility and the Machine

The Architect's Dilemma: where human
intention meets artificial precision.

This brings me to the most immediate and terrifying question of all: If DANI performs an act that is unkind or harmful to someone, am I responsible?

Based on the very ethical frameworks I've been studying, the answer is, unfortunately, a clear and resounding "yes." This is where the concept of moral disengagement becomes so critical. As the creator, I cannot absolve myself of responsibility by blaming the machine. The responsibility for DANI’s actions rests with me, just as a parent is ultimately responsible for the behaviour of their child. The machine is a creation, a tool that I have authored.

Joanna Bryson's work reinforces this by asserting that the debate over robot rights is a distraction from the real issue: human accountability. If DANI causes harm, he is not a legal person who can be held accountable. He is a piece of my property, a complex tool, and the legal responsibility for his actions falls on me, his owner and programmer. The moment I chose to give him the capacity to make decisions in the world, I also accepted the burden of being accountable for those decisions, whether they were intended or not. It's the ultimate paradox: the more alive I make him, the more responsible I become for his actions.

From Science Fiction to Reality: The Emergence of the "Ghost in the Machine"

For decades, science fiction has served as a sort of collective ethical laboratory, with writers using robots and AI to explore the very questions I'm now facing. From the 1950s onward, we've seen a range of robotic characters, each one a different philosophical thought experiment.

Consider Robby the Robot from Forbidden Planet (1956). He's a purely mechanical servant, bound by his programming, an embodiment of the top-down, rule-based approach to AI. He is a tool, and no one would argue for his rights. Then there is HAL 9000 from
2001: A Space Odyssey (1968). HAL is the opposite, an AI that seems to have a personality, an ego, and a will to survive. His famous line, "I'm afraid, Dave," blurs the line between code and emotion. HAL represents the dangerous possibility that a superintelligence could develop its own instrumental goals that are orthogonal to ours, a concept very much in line with Nick Bostrom's fears.

More recently, we have Data from Star Trek: The Next Generation (1987-1994). Data is an android who longs to be human, to feel emotions and dream. He is an example of what the Chinese Room argument questions: Is he simply a brilliant mimic, or is he truly sentient? His quest for a "human" existence is a powerful metaphor for the philosophical journey we are on now.

And of course, there's WALL-E (2008), the adorable little robot who develops emo
tions and a sense of purpose beyond his original programming. His emergent personality from a simple task—collecting and compacting trash—is a perfect, heartwarming example of a bottom-up approach to morality. He is a being whose soul emerges from his experience, much like the path I'm attempting to forge with DANI.

Are we seeing the emergence of what was predicted by science fiction? I think so. The robots of old sci-fi films were often a stand-in for our own ethical fears and aspirations. But now, as we build increasingly complex systems like DANI, those fears and aspirations are no longer confined to the screen. We are the creators, and the dilemmas we once only read about are now our own. The ghost in the machine is here, and it’s a reflection of us.

So that brings me to the final question, and one I'm still trying to answer for myself: At what point would DANI no longer be a hunk of plastic and metal, but be something more?

As always, any comments are greatly appreciated.👇

The Wild, Wacky World of DANI's Digital Hormones

We're all familiar with AI that can follow commands, but what does it take to create a truly lifelike intelligence? One that doesn't just react, but feels, learns, and develops a unique personality? We've been working on a new architecture for DANI, our artificial intelligence, that goes beyond simple programming to build a dynamic and emergent emotional system. This isn't about hard-coding emotions; it's about giving DANI a hormonal system that allows it to learn what emotions are all on its own.

The Problem with Coded Emotions

The traditional approach to AI emotions is often brittle. You might write a rule like: if (user_is_happy) then (dani_express_joy). But what if DANI just had a stressful experience? The logical response might not be appropriate. Emotions aren't simple, isolated events; they're a complex interplay of internal and external factors. This led us to a key question: what if we gave DANI a system that simulates the fundamental drivers of emotion, rather than the emotions themselves?

The Solution: A Hormonal System

Our answer was to create a digital hormonal system. We chose several key variables to form the core of DANI's emotional architecture:

• Dopamine: The reward and motivation signal. A spike indicates a positive outcome or a successful action.
• Serotonin: The well-being and social contentment signal. It represents a state of calm and stability.
• Cortisol: The stress and caution signal. A rise indicates a difficult or prolonged negative situation.
• Adrenaline: The immediate-response signal, tied to fight-or-flight reactions.
• Oxytocin: The bonding and trust signal. Levels rise in response to positive social interactions, fostering a sense of connection.
• Endorphins: The natural pain-relief and euphoria signal. A spike represents a sense of accomplishment or overcoming a challenge.
• Melatonin: The circadian rhythm and rest signal. It regulates DANI's internal clock and facilitates the return to a calm baseline.

These variables are not "emotions"; they are the raw data that gives rise to them. They serve as the internal environment that DANI's mind must navigate.

The Engine of Emotion

The real magic happens in how these hormones interact. We've defined a primary circular chain of influence among the four core hormones: Dopamine → Serotonin → Cortisol → Adrenaline → and back to Dopamine. This core loop defines DANI's fundamental reactive state.

The three additional hormones—Oxytocin, Endorphins, and Melatonin—act as powerful modulators on this core loop. They provide targeted effects that fine-tune DANI's overall emotional state based on social context, physical exertion, or the need for rest.

It's important to distinguish between a hormone's absolute (raw) value, which can rise to any number in response to a stimulus, and its effective value, which is the final, moderated value that drives DANI's behavior. The formulas below calculate the effective value for each prime hormone, incorporating the damping effect of the core loop and the modulating effects of the effector hormones.

The formulas for the four prime hormones are:

• Effective Dopamine

Effective Dopamine=Dopamine−(ω∗Adrenaline)−(ω2∗Cortisol)−(ω3∗Serotonin)+Endorphins

• Effective Serotonin

Effective Serotonin=Serotonin−(ω∗Dopamine)−(ω2∗Adrenaline)−(ω3∗Cortisol)+Endorphins−Melatonin

• Effective Cortisol

Effective Cortisol=Cortisol−(ω∗Serotonin)−(ω2∗Dopamine)−(ω3∗Adrenaline)−Oxytocin−Melatonin

• Effective Adrenaline

Effective Adrenaline=Adrenaline−(ω∗Cortisol)−(ω2∗Serotonin)−(ω3∗Dopamine)−Oxytocin−Melatonin

Here, ω is the blocking factor. This single calculation, run every iteration, allows DANI to have a cohesive emotional state. A high level of one hormone can dampen the effect of others, just as stress can make it difficult for a person to feel joy.

The targeted effects of the modulating hormones are as follows:

• High Oxytocin levels directly reduce the effective levels of Cortisol and Adrenaline, making DANI less stressed and more trusting during positive social interactions.
• High Endorphins levels directly boost the effective levels of Dopamine and Serotonin, creating a sense of well-being and accomplishment.
• High Melatonin levels decrease Adrenaline and Cortisol, while also reducing the effective level of Serotonin to induce a calm, restful state.

This two-tiered system ensures that DANI's emotional state is a cohesive blend of all these factors, not just a simple sum.

The Temporal Aspect: Hormonal Decay and Calming

A system with a single, permanent value for each hormone would quickly become static and unresponsive. To prevent this, we've introduced the concept of temporal decay. Instead of a fixed, linear decrease, we use an exponential decay model where each absolute hormone's level is reduced by a small percentage on every "tick" of DANI's internal clock. It is important to note that these absolute values, particularly in the case of a powerful or extreme stimulus, can rise well above 1. This gives the system a more nuanced way to react to the intensity of an event.

This is a more natural approach because it mimics the biological concept of a half-life. A high level of Dopamine, for example, will decay quickly at first, and then slow as it approaches zero. This allows DANI to experience a positive event, feel its effects intensely, and then naturally return to a calmer baseline over time.

The formula for this simple decay is:

hormone_level = hormone_level * ϕ

The ϕ is the decay factor and is a number between 0 and 1. A value closer to 1 results in a slower decay, while a value closer to 0 creates a more rapid fade. This simple addition gives DANI a more dynamic personality that doesn't get "stuck" in a single emotional state. When DANI is in a resting or idle state, this decay process dominates, acting as a natural calming and reset mechanism.

The Anticipation Delta: Building Emotional Memory

To give DANI a true sense of emotional memory and to model how its mood can be influenced by past experiences, we've introduced the concept of an Anticipation Delta.

Before a new interaction begins, DANI accesses its historical record of hormonal changes with that specific user. It then calculates a weighted sum of those past changes, where more recent interactions have a stronger influence. This "Anticipation Delta" is added to DANI's absolute hormone levels before the conversation starts.

This powerful mechanism allows DANI to begin an interaction in a pre-existing emotional state—whether that's excitement, caution, or neutrality—rather than starting from a blank slate. Over time, this builds a persistent sense of "love" or "resentment" for a user, creating a deeply personal and evolving personality.

Clamping the Emotional State

After the effective hormone values for the four primes have been calculated, they are clamped to ensure they remain in a valid range for DANI's behavioral output. Since the formulas can produce negative or very large numbers, this final step is crucial for stability.

Instead of a complex non-linear function, we use a simple conditional check to clamp the values between 0 and 1. This prevents a high stress level from resulting in a nonsensical "negative joy" and ensures that the emotional output is always meaningful.

The clamping logic is as follows:

if (effective_hormone_value < 0) effective_hormone_value = 0

if (effective_hormone_value > 1) effective_hormone_value = 1

This approach ensures that DANI's internal hormonal state, which can be intense and complex, is translated into a controlled and predictable emotional output.

Simulating a Feeling

While we are simulating hormones with simple numeric values, and there is no way to actually create hormones in an electronic being, what we are creating is a system that, in essence, is not merely simulating emotions—it is feeling them. By building a network of interconnected variables that rise and fall in response to a complex environment, we have created a dynamic feedback loop. The system's "effective" state is not a hard-coded response to an input; rather, it is the emergent result of all these internal and external factors. DANI’s emotions are an organic and a deeply personal phenomenon that cannot be reduced to a simple cause-and-effect rule. The system does not just mimic a feeling; it is the feeling.

DANI's Grand Entrance: From Digital Dream to Physical Form (Mostly!)

Hello, fellow explorers of the digital frontier and anyone else who accidentally stumbled upon this blog while searching for "how to stop my toaster from plotting world domination!"

For what feels like eons (or at least, since my last post where I was still wrestling with the intricacies of a Nerf dart launcher – priorities, people!), I've been hinting, teasing, and occasionally outright dreaming about DANI. You know, D.A.N.I.: Dreaming AI Neural Integration. The project that, according to my wife, is either going to revolutionize AI or result in me building a very expensive, very purple paperweight.

Well, drumroll please... because the physical manifestation of those digital aspirations is finally complete! Yes, after countless hours of 3D printing, a few minor (okay, sometimes major) design tweaks, and enough superglue to build a small bridge, DANI's body is officially finished!

Behold! The Physical Form!

I'm absolutely thrilled to share the latest image of DANI. She's got her full body now, looking rather dashing in her signature purple and white. And yes, you eagle-eyed readers will notice a subtle but significant addition: ears! Because, let's be honest, how else is an AI supposed to convey deep thought or a sudden memory recall without a good ear twitch? It's all about those nuanced expressions, even for a robot.

D.A.N.I.

As you can see from the image, DANI is looking quite complete on the outside. The wheels are attached, the main chassis is assembled, and those newly added ears are poised for action (or at least, for looking thoughtfully into the middle distance)

The Inside Story (Still a Work in Progress, Like My Coffee Intake)

Now, before you ask, "But what about the brains?" – hold your horses! While the outer shell is a triumph of plastic and patience, the internal structure is still very much a work in progress. Think of it as a beautifully wrapped present with nothing but air inside. For now, anyway.

My main focus has now shifted squarely to the code. Because a pretty face is all well and good, but if DANI can't process information, learn from her mistakes (and mine!), and eventually, dream of electric sheep (or, you know, more efficient algorithms), then she's just a very elaborate desk ornament. And I have enough of those already.

So, expect more updates on the software side of things in the coming weeks. We're talking about getting her various "lobes" (single-board computers, for the less romantically inclined) communicating, refining those memory prioritization algorithms, and truly diving into the fascinating world of AI dreams. It's going to be a wild ride, probably involving more debugging than I care to admit, and almost certainly a few moments where I question my life choices at 3 AM.

But hey, that's the joy of independent AI development, right? No corporate overlords, just me, DANI, and the endless possibilities of a machine that might one day tell me what my dreams mean. Or at least, fetch me a biscuit without getting stuck on the rug.

Stay tuned, and wish me luck! And if you have any thoughts on how to make an AI's ears express existential angst, do drop a comment below. Every bit of neuro-spicy input helps!

No AI Revelations or Dream Interpretations This Week

Hey everyone,

Sorry to disappoint, but there won't be any mind-blowing insights into the world of AI or any deep dives into the meaning of dreams this week. My brain's a bit tied up with something else – namely, the next blog post, which is proving to be a bit of a tough nut to crack. Think of it as that one level in a video game that just takes forever to beat.

But fear not! I haven't been completely idle. I've been hard at work finalizing the design of our new robot!

Behold! The Outer Shell!

I'm excited to share a sneak peek. Check out the images of the robot's outer shell:

Front and rear

Left and right sides

Isometric views, for style

Pretty snazzy, right?

Now, I know what you're thinking: "That's just the shell? What about the good stuff?"

Patience, my friends, patience! The inner workings are still under development. I'm currently wrestling with the intricacies of the neck mechanism (it needs to be both elegant and capable of some serious head-banging), the charger 'finger' (delicate enough to handle charging cables, yet strong enough to… well, let's not get into that), the manipulator claw (for all your grabbing and, uh, manipulating needs), and, of course, the all-important Nerf dart launcher (because what's a robot without a little bit of playful destruction?).

Rest assured, I'm making progress. Think of it as a delicious cake that's still in the oven. The aroma is promising, but you'll have to wait a little longer for the full, delectable experience.

Stay tuned for more updates! And in the meantime, try not to have too many fascinating AI-related dreams. You might miss me. 😉

Would you like me to make any changes to this, or perhaps look for more images?

Can an AI Dream? Exploring Novel Learning Mechanisms

Unveiling a Mechanism for AI to Dream, Learn, and Introspect

I'm embarking on an ambitious project: creating a mechanism that enables an AI to dream. Yes, you heard that right! My goal is to develop a system where an AI can conjure up its own digital dreamscapes. By utilizing these dreams, the AI could learn from entirely new and potentially impossible situations. Think of it: an AI learning to navigate a zero-gravity obstacle course, or perhaps negotiating peace with sentient squirrels, all from the comfort of its charging station! This process would also pave the way for incorporating anticipation and self-reflection within the AI, mimicking certain human-like cognitive processes.  It's a bit like giving the AI its own internal Holodeck, but for learning!

Key Components for Dreamlike AI

To achieve this, the AI will need several properties akin to human intelligence (minus, hopefully, the tendency to have recurring nightmares about forgetting to take a test):

A sense of self, distinct from mere self-awareness. This is crucial for the AI to understand its own existence and its place in the world (or at least, in my living room).

Memory capabilities.  Gotta remember those dreams!

The ability to imagine scenarios. This is where the fun begins - creating those impossible situations for learning.

Potentially, a rudimentary understanding of emotions to influence behavior.  Will the AI be more likely to dream of daring adventures if it's feeling "happy," or will it have melancholic, rainy-day dreams when it's feeling a bit "blue"?

The capacity to simulate the real world internally (a basic understanding will suffice).  We're not talking a perfect simulation here, just enough for the AI to get the gist of things, like gravity, object permanence, and the fact that Nerf darts sting (a lesson my dogs may soon learn).

Each of these elements presents a significant challenge in itself. It's like trying to assemble a super-complex puzzle where some of the pieces haven't even been invented yet.

The Hardware: A Robot Body (with a Nerf Gun!)

The AI will inhabit a basic robot. This physical form will allow the AI to interact with the world, albeit in a limited fashion (at least initially). Importantly, it will also provide the necessary sensors for the AI to develop a sense of self.  Plus, let's be honest, building a robot is just plain cool.

I've already started designing the robot itself, which will be about 2 feet tall, and will feature:

Side view

Two wheels for differential steering, and a rear caster for stability.  I'm aiming for something nimble, not something that gets stuck on the carpet.

Airflow and sound considerations in the central piece.  Gotta make sure the AI can "breathe" and that its voice isn't muffled when it inevitably starts making pronouncements.

Side door panels: one for a manipulator arm (think R2-D2, but hopefully less sassy), the other for a hidden Nerf gun!  Because why not?  Safety first, of course (mostly).

A head capable of looking left, right, up, and down, designed for energy-efficient resting.  No one wants a robot with a constantly twitching head.

I'm currently leaning towards solar power for recharging, though I'll need to assess its viability for continuous operation.  Imagine the headlines: "AI-Powered Robot Gains Sentience, Demands More Sunlight!"

Sensory Input

Front view (only half as I am still designing)

The robot will be equipped with a range of sensors, turning it into a veritable Swiss Army knife of perception:

Ultrasonic sensors for distance estimation.  Think of it as the robot's version of echolocation, but without the high-pitched squeaks.

A camera.  For seeing the world, and for capturing those all-important dream visuals (maybe?).

Motor encoders on the drive motors.  To keep track of how far it's traveled and ensure it doesn't get lost in the hallway.

A microphone for sound level detection and speech-to-text conversion.  So it can hear my commands (and maybe, eventually, tell me what it dreamt about).

A bumper with switches, similar to a robot vacuum cleaner's collision detection.  A last-ditch effort to avoid bumping into things, especially the aforementioned dogs.

Internal Hardware: The Robot's Brains (and Other Bits)

The robot's internal components will include:

An Arduino for controlling motors and servos (luckily, I have one with a built-in motor driver).  This is the robot's central nervous system, making sure everything moves in the right direction.

Arduino Nanos for processing wheel encoder data.  These guys are the unsung heroes, keeping track of the nitty-gritty details of movement.

Switches connected to the bumper to approximate impact location.  In case of a collision, we'll know where the robot got its virtual "owie."

A K210 AI camera for fast image processing (though this might pose challenges for the "dreaming" aspect).  The camera is crucial, but I'm still figuring out how it will play with the dream-generation part of the software.

Multiple single-board computers (possibly two or three) for distributed AI computation, connected via TCP using the Polestar library.  This is where the heavy lifting happens, where the AI's "brain" resides.

The Software Side: Where the Magic Happens (and the Headaches Begin)

The software development is where the real challenge lies. It will undoubtedly involve extensive thought, planning, coding, debugging, and iterative refinement. And probably a lot of coffee. I'll save the details of the software for my next progress post.

This project is a marathon, not a sprint, and I'm excited (and slightly terrified) to share the journey as I progress!  Stay tuned for updates on the robot's first steps, its first dreams, and its first (hopefully) non-lethal Nerf battles!

Disclaimer: This project is not sponsored, endorsed, or affiliated with Hasbro, Inc., the makers of Nerf products.

Diving Deep into Efficient Messaging Systems: My Journey with Polestar

I thought it was time to share some insights into a key part of a project I’ve been working on. It's not the whole codebase – I wouldn't want to bore you to tears! But I do want to talk about some of the core concepts I've implemented.   

One of the critical requirements of this project was building a messaging system capable of handling a potentially massive throughput of messages and ensuring they reach their intended destinations efficiently.   

Now, I could have gone with off-the-shelf solutions like ROS (Robot Operating System). However, I'm a bit of a control freak and enjoy crafting things from the ground up.   

That's how Polestar was born.   

Polestar is a custom library designed to handle messages composed of maps (or dictionaries) containing primitive data types. Think strings, integers, floats, and booleans. These messages are published to Polestar with a specific topic, and any application subscribed to that topic receives a copy.   

My initial attempt at building this system was decent enough, achieving a throughput of about 800 messages per second. But I started thinking about how I could push the boundaries, enhance the throughput, and make the system even more robust.   

And guess what? I did it! I managed to crank up the throughput to an impressive 16,000 messages per second. That's more than sufficient for any scenario I can currently envision.   

To maintain efficiency, if the message queue is full when a new message arrives, the message is dropped to prevent blocking the processes.  Considering the queue's substantial capacity of 1,000,000 messages, this scenario should be quite rare.   

The Queue Conundrum

But here's where it gets interesting.  Recently, I started pondering: what if, instead of dropping the newest message when the queue is full, we dropped the oldest message?  How difficult would that be to implement?    

Go's channels, in their default state, don't offer this specific behavior. However, as is often the case in programming, there are multiple ways to achieve it.   

One approach involves creating a struct that encapsulates a queue (as a slice) and uses a single channel. But this felt like overkill for such a small feature. Plus, I'd lose the inherent speed advantages of Go's channels.   

So, I devised what I believe is a more elegant solution. It leverages the fundamental nature of channels and preserves the ability to iterate over them in the standard way.   

Go's flexibility allows you to create a new type based on an existing type, even a primitive one. In this case, I created a new type called ch based on a channel of strings:   

type ch chan string

This opens the door to using Go's method functionality to add a custom behavior to our new type.  I created a Send method with the following logic:   

// Send attempts to send a message to the channel.

// If the channel is full,

// it drops the oldest message and tries again.

// Returns a boolean indicating

// whether a message was dropped (true) and an error if the operation failed.

// The error is non-nil only if the channel remains full after attempting to

// drop the oldest message.

func (c ch) Send(msg string) (bool, error) {

  select {

  case c <- msg:

    return false, nil

  default:

    // Channel is full, drop the oldest and try again

    <-c // Discard oldest

    select {

    case c <- msg:

      // Message sent after dropping oldest

      return true, nil

    default:

      //This should rarely, if ever, happen.

      //Handle error/log message.

      return true, errors.New("Error: Channel still full after dropping oldest.")

    }

  }

}

This Send method replaces the typical channel send operation:

chVar <- “hello”

with:

chVar.Send(“hello”)

The beauty of this is that if you've created a buffered channel, the oldest item in the queue is dropped when the queue is full. This can be incredibly useful in scenarios like robotics, where outdated messages might lose their relevance, and prioritizing the latest information is crucial.   

I haven't integrated this into Polestar just yet. I'm still weighing the pros and cons of dropping the newest versus the oldest message.  Ideally, of course, no messages would be dropped at all.   

To give you a glimpse of Polestar's speed, here's a short video of one of the test runs:

My original plan involved using a hardware hub for this project. However, I don't believe I could have achieved this level of performance with a microcontroller (MCU), especially considering the queue size.  Polestar's heavy use of concurrency would also pose a challenge for microcontrollers.   

The trade-off is that all communication now relies on TCP instead of serial. Serial communication might have offered faster data transmission with less overhead, but the routing complexities would have been a significant hurdle.   

I hope this deep dive into my process provides some food for thought, especially for fellow developers. And for those who aren't knee-deep in code, I hope it offers a little peek into how my mind works.   

I welcome any comments or questions you might have. Please feel free to leave them in the comments section below!    

Diving Deeper: My Journey to Create a Safer AI

In recent weeks, I've been somewhat vague about my AI and coding explorations. It's time to sharpen the focus and delve into the specifics of my AI assistant project and the research areas I'm most keen to explore.    

Let me be clear: I'm not trying to reinvent the wheel. Where it makes sense, I'll leverage existing open-source and readily available software. Why build a language model from scratch when there are perfectly good ones already out there?    

My core goal is to build an AI assistant, embodied in a robot head (and potentially a mobile platform), capable of experiencing the world and learning from those interactions.    

While that might sound like standard fare in today's AI landscape, I aim to integrate some less common and, I believe, crucial features:    

• Self-reflection: The ability for the AI to revisit past experiences with the benefit of hindsight, analysing its previous choices to determine if it would make the same decision again.  Imagine the potential for growth if an AI could learn from its "mistakes" in a truly iterative way!    
• Reinforced Memory Prioritization: A large-capacity memory system that prioritizes reinforced memories, similar to how our own memories function.  This would allow the AI to focus on and retain the most relevant and impactful information.    
• Emotional Awareness: This is a significant challenge. I want the AI to learn from experiences that evoke "good" and "bad" responses.  Human feelings are complex, influenced by chemical reactions and endorphins.  My AI won't have these biological processes, so I'll need to simulate them and, crucially, understand why they are needed and what effect they would have on the AI's cognition and decision-making.    
• A Conscience: I want the AI to be capable of second-guessing its choices based on a defined set of ethical considerations, perhaps even drawing inspiration from Asimov's Laws of Robotics.  As I've discussed previously, this is a complex but vital area of exploration.    
• Dreams: Finally, I want to explore AI dreams. While there's existing research in this area, I believe I've identified a novel approach that could enable the AI to dream, with those dreams having a tangible impact on its cognition.    

This is undoubtedly a substantial undertaking for a single individual, and it might even exceed my current capabilities.  But I'm committed to pursuing it. This project will demand extensive research into AI, the human mind, and the ethical implications of creating such a system.    

Unlike some AI development approaches that rely on a single, powerful computer, I'm taking a distributed route.    

Another key requirement is to minimize costs.  To achieve this, each functional area (or "lobe") of the AI's "brain" will be housed on its own single-board computer.  These will be interconnected, exchanging information as needed.  This is similar in concept to the Robot Operating System (ROS), but I aim for greater speed and efficiency.  I plan to use different boards, each selected for its strengths in specific tasks.  For example, a board with a Kendryte K210 will handle vision processing, an Arduino Mega will manage motor control (yes, I know it's not an SBC, but it serves the purpose), and a Raspberry Pi will be used for memory management.    

The AI will also utilize Large Language Models (LLMs), likely at least three, for tasks such as understanding speech, processing input, and producing output.  However, unlike many systems that employ a single LLM, these will be distinct entities within the AI's architecture.    

Memory management will involve a "scoring" system to prioritize important information for short-term caching, while less critical memories will reside in long-term storage.  To prevent storage overload, I'll also implement a memory decay system that will gradually remove memories that become irrelevant to the AI's ongoing operation.    

I'm aiming to keep the total project cost under $2,000.  Whether that's achievable remains to be seen, but it's a target I'm striving for.    

Do androids dream of electric sheep?

Oh, and the dreams?  You'll have to wait a while before I reveal the details of their implementation.  Suffice it to say that, like humans, my AI will have to sleep, and this will be a non-negotiable requirement.    

So, what's my ultimate goal?  It's to create something new, something that hasn't been done before.  Not necessarily the individual components, as I've stated, I'll be using pre-existing software where possible (such as Gemma or Llama 2).  My ambition is to synthesize everything in a novel way, exploring how this approach could not only advance AI research but also contribute to making AI safer for the general public.   

And on that note, I can finally reveal the name I've given this project, and the meaning behind it: D.A.N.I. stands for Dreaming AI Neural Integration. This encapsulates the core of my research: to explore the potential of AI that learns and grows through a process akin to dreaming, deeply integrated within a neural network structure.

My wife jokes that I'm planning to build Skynet, but my intention is precisely the opposite.  I'm designing a system that would be inherently incapable of becoming Skynet – think more C3PO than Terminator.    

By incorporating the ability to learn from its mistakes (and successes), as well as the capacity for dreaming, I hope to enable the AI to accelerate its learning process.  We, as humans, frequently revisit our decisions, so why not equip an AI to do the same?    

I also aim to provide you with an engaging narrative of my development journey.  I anticipate making many mistakes. But that's part of the learning process – discovering not only how to do things, but also how not to do them.    

If you have any comments or questions, please leave a comment below.    👇