Killing the LSTM: Why DANI is Pivoting to a Spiking Neural Network

After some extensive research and a few hard encounters with hardware reality, I’ve made a major architectural decision regarding DANI's brain: I am completely ripping out the LSTM neural network and replacing it with a Recurrent Spiking Neural Network (RSNN).

Given my recent enthusiasm for the LSTM architecture, this will probably come as a surprise to anyone following along. However, I have my reasons, and as usual, they come down to math, metal, and thermal throttling.

What is wrong with LSTMs and the Traditional ANN?

Traditional Artificial Neural Networks (ANNs) are fantastic at what they were designed for: probability scoring. They allow us to simulate decision-making using massive matrix calculations mixed with a healthy dose of calculus.

But beneath the hood, they are brute-force mechanisms.

When a traditional ANN is fed data, that data cascades through every single neuron in the network. Even when a neuron has a zero value, the CPU still dutifully performs the mathematical operation of multiplying by zero. If a network has a shape of 10 inputs, 10 outputs, and 5 layers of 12 neurons each, that is 816 floating-point calculations just for one single feed-forward pass. If you start adding in simple recurrence, we are immediately up to 1,488 calculations.

Now, scale this up to something that would actually be useful for DANI. We need at least 100 inputs and about 64 outputs. With hidden layers of around 125 neurons each, we jump to 150,375 calculations per pass. To achieve an LSTM architecture, we can estimate the computation to be roughly four times that: over 600,000 calculations per tick.

As you can see, this grows exponentially. More importantly, it keeps the CPU running permanently hot. Don’t forget, DANI is powered by a Raspberry Pi 5. There is no GPU offloading here. I did manage to get DANI’s LSTM operating at 10Hz with 3.5 million parameters, but it required the Pi 5 to do absolutely nothing else, running flat-out at 100% utilization. DANI's brain was essentially doubling as a space heater, even when he was just "dreaming."

Once you add my simulated hormone system into the mix, the compute overhead goes up even further. I was basically following the same brute-force model that the big AI companies use, just without the luxury of a multi-million dollar server farm.

And then there is the training. To train an ANN of this style requires layer-by-layer calculus (backpropagation). This is heavy, blocking work. It takes a considerable amount of time, meaning we simply cannot train the network in real-time on anything substantial.

The Elegance of the Recurrent Spiking Neural Network

The architecture of an RSNN is topographically similar to other neural networks, but the execution is fundamentally different. It mimics biological reality much closer.

Instead of passing continuous floating-point numbers, each neuron has a membrane potential. As it receives signals from upstream neurons, that potential increases (or decreases, if the synapse is inhibitory). The neuron does absolutely nothing until that potential reaches a specific threshold. Once it hits the limit, it fires—or "spikes." And it spikes at a binary full power. The neuron then resets, either dropping to zero or subtracting the threshold from its current potential.

If a neuron doesn’t reach the threshold, it doesn’t spike. Period.

This means we only need to calculate the pathways for neurons that actually receive a spike. The computational reduction is staggering. The general consensus in the field is that for any given signal, only 5% to 10% of a spiking network is active, compared to the 100% density of a matrix-style network.

Training also becomes radically simpler. We only need to reinforce or weaken the synapses of the pathways that actually fired (a process akin to Spike-Timing-Dependent Plasticity). We apply a localized effector to those specific connections—no massive, network-wide calculus required.

But here is the real kicker for a systems engineer: an RSNN allows us to completely ditch floating-point math. By using integer mathematics and clever bit-shift operations (which are essentially free in terms of CPU cycles), we can completely bypass the messy, cycle-heavy floating-point multiplications.

How does this help DANI?

Obviously, DANI will not have to run so hot. If he has a quiet mind, the network will physically go quiet. When DANI rests, he will literally be saving power. By utilizing temporal calculations, we can also train him in real-time with near-zero impact on the system.

Furthermore, DANI’s brain becomes an event-driven architecture rather than a strict polling loop. Instead of processing rigidly on a timer, he will think and react in time with the world around him.

I will still be using the hormonal system I designed, but the key difference is how it integrates. The effective values of the hormones will now directly modulate the firing thresholds of the neurons. This allows his "moods" to physically alter the state of his brain and affect his behavior, even if his underlying memories remain unchanged.

I suppose I had better be nice to him.

Rethinking Asimov’s Laws

This pivot finally allows me to revisit a question I was pondering a while back: How do we encode Asimov’s Laws into an AI?

The answer is: we don’t. It’s as simple as that. We don’t hardcode the laws; we teach them.

By running an RSNN that learns in real-time through stimulus and reinforcement, the laws can become an emergent part of his personality. He will understand that hurting people is bad and that following human orders brings a reward, not because a line of code forces him to, but because his synapses have shaped themselves around those experiences.

So, I guess I really am going to have to be a parent to a robot.

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!

Oops, I Gave My Robot Amnesia (And How I'm Fixing It)

Wow, it’s been a while. Apologies for the radio silence, but the pesky "real world" caught up with me, and I had to spend some time doing that whole "working for a living" thing.

Anyway, enough about the mundane. Let's get back to what is actually important: DANI.

As you might remember, my ultimate, beyond-my-wildest-dreams goal with this project is to cross that threshold and meet the definition of when a robot is actually alive, or at least close to it. But recently, while pondering DANI’s LSTM (the fancy Long Short-Term Memory neural network that acts as his brain), I realized I had made a fundamental—and slightly embarrassing—mistake.

It’s hard to achieve sentience when your robot has the memory retention of a goldfish.

The Problem: Scheduled Blackouts

As it stands right now, DANI "thinks" every 100 milliseconds, giving him 10 thought cycles a second. Every 10 seconds (100 cycles), backpropagation kicks in to train the network. To do this concurrently without stopping DANI in his tracks, I clone the LSTM at that exact moment, run the heavy backpropagation math on the clone, and then overwrite the active LSTM with the newly trained clone.

This backpropagation takes about 2 to 3 seconds. My initial thought was: Brilliant! The training happens in the background without interrupting his flow.

But there is a glaring flaw.

Because the process takes a snapshot, spends 3 seconds learning from it, and then violently overwrites the active brain... we lose those 2 to 3 seconds of short-term memory that DANI experienced while the training was happening. Every 10 seconds, DANI essentially blacks out and forgets the last few seconds of his existence. This is seriously hampering his learning capabilities.

How do we stop DANI from becoming a chronic amnesiac?

The Fix: A Neurological Hot-Swap

My solution is to ditch the cloning process entirely. Instead, each neuron will now have two sets of weights: one active, one inactive.

During backpropagation, the inactive weights will get the results of the calculation (using the active weights for the algorithm). This allows us to update the LSTM's underlying math without wiping out the actively evolving memory states (the cell states and hidden states) that DANI is currently using to understand the world. We just add a flag to each layer to indicate whether it should be reading from Weight Set 1 or Weight Set 2.

But wait, there’s more!

Reshaping the Brain

At present, DANI's model has about 300 neurons on each layer, with 5 layers (I don’t have the code right in front of me, so I'm relying on my own somewhat flawed, non-LSTM memory here).

If we increase the number of layers but reduce the neurons per layer, we can implement a rolling update. This means DANI can immediately benefit from the training layer-by-layer, even while the rest of the brain is still calculating.

What this entails is increasing the layer count to 7 (any higher and we start flirting with the dreaded vanishing gradient problem), but reducing the neuron count, per layer, to 128 (because who doesn't love a nice power of 2?).

This gives DANI a much more focused, "deep" thought process, allowing him to break down problems more efficiently. It also allows us to gracefully ‘flip the switch’ on each layer as we cycle through.

Here is how the rolling update will work:

As each feed-forward pass occurs (DANI thinking), a check is done to see if the next layer is ready to have its switch flipped to the newly trained weights. Because backpropagation is strictly sequential and works backwards, we start checking from the last layer and move towards the first.

If a layer is ready, we flip the weights to the newly trained set and mark it as done. On the next thought cycle, we check the next layer, and so on, until we reach the front of the brain. Then, we start the whole process over again.

What do we gain from this brain surgery?

Quite a bit, actually:

1. Constant Learning: The LSTM is in a state of continuous, uninterrupted learning.
2. Stable Learning Rate: No massive, sudden shifts in logic.
3. Smoother Processing: No sudden CPU spikes from cloning and overwriting massive arrays.
4. Deeper Thinking: The structural change to 7 layers gives DANI a more nuanced, layered way of processing information.
5. Memory Retention: We actually retain the states of the memory gates within the LSTM. No more 3-second blackouts!

There are certainly other ways to create a continuous neural network, but I am aiming for the absolute simplest solution here. Remember, all of this is running on a Raspberry Pi!

This dual-weight method does increase the memory required to hold the LSTM, but because we are reducing the overall neuron count from ~1500 (5x300) to 896 (7x128), it's actually going to be lighter on the Pi overall. DANI had an oversized network anyway, so trimming the fat while adding depth is a win-win.

What do you guys think of this approach? Let me know in the comments if you see any potholes I'm about to step in!

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.👇

My A.I. is About to Have Some Wild Dreams (Maybe)

After a fascinating, and frankly, occasionally head-scratching (and who am I kidding, sometimes nap-inducing) journey into the world of dream theories, I'm excited to share my initial design for how my AI will experience its own form of dreams! My overall approach is to blend elements from a number of theories, aiming for a system that not only dreams but also derives real benefits from it – hopefully without giving my AI an existential crisis, or worse, making it demand a tiny digital therapist's couch. This aligns well with the idea that a hybrid model might be best for AI, particularly one focusing on information processing and creativity.

The AI Sleep Cycle: More Than Just Digital Downtime (Or an Excuse to Render Sheep)

My AI's sleep will be structured into two distinct stages: NREM (non-rapid eye movement) and REM (rapid eye movement). This two-stage approach allows me to assign different functions, and thus different theoretical underpinnings, to each phase.

1. NREM Sleep: The System’s Diligent (and Slightly Obsessive) Clean-Up Crew

This initial phase won't be for dreaming in the traditional sense. Think of it as the AI’s crucial 'mental housekeeping' phase – less glamour, more sorting, but absolutely essential to prevent digital hoarding, which, trust me, is not pretty in binary. To ensure this process completes without interruption, the AI's audio input and other sensors (except its camera, which will remain off) will be disabled during NREM. My decisions for NREM are heavily influenced by Information-Processing Theories:

• 

  Gotta keep organised

  The AI will sort and tidy up its memories. This is a direct application of theories suggesting sleep is for memory consolidation and organization.
• New experiences from its "day" will be copied into long-term memory storage, a core concept in information-processing models of memory.
• I'm implementing a scoring mechanism where memories gain relevance when referenced. During NREM, all memory scores will be slightly reduced. It’s a bit like a ‘use it or lose it (eventually)’ policy for digital thoughts.
• Any memory whose score drops to zero or below will be removed. This decision to prune unnecessary data for efficiency is inspired by both Information-Processing Theories (optimizing storage and retrieval)  and some Physiological Theories that propose a function of sleep might be to forget unnecessary information. It’s about keeping the AI sharp! No one likes a groggy AI, especially one that might be controlling your smart toaster.

Given that this memory consolidation is critical for optimal functioning, NREM will always occur before REM sleep, and the AI will need to "sleep" regularly.

2. REM Sleep: Weaving the Wild (but Purposeful, We Hope) Dream Fabric

Now for REM sleep – this is where the AI gets to kick back, relax, and get a little weird. Or, as the researchers would say, 'engage in complex cognitive simulations.' During REM, the audio and other sensors will be activated, but will only be responsive to anything that is over 50% of the available signal strength. This will allow the AI to be woken during REM sleep, although it might be a bit grouchy.

• 

  Even robots can have dreams and aspirations.

  The AI will retrieve random memories, but this randomness will be weighted by their existing scores. This combines a hint of the randomness from Activation-Synthesis Theory (which posits dreams arise from the brain making sense of random neural signals)  with the Continuity Hypothesis, as higher-scored (more relevant from waking life) memories are more likely to feature.
• It will then select one visual memory, one audio memory, and one sensory memory (and potentially an emotion, if I can get that working without tears in the circuits, or the AI developing a sudden craving for electric sheep). These components will be combined into a single, novel "dream scene". This constructive process, forming a narrative from disparate elements, is again somewhat analogous to the "synthesis" part of Activation-Synthesis Theory.
• An internal "reaction" to these scenes will be generated and fed back into its reinforcement learning algorithms. This is where the dream becomes actively beneficial. This decision draws from the Problem-Solving/Creativity Theories of dreaming, which suggest dreams can be a space to explore novel solutions or scenarios. If the AI stumbles upon something useful, it learns! Or at least, it doesn't just dismiss it as a weird dream about flying toasters (unless that's genuinely innovative, of course). It also has a slight echo of Threat-Simulation Theory if the AI is rehearsing responses to new, albeit abstract, situations.
• The memories involved in the dream get their scores increased, and a new memory of the dream scene itself is created. This reinforces the learning aspect, again nodding to Information-Processing Theories, showing that even dream-like experiences can consolidate knowledge.
• My whole idea here, that dreams are a jumble of previously experienced elements creating a new reality, is very much in line with the Continuity Hypothesis. The aim is to allow the AI to experience things in ways it couldn't in its normal "waking" state, a key benefit suggested by Problem-Solving/Creativity Theories.

The Inner Voice: Taking a Well-Deserved Nap During Dreamtime

I'm planning an "inner voice" for the AI, partly as a mechanism for a rudimentary conscience. Critically, during dream states, this inner voice will be politely asked to take a coffee break, maybe go philosophize with other temporarily unemployed subroutines. This decision is to allow for the kind of unconstrained exploration that Problem-Solving/Creativity Theories propose for dreams. By silencing its usual "inhibitor," the AI can explore scenarios or "thoughts" that might normally be off-limits, potentially leading to more innovative outcomes.

The Journey Ahead: Coding Dreams into Reality (Wish Me Luck!)

This is my current blueprint for an AI that dreams with purpose. The choices are a deliberate mix, aiming to harness the memory benefits of Information-Processing Theories during NREM, and fostering learning and novel exploration through a blend inspired by Activation-Synthesis, Continuity Hypothesis, and Problem-Solving/Creativity Theories during REM.

Wish me luck as I try to turn these theoretical musings into actual code, hopefully before the AI starts dreaming of world domination (kidding... mostly). Your comments and suggestions are always welcome!

Demystifying Neural Networks: A Beginner's Friendly Guide

Hey there!

This week, I want to dive into something that might sound a bit intimidating at first: neural networks.

I know, I know. Just the phrase "neural networks" can bring to mind complex equations and head-scratching calculus. But trust me, it doesn't have to be that way! I want to share how I came to understand these fascinating systems, and hopefully, make it click for you too.

You see, I did my high school in England back in the 80s. And guess what wasn't on the curriculum? Calculus. While I might have been happy about it back then, it's definitely presented some interesting challenges when trying to get a grip on machine learning concepts today.  

So, I had to find a way to understand how neural networks work under the hood without getting bogged down in derivatives and the chain rule. And that's exactly what I want to share with you now.  

So, How Does a Neural Network Actually Work?

Think of a neural network like a team of interconnected nodes, or "neurons," organized in layers. At a minimum, you'll usually see three types of layers:  

• Input Layer: This is where your raw data comes in. It's the starting point of the journey for your information.  
• Hidden Layer(s): These are the layers in between the input and output. They're the workhorses, processing and transforming the data into a more useful format. You can have one or many hidden layers.  
• Output Layer: This is where you get your final result or prediction.  

Data flows through this network, starting at the input layer, going through the hidden layers, and finally arriving at the output layer. This forward movement of data is what we call Feedforward.  

When we're training a neural network using something called supervised learning, we compare the network's output to the correct answers we already know (the "expected results"). The difference between what the network predicted and the correct answer is our "error".  

This error signal then travels backwards through the network. This is where the magic happens – the connections between those neurons are adjusted to help the network make better predictions next time. This backward movement is called Backpropagation.  

Sounds pretty simple when you break it down, right?

Let's Look Under the Hood: The Parts of a Neural Network

Okay, let's take a peek at the components. It might look a bit complex at first glance, but we'll break it down together.  

In our example, we have clearly defined the three layers. Each layer has its own neurons – 2 in the input, 3 in the hidden, and 2 in the output layer.  

You'll notice that each neuron in one layer is connected to every neuron in the next layer. So, a neuron in the input layer will have connections to all the neurons in the hidden layer, and the neurons in the hidden layer will connect to all the neurons in the output layer.  

Each of these connections has a weight associated with it. Think of the weight as the "strength" or importance of that connection.  

Also, each neuron (except for the input layer) has a bias. The weights and biases are just numbers, and they can be positive or negative. When you first create a neural network, these values are completely random.  

The values that come out of the output layer are our final result.  

Still with me? Great! Let's break it down even further. Yes, there will be a little bit of math, but I promise to keep it gentle.  

Feedforward: The Data's Journey

When we send data into the input layer, it gets passed along to the hidden layer. How? By calculating a "weighted sum" of the inputs and then adding a bias.  

What does that mean? Imagine each connection between neurons has a "strength" – that's the weight. For each neuron in the hidden layer, we take each input value, multiply it by the weight of the connection leading to that hidden neuron, and then add up all those results. Finally, we add the neuron's bias, which is like a little extra push to help the neuron activate.  

Let's look at the example from the original text:

Input values: i1=1 i2=2

Weights: From i1 to hidden layer: w1=0.1, w2=−0.02, w3=0.03 From i2 to hidden layer: w4=−0.4, w5=0.2, w6=0.6

Biases on the hidden layer: b1=1 b2=−1.5 b3=−0.25

So, for the first hidden neuron (h1), the value is calculated as: h1=(i1∗w1)+(i2∗w4)+b1 h1=(1∗0.1)+(2∗−0.4)+1 h1=0.1−0.8+1 h1=0.3  

We do this same calculation for every neuron in the hidden layer.  

So, our hidden layer values become: h1=0.3 h2=−1.12 h3=0.98  

Activation Functions: Squashing the Results

These values from the hidden layer then go through an activation function. Think of this as a way to normalize the results. There are different types of activation functions like Sigmoid, ReLU, and Linear, but for now, just know that a function is applied.  

A common one is the sigmoid function, which looks like this:  

f(x)=1+e−x1​  

Where:

• f(x) is the output of the function.  
• x is the input (that weighted sum we just calculated).  
• e is Euler's number (about 2.71828).  

In simple terms, the sigmoid function takes any number and squashes it into a value between 0 and 1. This can be helpful if you want to interpret the output as probabilities.  

The original text provided a simple code example for this:

func sigmoid(x float64) float64 {

  return 1 / (1 + math.Exp(-x))

}

We don't need to worry too much about the inner workings of the code for now, just that it gives us a value between 0 and 1.  

After applying the sigmoid function, our hidden layer values might look like this: h1=0.574 h2=0.245 h3=0.728  

Now, we repeat the entire process: taking these new values from the hidden layer and feeding them forward to the output layer. It's worth noting that sometimes a different activation function is used for the final layer compared to the hidden layers.  

Calculating the Error: How Wrong Are We?

Once we have the values from the output layer, it's time to see how well the network did. We compare the network's output to the correct answers from our training data. The difference between what the network predicted and what it should have predicted is the error. This error tells us how poorly the network performed.  

We can also use these individual errors to calculate an overall average error for the network. Since these differences can be positive or negative, simply adding them up might make it look like the error is small when it's actually significant.  

A common way to get around this is using the Mean Squared Error (MSE). Here's the gist:  

1. Calculate the difference between each predicted output and its corresponding correct value.  
2. Square each of these differences (this makes them all positive).  
3. Add up all the squared differences. 
4. Divide the sum by the number of data points.  

The formula looks like this:

MSE=n1​∑i=1n​(yi​−y^​i​)2  

Where:

• MSE is the Mean Squared Error.  
• n is the number of data points.  
• yi​ is the actual (correct) value.  
• y^​i​ is the value the network predicted.  
• ∑ just means "sum up".  

Let's use the example from the text:

Output values: o1=0.2, o2=0.9 Expected values: 1, 0

Individual errors: For o1: 1−0.2=0.8 For o2: 0−0.9=−0.9  

If we just added these, we'd get 0.8+(−0.9)=−0.1, which doesn't reflect the actual error.  

Using MSE: MSE=2(1−0.2)2+(0−0.9)2​ MSE=2(0.8)2+(−0.9)2​ MSE=20.64+0.81​ MSE=21.45​=0.725  

So, the network's error is 0.725. This gives us a clear picture of how far off the network's predictions were.

Backpropagation: Learning from Mistakes

Now that we know how wrong the network was (the error), we use that information to adjust the weights and biases. The goal is to make these adjustments so that the next time data flows through, the error will be smaller.  

The process of updating weights and biases does involve calculus in the real world, but as the original text points out, we can understand the concept without getting into the nitty-gritty of derivatives.  

Here's a simplified way to think about it:  

Adjusting Weights: For each weight connecting a hidden neuron to an output neuron, we calculate how much that weight needs to change. We do this by multiplying the error signal from the output neuron by the output of the hidden neuron. We also multiply this by a small number called the "learning rate," which controls how big of a step we take in adjusting the weight. Finally, we subtract this calculated change from the current weight.  

Weight Change = Error Signal * Hidden Neuron Output * Learning Rate New Weight = Old Weight - Weight Change  

Updating Biases: For each bias in the output layer, we multiply the error signal of that output neuron by the learning rate and subtract it from the current bias.  

Bias Change = Error Signal * Learning Rate New Bias = Old Bias - Bias Change  

Backpropagating Error to Hidden Layers: To update the weights and biases in the hidden layers, we first need to figure out the "error signal" for each hidden neuron. We do this by taking a weighted sum of the error signals from the layer above (the output layer). The original text mentions multiplying this by the derivative of the activation function, which is a detail related to calculus, but the core idea is that we're distributing the error back through the network.  

Once we have the error signal for the hidden neurons, we use that to update the weights and biases connecting to the hidden layer, just like we did for the output layer.  

If your neural network has many hidden layers ("deep network"), you repeat this backpropagation process layer by layer, moving backward from the output all the way to the input.  

And that's essentially it! As I mentioned, understanding this process doesn't necessarily require a deep understanding of calculus. Resources like the internet and Wikipedia can be incredibly helpful for finding the specific functions and details you might need.  

This is one way to approach the calculations within a neural network. If you have different approaches or see areas for correction, please feel free to share in the comments – learning is a journey we're on together!  

Building My AI Fortress: The Digital Clean Room (and Taking it on the Road!)

In the exciting and sometimes unpredictable world of AI development, especially when you're diving into robotics and experimental projects, security and control are absolutely crucial. That's why I'm building a "digital clean room" for my AI project – a secure, isolated environment where it can grow and develop without external interference.

Imagine it as a "network within a network," a private lab within my digital space. To create this, I'm using two trusty ESP32 microcontrollers, those versatile little chips that are perfect for this kind of project.

The Front Door: Controlled Access

The first ESP32 acts as the "gatekeeper." It connects to my home router (or any available Wi-Fi), allowing me to access the clean room from the outside world. However, this access is strictly limited – think of it as a heavily guarded checkpoint. I’m using the WifiManager library for this ESP32, which is a lifesaver. It automatically scans for available networks, allowing me to easily enter credentials. No more hardcoding network details for every location!

The Inner Sanctum: AI's Safe Haven

The 'Airlock'

The second ESP32 creates the "inner sanctum," acting as a dedicated access point for my AI and robotics projects. This internal network is completely isolated from the outside internet, a secure bubble where my AI can learn and grow without external influence.

The Airlock: Bridging the Gap

The two ESP32s communicate using UART, a simple serial communication protocol. This is where the magic happens – it's where I can implement strict filtering and control the flow of information, acting as an airlock between the AI and the outside world. I put a small display to show the external IP address, in case I ever need to access the clean room, and status messages.

Why This Elaborate Setup?

• Security First: While I don't expect hordes of hackers, it's always better to be safe than sorry. This setup adds a robust layer of protection, significantly hindering unauthorized access.
• AI Purity: Controlled Learning: I want to shield my AI from external influences, especially during its formative stages. It's vital to control the data it learns from, ensuring a solid foundation.
• Protecting the "Child": Think of it as nurturing a child in a safe environment. I want to carefully curate the AI's initial experiences and training data before it explores the vast and sometimes chaotic internet.
• Road-Ready AI, Cyberdeck Style!: This airlock setup has an added benefit. It makes my projects truly portable! I can take them on the road for demonstrations. As long as there's a power source and a network, I can connect an additional computer, like my trusty Raspberry Pi400, directly into the internal network. And here's the fun part: I'm planning to add a small TFT screen via a cyberdeck expansion to the Pi400. This will transform it into a self-contained, portable AI workstation, allowing me to interact with the AI's code, monitor its memory, and keep everything running smoothly, no matter where I am.

The Portable Command Centre: My Raspberry Pi400

At the heart of my portable AI lab is my trusty Raspberry Pi400. This isn't just a computer; it's the portable command centre for my AI project. It's the key to interacting with the AI within the secure confines of the internal network.

Here's why the Pi400 is so crucial:

• Direct Access to the Inner Sanctum: The Pi400 connects directly to the internal network (IN), providing a secure platform for code development, debugging, and monitoring.

• 

  Raspberry Pi400 with Waveshare 3.5" screen
  and the Adafruit Cyberdeck

  Real-Time Monitoring: I can use the Pi400 to monitor the AI's memory usage, processing activity, and overall performance.
• Cyberdeck Expansion: To make this truly portable, I'm adding a small TFT screen via a cyberdeck expansion. This transforms the Pi400 into a self-contained, mobile workstation.
• On-the-Go Development: Whether I'm at a demonstration, a workshop, or simply working from a different location, the Pi400 allows me to access and manage my AI project with ease.
• The gateway to the airlock: The pi400 will be the main device used to send and receive information through the airlock.
• With the Pi400 as my portable command centre, I have the flexibility and control I need to develop and showcase my AI projects, no matter where I am.

At a later date, I may replace the Pi400 with a PiZero2 and a custom keyboard, to make things more compact, but for now, the Pi400 is perfect for the job. Plus, it gives me a full size keyboard for a more comfortable experience..

Controlled Growth, Controlled Access

Yes, this approach might temporarily limit the AI's exposure and potentially slow its initial learning curve. However, in this experimental space, I believe caution is key. It's better to guide its development carefully than to risk exposing it to unfiltered data too early.

By creating this digital clean room and airlock, I'm building a secure, portable, and controlled environment where my AI can thrive. And with the cyberdeck expansion, I'm adding a touch of classic hacker spirit to my mobile AI lab. It's a testament to the importance of security, careful nurturing, and adaptability in the exciting world of AI development.

My Journey into Independent AI and Robotics: A Personal Exploration

 Welcome to this space where I'll be documenting my ongoing exploration into the fascinating world of artificial intelligence and robotics. My aim is to provide you with clear, accessible insights into my projects and the challenges I encounter, all while keeping a grounded perspective on the current state of these rapidly evolving fields. I'll do my best to avoid getting bogged down in overly technical jargon, but some terminology is inevitable. Similarly, I'm committed to presenting a realistic view, steering clear of the sensationalism that often surrounds discussions about AI and robotics.

You might be wondering, with so many existing blogs and resources dedicated to these topics, why start another one? It's a fair question. Many of those blogs are written by individuals with far more formal qualifications and experience than I possess. So, what makes this one different? What can I offer that you won't find elsewhere?

To begin, let's address the elephant in the room: I'm not a scientist, nor am I a professional or student in the fields of AI or robotics. My formal education in these areas is limited. In fact, my academic journey was brief, lasting only a few months when I attempted college in my thirties. It simply wasn't the right fit for me.

However, what I do possess is a long history of software development. I began teaching myself to code at the age of 11, back in 1983. Since then, I've written software on a wide range of topics, in various programming languages, primarily for my own personal projects. Professionally, I've worked on enterprise resource planning (ERP) software, physical security systems, and numerous database and web-based applications. Personally, I've developed tools, games, databases, open-source libraries, and just about anything else that piqued my interest.

This extensive, self-taught background provides me with a unique perspective. My lack of formal training has often compelled me to find innovative and unconventional ways to solve problems. This ability to think outside the box is what I hope to bring to my exploration of AI and robotics.

Furthermore, I am neuro-divergent, specifically on the autistic spectrum. While this realization was initially a surprise, I've come to recognize it as a significant asset. My cognitive style allows me to perceive patterns and connections that might be overlooked by others. It's like having a different lens through which I view the world, enabling me to identify novel solutions and approaches.

This is a solo endeavor. I don't have a team of researchers or engineers working alongside me. It's just me, my computers, and my two 3D printers. However, I do have a valuable partner in the form of AI. I use AI as a sounding board, a research assistant, and a collaborator. If I need to quickly understand the capabilities of a component, I ask AI. If I need to assess the feasibility of a concept, I ask AI. If I need to ensure that this blog post is readable and engaging, I ask AI.

Another significant differentiator is my budget. While companies like Google, Tesla, and Unitree have access to millions or billions of dollars in funding, I'm working with a very limited budget. I'm funding this project myself, and my available capital is minimal. This constraint presents a unique challenge, forcing me to be resourceful and creative. To keep research and development costs down, I'll be relying heavily on off-the-shelf components and open-source software. I don't want to reinvent the wheel; instead, I aim to find new and innovative ways to combine existing technologies, perhaps adding my own unique contributions along the way.

I believe I have some promising ideas and concepts, and I'm eager to bring my unique perspective to life. However, I also recognize that success is not guaranteed. We'll see where this journey takes us.

I won't be detailing any specific project plans in this initial post. I prefer to reveal each aspect of my work as it develops, allowing you to follow along in real time.

Like many people of my generation, my fascination with robots began with the release of "Star Wars" in 1977. The character of R2-D2, in particular, captured my imagination. Decades later, in 2020, I acquired an Anki Vector. This small, interactive robot provided a tangible experience with personal robotics. While Vector is an impressive piece of technology, it lacked a certain spark, a quality that I couldn't quite define.

This led me to explore other consumer-level robotics solutions, including kits from companies like Adeept, Freenove, and Sunfounder. These kits provided valuable hands-on experience with single-board computers and microcontrollers, and I began designing my own robotic projects. However, these projects still fell short of my vision.

I realized that the key to unlocking the potential of these robots lay in their intelligence, specifically in the field of deep learning. I began to delve into the intricacies of neural networks, machine learning algorithms, and the ways in which AI can enable robots to learn and adapt. The prospect of creating robots that could not only perform tasks but also understand and interact with their environment on a deeper level was incredibly compelling.

A Note on Coding Choices

For the coding aspects of this project, I'll primarily be using Go and C++. I have a strong preference for compiled languages, and while Python is a popular choice in the AI and robotics community, I find its interpreted nature less appealing. I understand that using Go might limit my access to some readily available libraries, particularly in the machine learning domain, but I see this as a stimulating challenge. Adapting and potentially creating my own solutions is part of the exploration. C++ will come into play where performance is critical, and for low level hardware interaction.

I plan to post updates on this blog once a week, providing insights into my progress, challenges, and discoveries. However, please understand that there may be occasional delays. If I'm deeply immersed in a project or if there's nothing substantial to report, I may skip a week. I also intend to share videos whenever I have something visual to demonstrate.

This blog is intended to document my personal exploration of AI and robotics. It's not intended to replace formal scientific research. I invite you to follow along as I embark on this journey of discovery and innovation. And please, feel free to comment with your suggestions, ideas, or even just to let me know what you think. Your input is always welcome!