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.

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.

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!  

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!