536: I've Seen a Giraffe
00:07 Welcome to Embedded. I am Elysio White alongside Christopher White. Our guest this week is David Such, author of a new book about Embedded AI. Hi, David. Welcome. Hi, both of you. Thank you very much for having me. Could you tell us about yourself as if we met for lunch on the Sydney Harbor? Sure. Well, it's a lovely day on Sydney Harbor today. I'm David Such, an electrical engineer based in Sydney. I run Reef Wing Software, which is a design and hardware and firmware company, and I enjoy writing about both those subjects. I also have a degree in mine science and do some mentoring at Sydney University. I started off in automation and controls at a company called Honeywell and worked for them both here and in the UK,
00:58 and then headed off down the management route and ended up running a large facilities management business a bit over 10 years ago. I pulled the pin on that and made the decision to come back to engineering, which is what I actually enjoy doing. And for the last few years, my focus has been on machine learning, on microcontrollers, and that morphed into the embedded AI book, which you mentioned. Thank you. We will be mentioning it a lot more, but first, we want to do lightning round, or we ask you short questions and we want short answers, and we may not entirely behave ourselves and say,
01:34 why, when, what, how. But we'll try to keep it short. Are you ready? I am ready. When will the robots win and will they be merciful? I think we're another five to ten years off. It's what I could do in that time. I'm an optimist. I'm a robot optimist. And will they be merciful?
01:59 Well, that's the optimism side. So I think they would be. Okay. Data-driven or theory-driven? Data, 100% data. I think you start with the theory and then confirm it with the data. Are giraffes real or were they hallucinated by hell-l-l-l-lams? I think they're real. I've seen a giraffe.
02:21 Okay. Are they as improbable in person as they sound when you say camel leopard with a giant neck? They are amazing, beautiful creatures. They've got very long tongues. I don't know if you know that. I was feeding one at the city zoo with a carrot, and it's got a very long tongue. Python or C?
02:47 Depends, can I say that? I'd say C on device and Python on the PC. Learning, doing, or teaching? Teaching. Complete one project or start? Start a dozen. Start a dozen. I've always got a bunch of stuff in progress and some never finish.
03:06 Do you have a favorite fictional robot? I do. It's the robot on Lost in Space. I think it's called the B9 class environmental control robot. And an honorable mention to Robbie the Robot and Forbidden Planet. Do you have a tip everyone should know? Yes, read the data sheet. Should you believe the day of the issue?
03:32 Well, not always, but I think, you know, they look very intimidating, but the number of times that it's helped me solve a problem or discover why something's not working, I think it's very important. So you recently wrote a book, and when I talked to you about it a couple months ago, as you were finishing, you were in that stage of what have I done? with my life and how did this happen? How can I make it stop? Yes. So it took two years and was a lot harder
04:09 than I was expecting. I don't know if you found that. Oh yes. I actually... The second version, the second edition was a lot easier. Yeah, well, I guess at least you're starting with something then. And as part of that process, I rewrote the book about five. time. So by the end, I was sick of reading it, for sure. By the end of the first edition, I had read it several times, and I had finally truly learned how to write. And so with the second edition, I didn't have to learn how to write again. Oh, well, that's helpful. And look, writing's like any other skill of it. The more you practice it, the better you get at it. Absolutely. So your book is not a
04:56 general AI. It is about embedded AI. I mean, that's the title, so let's call that obvious. But are you talking about Jetsons and Raspberry Pi's or proper microcontrollers? So I use, it's a very much a project-based book. And what I wanted to do was, it's, it's fairly expensive too. And what I didn't want to load on top of that is making, the reader have to go out and buy $700 worth of hardware to be able to do the projects in the book. So what I've tried to do is select some fairly commonly available microcontrollers that are too expensive, which still allow you to do something useful. And for me, it was mostly about learning exercise.
05:50 And so I was selecting for that more than for, you know, if you were trying to build something. for production necessarily. And is the goal for it to be a textbook or a series of projects for a hobbyist or someone entering the field or is it a professional manual? So it's a good question. I think it's an intermediate book. So this is probably not the first book you're going to read on the subject. And I expect the reader to have some notes.
06:26 knowledge of electronics and to be able to read a schematic and to have some understanding of uploading firmware, but not necessarily a lot of knowledge around machine learning or AI. So I think there's a, there's a spectrum along there. It's probably, it's for people in like engineers or people that are transitioning, there may be embedded engineers, looking at move into machine learning, or it might be students, people like that. That makes sense. You deeply covered a few areas that I often see people struggle with. Your IMU chapter, which I expected to be just, here's how you use an IMU,
07:15 went into a lot more detail about sensor fusion and even Kalman filters. But how is that machine learning? That's all very heuristics. Right. So what I was trying to do was to provide the necessary tools to be able to do the work. And where that all came from, the book I wrote before this book was actually about drones and flight control software. And the problem was I was five years too late for that, and so no publishers were interested in it. but the fact is that you need to be able to get the right data into your project, and that starts at the senses.
08:01 And so, you know, I think there's three chapters that focus on how you can use those cheap sensors and provide practical data from them, which you require for any sort of embedded project. But how many filters in particular? I mean, you had some other filters and how to deal with the data and how to calculate, how to use quaternians and all the things that I have done with IMUs so many times. It was kind of a joy to be able to say, oh, well, now I'm going to stop explaining this and just start pointing people to this. But it's not, I expected convolutional neural networks, which you have, and recurrent neural networks, which you have. But I wasn't expecting that. Is it from the approach that your data has to be cleaned or put in a, for a microcontroller,
08:57 especially put in a more compact format than just throwing it all the raw sensor data? Yes, that's part of it. And it's also part of this, my thesis, that intelligence is moving further and further to the edge. And so, you know, the edge used to be the microcontroller, but now the edge is the sensor. and I've got a few projects in there where there's machine learning happening on the sensor so you don't even have to bother the microcontroller. And I think what a lot of people don't realize about IMUs
09:28 is they give you these readings, which are not very useful, are they by themselves? You've got to turn them into some sort of orientation. I mean, they give you all kinds of readings, some of which are very useful, some of which are not, and it depends on what you're doing. Well, sorry, yeah, what I mean was not that they're not useful, but they're in a form that normally you don't want to know what the, you know, the acceleration rate is. You want to know whether it's pointing up or down.
10:00 Or you do want to know the acceleration rate, but you don't want gravity. Correct. And, yeah, no, the I am user pain. And you want oiler angles. nobody actually wants quaternian values, but we all need them. It's like the worst form of broccoli. That solves the whole gimbal lock thing, doesn't it?
10:23 Right. But, you know, if you have a model, an AI model, it should be smart enough to just figure out gimbal. I'm sorry, no. I mean, there's some part of me wants to believe that you just throw some R&N or something that ends in NN neural network and you just give it the raw data. And it figures out, you know, temperatures and...
10:48 But you know as well as I do that all it's going to do if you train it right is come up with a common filter somewhere inside it. If you're lucky. Well, right, but... I mean, for the most part, your IMU probably reads either just noise or nothing. Right. And so it will just always tell you your gyros are zero because, you know, if you're not moving. So I guess what I'm trying to get to is
11:12 IAMUs could be their own whole book. Actually, I think I have a couple of whole books. Embedded systems could be a book. AI could be two math books and three software books. How are you making a book that has all of this? Is it how are you, what is your approach towards helping someone understand what's really happening, but not overloading them, but also not giving examples that are too pat, too simple.
11:48 Right. So my whole approach was that I only explain enough to be able to make an engineering decision. And so I think, you know, the difference between engineers and scientists is scientists have to be, their models have to be correct. whereas for engineers, we're happy for the model to be only correct under these very specific conditions as long as it's useful. So that was the approach I took was that, as you say, there's plenty of books about general AI theory,
12:21 and I didn't want to reproduce that. There's plenty of good books about embedded systems such as your own. So what I wanted to do was to provide a practical approach to someone who is looking to get into the field, what are the pathways and the key underlying things that you need to know about in order to be able to design these systems and produce ones that work? And the reason I went for a project-based approach is that with theory,
12:50 it's very easy to just say, you know, you do blah, blah, blah, and it all works. But if you've got actual... You know, exactly right. But if you've got hardware, it's actually, you can't. just hand-waver it. You've got to know how to build the model. You've got to know how to deploy it. You know, you need to know how to quantify it. So by doing projects, I believe that it's a much more, and for me, it's a better way of learning. That's how I learn best. It's good to sense, I mean, there are all of these theory books, but having a project about
13:26 this book means you actually put this in practice. It creates a synthesis of theories, different theories, into an actual thing you can accomplish. But one of the difficulties with many of the machine learning methods is that they work 90, maybe even 99% of the time. But that 1% means I never enjoy putting them in actual products because they make me so frustrated when they don't work. How did you balance the, it's got to work all the time versus it's got to be an actual book length book and not 12 million pages? Yeah, so I know exactly where you're coming from. I still don't use Siri to this day because it's so annoying.
14:18 So I think a good example of this is the Hot Word project. And one of the things I was careful to do is not to just produce the right result at the end and say, this is what I did and it worked first time, because that's not how it really works. So I was very careful to demonstrate as I went along and to document the mistakes that I made because I think that's part of the learning process. And so for the Hot Word project,
14:48 the first time I trained that model, it was 96% accurate on the wake work, which sounds fantastic, but it was also false alarming 55% on everything else. So you've got to be very careful what you optimise for. And so I think, you know, in terms of, I think sometimes I would argue that the force activation is sometimes the lesser evil, because you can maybe filter that out further down the system,
15:27 whereas if you get a false rejection, then the device is ignoring you, and you're wondering what the hell's happening. So I think, you know, you've got to make sure that you're optimizing for the right variable. And I think a lot of projects don't do that. And the difference between a hobbyist project and something that you use in production is how it handles the edge cases, I think. And that's normally stuff that you need to engineer around the outside to compensate for the model.
16:00 Okay, I can see that. That's not how I would have put it, but I can see it. How would you have put it? When you're doing something for a project, an amateur project, a personal hobby project, when you get it to work, you're done. It's great. When you're doing something for production or a professional project. when you get it to never fail, you're done.
16:28 So never fails a high bar. That never fails to, is too high. I agree. But when you get it so that it doesn't fail, except in very extreme cases, 96% would not be good enough for me, because that means one out of every 20, 30 times, it doesn't work.
16:50 And 55% wake up would be, I mean, I would feel like it's listening to me all the time. That would be terrible. But that lack of reliability just is so irritating. It makes me not use the thing at all. It's wake words because they are the prerequisite to everything that comes after them. If they get missed, they cause a cascade failure. I mean, what I'm arguing is I hate AI, so let's just go with it.
17:26 Why? Fair enough. Why dance around it? I'm just so sick of it. It's not just Christopher being grumpy anymore. You've jumped on board, have you? I'm the opposite. I love it.
17:41 I think it's absolutely fantastic. I think it's great for many things. but I do get tired of the, it almost works, but I can never get the last few bits. I can never, I spend all, it's not even that I spend, you know, 90% of my time on the last 5%. It's that I spend 99% of my time on the last 5%. And I can't, I'm not sure it's possible to get the last bits, the last. The other thing that makes it interesting is it fails in weird ways. Like, one of the things I wanted to do was to create a business card side printed circuit board,
18:25 which I could use to market the book. And if you've seen these, it's got an NFC tag on it. So you could tap on the card and it brings up a URL which links to, you know, where you can download the book. And to make it a bit more fancy, I put a microprocessor on there as well, because these NFC tags can also harvest power from the field, and you can use that to do a short,
18:53 I do a short animation of LEDs, which look like a neural network. But you don't get a lot of power from that. No, you don't get much of it. So you've got to be quick, right? But the point is, I thought, all the printed circuit boards in the book, there's five custom printed circuit boards that I've got as part of the book.
19:16 And I all did those by hand. And I thought, I wonder if AI's got to the stage where it could do schematics and printed circuit board layouts. So I decided to give it a test on this project. And it did the schematic. And the rookie mistake there is always it selects parts, which are not available when you go to manufacture it. So I sent it back and it fixed that up. And you look at the schematic and it looks weird. it's not the way that a person would do it,
19:43 but it looked accurate. So I said, okay, well, do the next bit, go onto the printer circuit board layout, and it did that. And again, you know how it does that? It sort of does lots of little lines rather than just doing one smooth line. But nevertheless, it passed the design rule checks for the tool,
20:03 and I set it off for manufacturing, came back, and it sort of worked. You could, you could, The story of E. 95%. Sort of worked. So what didn't work was the animation of the leads. And then I'm trying to work out what the problem was.
20:24 And I asked Claude, can you recheck your design and make sure that you've done this correctly? And it comes back and says, oh, sorry, I put the LEDs in backwards. How the hell did I miss that? Because it's a very obvious mistake on the same. schematic. And I go back and have a look at the schematic and it's got them around the right way. And I say, how is this possible? Because in this tool, the manufacturer provides the schematic
20:51 and the footprint. So there shouldn't be any way to mess it up. And it says, oh, I created my own version of the symbol and got it wrong. So I think that's what you've got to watch out for is it can make weird mistakes. You turn it up to their top model and it creates a new semiconductor for you. Right. Okay. So that's using, how much AI did you use to make the book? Yeah, so I used it in two key ways, actually.
21:24 I didn't use it to write or do the code. It wasn't good enough back when I was writing the book. And I found it wasn't very good at embedded code. I don't know if you found that as well. It's getting better. Is it? Yeah. The first time I tried it, it was terrible.
21:41 It created code that wouldn't work. But where I did use it was in two areas. So I wrote the manuscript in Word, and then as part of the publishing process, they imported into Indesign to do the layout for the print. And that conversion is not 100%. They mangled the text and images and things. And so I got AI to do a diff between my Word doc
22:10 and the printed PDF. And so it was very good at pointing out where there had been changes between the two. So that was very handy. And the other area I found it useful was in generating the index. How did you do the index for your book, Alicia? Paid someone.
22:32 Right. Yeah, so that's one option. But I can't afford to be giving away my hard-earned royalties. So I thought this might be something that I can automate. And I ended up using a three-tiered sort of process to automate it. And the first one used AI to go through and summarize what were the key terms within the books. Because you can't just list words in the book, can you, for your index? You've got to try and find, you know, of the 600 occasions where I've used the word accelerometer,
23:07 which are the ones that a reader would actually want to find. So there's a bit of intelligence around selecting which one of those to use. So I used AI to go through and create a master list of terms for the book. And then I used a Python script actually to go in and add the – there's some hidden word tags that they use for the indexing. So I used a deterministic Python script to do that. And then the last process was I went through manually and fixed it all up. Makes sense.
23:45 So going back to my question about failures, how do I figure out where, when to avoid spinning for a long time on something that almost works, but is never actually going to get there? How do I realize when my edge AI needs to be replaced with either a bigger processor, a curistic, deterministic algorithm? How do I draw the lines for this should be AI and this shouldn't? But let's start with when this shouldn't be AI. So my position on this would be if you can avoid using, using AI, you do. What's the name of your book again?
24:36 I just want to write this down. Can we take that out? No, I think that's actually a good heuristic. I mean, at a minimum, you shouldn't be reinventing things that work with some, less, what's the word I want to use here? Less transparent. Like, if I write an algorithm, I can look at it. if I write a model to do something that a simple algorithm could do,
25:04 let's say you're replacing a PID loop with a deep neural network. Okay, I understand how a PID loop works. I understand how to tune it. I can look at it and figure out what's wrong. There's lots of research on how to do things. Even if the model works, if I want to change how something works, maybe there's no way to do that. Or maybe you can't look at the model and say,
25:24 oh, well, this is how this is doing this control system. So transparency should be on the side of, don't use AI for sure. Exactly. So I say if it's, it isn't, AI isn't better, but it solves a different class of problem. So if you can use a algorithm, which is deterministic, it's, you know, test for, runs in not much memory at all, then you definitely should do that. And to be fair, half my book uses classical methods, you know, you were saying before about that. So, I'm 100% on board with that. So where ML comes in handy is,
26:00 for the problems that classical methods find difficult. And you're talking before about the Calman filter. And what tends to happen with those is you tweak those to solve a particular class of problems. And where it runs into issues is if some new thing comes up that you haven't trained for, and then the bottle is no good at optimizing for that. So that's where I think that,
26:29 machine learning can add some value. It can be better at generalizing than a carefully tuned algorithm is. So do you have any projects or examples where neural networks really help maybe because the environment's changing or something, projects where the AI is worth it, where the AI is worth the cost of complexity and transparency and processing? power. Yeah, so I think one good example is the comparison between the lookup table on the battery, working out how a battery state of charge changes over time, and comparing that to a machine learning model. And what happened with the lookup table is that it's very good for a very specific sense of circumstances on one particular battery.
27:34 But what happens is there's no state of charge pin on a battery. And over time, what happens is as the voltage changes and the load on the battery changes and the age of the battery as it gets older, all these things have an effect on the state of charge. So the machine learning model was much better at being. able to understand what was happening with that battery over time compared to the lookup table. It's funny. I actually thought about that one a while and found that to be a difficult case because in order to write the neural network,
28:25 in order to write the AI piece you recommend it, the book suggested I understand how the charge works. Let's see. To build the lookup table, you need to understand the relationship between the battery battery voltage and remaining capacity for your specific cell chemistry. Oh, that's to build the lookup table.
28:46 You're saying I don't need to understand that relationship in order to build the machine learning version. I think you still need to understand it. See, that's what I didn't want. I didn't want to understand it. Because even with the machine learning version, what ends up being the best way to train it was a hybrid model which understands that
29:15 that's different phases of charging in a battery, right? And then current does different stuff at different phases of when you're charging and discharging. And I used a MOSFET to be able to programmatically discharge the battery over time. But the problem with that is it actually bypassed the Texas Instruments fuel gauge I was using. So the model may not have known that that was,
29:46 it wouldn't have been able to see that. So I had to build that into sort of an expert knowledge of the system. So I think whether you're using neural networks or you're using a lookup table, you still need to understand what's happening in the underlying system. I thought that's a good message. Because one of the things I don't like about AI, or, well, using the term AI is fraught. Rampant use of machine learning. Rampant use of whatever, chatbots and things, is this urge to just have a
30:22 do things without understanding the output. And that's, yes, being able to make the decision between using machine learning on a device and not using machine learning on advice means understanding your problem in the first place and, you know, which approach is actually going to be beneficial. Because there's plenty of problems, as you said, that are better with ML. It's hard to make a bird detector with heuristic methods on, you know, on a camera. Right. And, you know, I think they went, you know, before the sort of the AI winter, there was that period where people were trying to go down the expert system route.
30:59 And the problem is you get that scaling issue, don't you? Where you can't account for every possibility and it doesn't scale very well. You can't put down every rule for every possible way to address the problem. Yeah. Okay. So say I have found something I think AI will help. How do we decide what intelligence will run on what kind of chips? For example, say I have an LLM. Will it work on an AT Tiny or an R-Pi? A Raspberry Pi. Sure. If you're only like five words. I know. That's such a terrible question. But really the question is, how do we figure out what chip to use for what algorithms? Yeah, it's a very good question.
31:50 And for those following at home, if you could turn to Chapter 11 in my book, Table 11.1, no, look, you can't squeeze much of a large language model onto a mic controller. Oh, you can't. So don't do that. An AT tiny, you know, it's got a few kilobytes of static RAMs. So you might be able to run a decision tree or a, a tiny classifier, but you're not going to be running a neural network on there.
32:20 An M4, an M7, you might be able to do some keyword spotting and some small vision model stuff. Raspberry Pi, you could probably run a small language model at a few tokens per second. So, you know, you'd only do that if you had an application that that was useful to do so. And I had to answer this question in my book, right? I wanted to train a GARN that generates melodies.
32:53 And I had to pick which board I wanted to run that on. And so that's what, that was my sort of thinking was the way to make the decision on this was, first of all, does it support the frameworks that I want to use? Because you don't want to choose a chip and then have to port the framework to a framework to, an unsupported chip. I think that's how you can tell if you're an engineer where you spend more time on the tooling than you do on the project. So that was the first decision that I used. Wait, wait, the tooling here is like edge impulse or tensor flow light?
33:33 So this particular one, this was the GAN, this was TensorFlow light. Okay, but for an example, you. You said framework. I just want to make sure we understand what the word framework means here. Yeah, that's what I'm referring to. Okay. Cool. Yeah.
33:51 And then the next thing was that the memory. So this is a hard constraint that you can't get past. And so it's all very well creating a fantastic model. But if you can't fit it on the memory of your microcontroller, then that's no good. So, you know, the quantized generator that this project created was about a megabyte. So that meant that I had to use something like a picco or a picco two. So that's the next one. And then the third thing that I used to make a selection is the amount of effort that you have to go to versus how much control you need.
34:34 So if you're using an existing framework like TensorFlow light or Edge Impulse, that makes things easier to implement, but you don't have a lot of, you've got to use what they provide as part of that framework. Whereas if you write the C code yourself, you can obviously do anything you want, but you have to do it all. Per amount of effort. Effort versus control. That is a good balance. Yeah. Yeah. And looking at your chapter 11, table 111, it was exactly what I was asking for. There are Arduino type processors, including the NRF processors that are on Arduino boards. And it talks about the type of the processor, whether it's an M0 or an M4F or M7, blah, blah, blah, dual core.
35:29 And the amount of RAM and which ones support TensorFlow, light versus Edge Impulse versus Micropython. You have a column in here for C and C++, and every single one of them is checked. I'm glad to see that. I'd be kind of sad if it wasn't. I don't see the AT Tiny in here, but that's okay. Okay. I do like the ATT. I use that on my business card that didn't work.
35:52 Well, I mean, that would be low, low power, fast boot. Yeah, it's got everything you needed there. Exactly. And then your methodology of, okay, you choose how you're going to implement this and how you're going to implement it, whether it's using a framework like TensorFlow, or micropython even can be a framework. If your processor doesn't support that,
36:18 maybe you're not using the right processor. And then the second point of memory, yes. I think that's something we're all going to have to get used to is that the size of our models drives so much. And so you can do a lot of your testing offline because if you can't get a model to fit into your microprocessor's memory, gigs up. We're not doing this. And the good news is memory is so cheap now.
36:47 I don't think that's, no, no. Oh, I didn't see the sarcasm light. Oh, you should have rolled up your sleeve so I could see that. It's always on. It's always on. How do you feel about micropython? Oh, it's cool. It is, it is in many ways truly wonderful.
37:07 And then every once in a while I realized, oh, I could use a much smaller processor. Right, yeah. But. I feel it sort of fits in no man's land, doesn't it? So I used it recently in a project that involved scientists being able to repurpose my device to their own requirements, monitoring environmental conditions. and they would be able to write scripts that would go on top of the hardware I provided. And it was wonderful.
37:45 I mean, at first we had some of the scientists writing in C. I quickly realized how badly that was going to go. And yet, once we got the Python working and all they had to do was type a few lines, it got much simpler. It seems to be really good for devices or products where you want the end user, without changing the firmware to change something about how the board operates or script the board. And that's really, a few things I've seen it. I've seen an ear device, the jumper list that I've been playing around with we had the show about, has a Raspberry Pi 20, whatever, the Pico has its controller, and you can control,
38:26 you can go in and, you know, query voltages and things of all the test points and things, you know, and do some stuff programmatically. And I've seen it in music devices as well where maybe you have a synthesizer module with Micropython and people can go in and do custom stuff. So it's not, I don't think it's a, I don't think it's a great fit for here's the end product and this is the firmware.
38:49 But it's good for people who are going to muck with it anyway and you want to give them a good way to muck with it. Right, or if you don't want to write, if you have something complicated that needs a lot of interaction, but you don't want to write a giant CLI yourself. Yeah. It's a good CLA, yes. It's a really good CLA.
39:09 To some extent, I wish we had started another project with that as the base, even though it was way more complicated than it needed to be. Because we ended up with the CLI that's really complicated. But what if it was Python? That would be so much easier. Yeah, it's done. Okay, let's see. I have so many questions.
39:32 I don't even know where to go from here. Oh, do you talk about machine learning cores or the new controllers that have the AI-ML? Neural processing bits, yeah. What are essentially tiny GPUs stuck on them, like little horns on top of horses? What? Yeah, the white... The unicorn. Oh, okay.
39:56 Yeah. Sorry. The wake word model uses the Arduino Nicola voice, which has got a sentient chip on it, which is good. The problem is, I don't know if you find this, but a lot of the example code that you get is very fragile and brittle. And so I had to do a lot of work to get to get it to work as advertised. But yeah, I think that that's a great model going forward. I also did some work. I think you were talking about your dodgy robot arm in one of the episodes. And one of the projects. arm. I do, yeah. It's also dodgy. But what it does is it's got a, it uses the ST I-MU, which allows you to do anomaly detection on the arm. And so I thought that that was very useful.
41:14 Let's see. Your book is very project-based. Which came first to the projects or the learning objectives? Definitely the objectives. So I started with what I wanted to cover within the book, and then I looked for projects that would help me explain the best way to approach those sort of problems. And then when you consider those sorts of problems, you had to, because your book covers so much material, you have to go from describing what is linear interpolation, and Y equals MX plus B and how that works,
41:53 to stochastic dissent and statistical methods and expectations. How do you... This is the problem. We'll call these kinds of books. It is. I mean, it's just a lot. How did you decide what your reader already knew versus what they should look up versus what you should teach them?
42:18 Honestly, the way I selected what should be in the book was the stuff that I was interested in. So, you know, is that the best curriculum possible? I don't know. I don't know. This was the journey that I myself went on when I was learning about this. And it was the book that I wanted to have available and I wish was available because what I find is that I enjoy going deep. on different subjects and I felt that a lot of other books covered things superficially so what I tried to do was go just deep enough to allow you to
43:07 make an engineering decision of whether you should use A or B but no further than that and this book was way bigger than I initially imagined, and that's even after chopping out like six chapters. So, yeah, I could have kept going for sure. I mean, yes, because there were so many other things you can do. I mean, let's see, I'm in Chapter 11, building an AI MIDI synthesizer and everything from the adversarial networks to building a piano keyboard, to a synthesizer to USB MIDI procedural composition to the MIDI controller.
43:54 It just, and that's one small section of your book. It's really quite a lot. It's a lot. Yeah, like I, but these are, I guess the problem is for me, I get interested in diverse subjects. And like I suddenly, I was. wondering, how do capacitive keyboards work? And so I went off down that. Boy, that is a rabbit hole. And it's, I think every time I end up there, even having programmed for them, developed with them,
44:31 worked with them in the year 2000, I still think maybe the answer is just magic. And look, the software that you can do now on things like the PICO is, amazing. Like the PIO and the DMA staff, it's just, it is magical the way that you can offload all this sort of processing off to little other bits of the controller. You mentioned writing a drone book and then being too late to the industry. Were you worried about that for this book? Because AI and microprocessors change pretty quickly. Yes, yes, yes, it was. So I wasn't so worried about missing AI, if you like, because I think this is, you know.
45:29 It's never going to go away. No, I think this is a, it's a major pivot point, I think, in human civilization. So I think, you know, there have been five or six of these major pivot points and AI as one. So I wasn't concerned about missing that. I was concerned about, as you say, micro-processes change, and that was part of the reason that I selected the processes that I did, so that those hobbyist-type controls, the Arduino stuff, have been around forever, and they tend to change at a slower pace
46:02 than if you were using, you know, development boards, which change every six months or so. But having said, even with that, you know, Qualcomm took over Arduino and Edge Impulse in the time that I was writing the book, which is probably arguably not a good thing. So the way I tried to address it was to stick to principles as much as I could. So there's a lot of stuff in there, which is quite old, as you say, the Kalman filter and the Mahoney filter and all the Sensifusion stuff.
46:36 That's not new knowledge. But what I found was it's hard to find books that explain that stuff in detail, which is why I included it. And the other thing that I've done is that as stuff changes, I've been releasing sort of bonus content that addresses anything specifically. So one example is for the battery monitoring project, I had two shields, one's a logging, and display shield, and the other one does the actual charging and discharging the batteries. And the sensors on there
47:20 or the chips on there use I-2C as the bus. And they worked fine, the two shields by themselves, but when I put them together, I was occasionally getting issues with them. And you can probably guess where the problem was. Pull-ups.
47:41 Yeah. Exactly. So I had to create a new version of the board, so that's come out as a sort of bonus content. Do you have any advice for people thinking about writing a technical book? I think you need to have a good reason to be writing a technical book, and it definitely shouldn't be making money. So I do think it's a great way to learn about a subject. If you want, I'm convinced that if you want to learn a subject, try and teach it to somebody else. True.
48:23 So true. So I think from that perspective, it's great. And Alicia, I think you were talking about an example of where you were down at Apple or something and they brought your book out. So I think. That's the other area where it's useful. The credibility check. Correct, yeah.
48:41 Reputationalally, being able to say that you've written a book and have got the grit to be able to go through that very painful process. But I think you want to be very certain that you're willing to put in the time and to go through it because it's harder than it looks. I found it harder than I expected. Yes. It is definitely harder than it looks. And having a quality editor and a quality publisher is really important.
49:16 Writing a book on its own is usually not sufficient. Did you have a lot of interaction with no starch? I know they're reasonably hands-on. Yeah, that was great. And that's part of the reason the book I had to rewrite it five times was originally the way I wrote it was more like a series of sort of lab notes of, I did this, then I did this. And my developmental editor said, I think it would be better. Sierra Fong was their name.
49:46 It would be better if we did it as a series of projects that people could build along themselves. And I think she was 100% correct. But it did mean I had to go back and rewrite it all. But it made for a much clearer process. And the other thing was, as you say, I cover a lot of ground in the book, and she was very good at being able to help me package that up into sort of understandable subsections. Which given the breadth of topics you are covering, you really needed the subsections.
50:26 They were very important to being able to say, okay, I want to know about this area. and I'm going to skip the other parts. Do you have a favorite project from the book? I think my favorite would be, I think it's probably the MIDI controller, actually, with the GAN music generator. Just because it, I love the fact that it was using two cores of the Pico and that one of them's running the spectrograph and the other one's running the R&N.
51:10 And just learning how the PDM microphone goes in there. And that was the one I got a lot of joy out of. No Starch has asked me to provide a quote for your book. What should I say? You know, the best quote in your book, I think, is the one where you say that every sensor is a temperature sensor. that strongly resonated with me. Some just measure other things as well. I don't think that's going to be it,
51:45 but I have enjoyed your book quite a bit, and I do appreciate that all of this information went into one place. I mean, I have notes about maybe 30, 40% of it, but I don't have a place I can point other people. And so I am looking forward to saying, you know, you want to try that? Go ahead. Here's a good reference. Oh, you're using IMU for the first time.
52:12 Wow, do we have an adventure in store for you. What do you think is missing from the book? What would you have put in there? I think what I would want was the impossible things that I started the show with, which is I don't trust AI. It's not reliable. It's too complex. It's not transparent.
52:32 it's impossible to debug it's impossible to test in all the cases that it needs to be tested in and so what I would want in your book is here's how to QA AI system but also you know here's how to
52:52 figure out if you can QA it before you put all the effort in and I mean that's just a problem with AI in general that's that's not your book. Although if you say you have that and I just haven't gotten to it, I'm going to be so embarrassed. No, no, I think that's going to be the next book. Because I agree with you. I think that the problem a lot of people are making at the moment is that they're trying to build safety into
53:19 large language models. And because it's not deterministic and it's, you know, it's all statistics at the end of the day, it just can't be done, can it? So, I would argue that we need to go to a different sort of model where the safety is built in lower down, the same way that the evolution has worked it out. We have reflexes that don't go to the neocortex until after it. They've already fired. So I think that's the sort of model that we need to move to in terms of robotics and self-driving cars and things like that. It's funny about it, Micropython. to some extent one of the reasons I really liked it was because I could build in all of those safety in the sea
54:06 so they couldn't get to anything that was going to blow up my robot and that was super helpful and your your neocortex versus I guess amygdala or cortex or I don't know however many brain parts you want it does make sense to separate it and to hear the safety critical pieces. And if you hear the screech of the cat's claws on a rock, which sounds a lot like the screech of a blackboard, yes, your brain is going to go, wow, we need to do things. Even without AI, there's plenty of embedded systems I've worked on where we put the safety systems in hardware.
54:47 Oh, the laser's firing. Well, there's a hardware integrator that measures how much. energy's put in, and if it goes too much, it shuts it off instead of the software, you know, oh, I'm looping around sampling, it seems all right. Oops, I got distracted and, you know, the laser was on too long. I love that firmware engineers are the people who least trust the firmware. Trust them. They know what happens. Well, you had recently, the guy who was building the robot dogs. Yes. And he was, yeah, so he was talking about how originally he was sort of hard coding in the gates, and now he's trying to use neural networks. And I was thinking, what he needs is a cerebellum,
55:27 which is how the brain does it at the moment. So when you walk or you jog or you skip, or even chew, that's all done by the cerebellum. So you know, when you drive home sometimes and you can't remember how you got there, that's because the cerebellum's taken over. So I think, I think that's the model that we need to go. You need to have this co-processer where you know, the brain says walk and then this other bit handles how it actually does the walking. I think David's next book is going to be neurobiology and how it should be applied to software. 100%. In a second, I'm going to ask you if you have any thoughts you'd like to leave us with.
56:08 But first, we have a giveaway. No Starch is providing two print copies of Embedded AI for listeners in U.S. or Canada. I guess we... Which is ironic. Why? Because he's in Australia. Okay, that is kind of ironic. I didn't get it.
56:29 Am I the first Australian to be in the show? No. No. Sorry. We've had several. Let's see. How shall we select winners? I think send me a project you're going to do with AI.
56:45 Just an ID. ML. ML. Don't send us a project you're going to tell Cloud to do. No, we want to, I want to use a microprocessor to build myself a synthesizer that reacts to my cat meow. That sort of thing. And if you feel free to make it as silly and ridiculous as you want, because really they all just get put into an Excel sheet and then I shuffle and choose a number. So mostly you're amusing me with your emails.
57:12 Show at Embedded.fm. And that will be until the end of October. So you have a couple weeks to do it, but do it soon. No Starch has also created a 25% off coupon for Embedded AI. It's Embedded 25. Wow, that's not going to be hard to remember. Embedded 25 at Nostarch.com. That's valid until November 5th.
57:40 So use it soon. Now, David, do you have any thoughts who'd like to leave us with? I do have one, and it's a bit of a cliche, I'm afraid, But I do think you've got to keep learning. I think, you know, I've had more than one career and people coming through now will have three or four. And things are changing and they're changing. The pace of change is accelerating.
58:04 And the half-life of anything that you learn is getting much shorter. So they used to say that half of what you learned at uni would be useless in five to ten years. And I think that's only got much faster. So I think, you know, if there's one thing, that you want to learn, it's how to learn. Indeed. Our guest has been David Such,
58:27 executive director of Reefwing Software and author of Embedded AI, Intelligence at the Deep Edge, published by No Starch. You can find it wherever you get your technical books from. And you can use that coupon if you're using it at Nostarch.com. Thanks, David.
58:45 This was fun. Thanks for having me. Really appreciate it. Thank you to Christopher. for producing and co-hosting. Thank you to Mark Omo and Scott in our Patreon listener Slack group for some of their questions. And of course, thank you for listening. You can always contact us at show at embedded.fm or hit the contact link on Embedded FM, which is how you're going to be entering that contest, email, or hitting the contact link. Now a quote to leave you with. This was in
59:13 David's book, but it didn't originate with him. It actually originated with George Box, who is a statistician. All models are wrong, but some are useful.
There aren't comments yet for this episode. Click any sentence in the transcript to leave one.