In this chapter of the Zero2Maker Workshop, we'll be looking into system integration, what it is, the issues that can arise from it, and how you can avoid them. If you're new to this workshop, we'll be taking you on a fast-paced and practical journey to learn a wide variety of maker skills, so that you have the tools and knowledge to make anything. So follow along as we develop our own projects and share insights into the process. To kick us off, what is system integration? And why do I hear the term, integration hell all the time? System integration is one of the final steps in a project, it's where you bring all your systems together. Everything that you had worked on separately comes together, but they don't always like working together, and this is where some of the worst project issues can arise. This is the reason why it's often called integration hell, because everything that was previously working starts breaking.

For example, you've got your sensors outputting data and your motors spinning, but when you start working on the code to combine them, you realize the sensor's output is in meters per second, and the motors are in RPM. And that's just a single, simple example. There will be far more complex issues, and you may have to deal with many of them at once. And on top of all of that, no matter how well you plan, no matter how rigorously you check your individual parts, there will be problems with them that you won't find out about until you integrate them. Jared and I have faced many system integration issues over the years, and definitely some in our Fab Academy projects. So let's jump into some of those issues we've faced and give you some of the valuable information and strategies for dealing with them. Let's start with something called incremental integration. It's a simple one, but it's a vitally important preventative measure.

The process is simple. You get a module or a part of your project working in isolation, and then you integrate it, and then you get another module working, and then you integrate it, and so on. And the important thing is that you want to take small steps here by kind of drip feeding parts into your project and integrating them bit by bit. It's easy to deal with any issues that arise. In my project Leo, which is an omnidirectional indoor robotics platform, I had the end goal of controlling the robot with my keyboard, and I got there with incremental integration. I started by just getting one wheel to move by itself. Cool. Then I got the encoder working in isolation to measure the speed of the wheel when I manually rotated it. Then I got the wheel to move and the encoder reading at the same time. Baby steps here. Then I wrote some code to measure the speed of the wheel and control the speed of it to reach a target RPM. And here I realized that when I drove my wheel forward, the encoder would actually read it going in reverse. Problem number one fixed.

After fixing that, I manually changed the target RPM, and it worked well when I wanted the wheel to move really fast, but not when I wanted the wheel to move slowly, so I needed to go ahead and fix how my code handled this. Then I got another wheel working, everything was fine, added another wheel, fine again, and the fourth motor didn't work because I realized I had accidentally swapped two of the wires the last time I had rebuilt this thing. Easy fix though. So my wheels were working fine going forward, but when I tried to make them go in reverse, I realized I had another issue, and incorrectly defined some pins at the top of my code. Easy fix. And this was all going to be controlled by a Raspberry Pi 4 computer, so I got it sending commands to the wheels and tested out all the directions, forwards, backwards, reverse, rotate, and discovered a whole heap of issues there. And even I discovered an issue with one of my mecanum wheels being backwards. And then I finally added the keyboard control to the Pi 4, and it was done with a few more issues on top.

Now, each of these problems I encountered individually were easy and quick fixes, but can you imagine how much of a nightmare it would have been to tackle all of them at once? By adding things to your project in small steps with incremental integration, you avoid so much hassle. In fact, if I tried to do this all at once, chances are the only way to fix the problems that arise, I would need to go back to the start and do this whole incremental process. Another important thing to know is that system integration often takes a long time. Individual parts are quick and easy, but when you start combining them into one solution, they start taking longer and longer. In my project Plant Pulse, an agricultural plant monitoring and watering system, some of my small objectives didn't take long at all. Getting the soil moisture sensors to output data, soldering up a PCB, getting communications working with ESP-NOW. All of that took about half an hour each, but when combining them, it ended up taking about 6 hours.

ESP-NOW needed data from the soil sensors formatted in a different and specific way, my PCB didn't show what pins the soil sensor used, and that's just a couple of the integration issues I faced. And this time gets eaten up in things like writing code to translate from one format to another, making the user experience nice, and these are just all things that come together at the end in system integration. And it gets even worse with a deadline, we had to push really hard before our project due date to get the prototypes ready, and features often have to be removed altogether. Deadlines are often the limiting factor for system integration, and that's the real trap. What this is going to make is underestimate the time it takes to integrate all of their parts in their project. A really valuable lesson that I've learnt and been hesitant against is that the time you spend double and triple checking everything is time well spent.

Another simple one, but I can't stress it enough, I have been historically really bad on this one, and this is the first project I think I did a pretty good job with. Every single time I connected wires, I triple checked the diagram that I was using to see if the wires were in the correct position and orientation. Every time I plugged in a motor controller, triple check it was correctly receiving power. Every time I soldered a board, I triple checked that all the connections were working. All of these checks do add up time wise, a few minutes here and there add up to hours on a project. But by checking that every set of wires were correct, I didn't have to spend the time finding out why my encoder was reading backwards, well that actually did happen, but it's a great example because when I rebuilt it, I didn't double check the wires as thoroughly. By checking that the motor controller was correctly receiving power, I didn't accidentally swap the polarity and blow it up and have to wait 3 days to get a new one.

And by checking every solder joint I made, I found issues with them before I buried it deep within the robot and would have to spend an hour disassembling and reassembling everything just to fix it. The lesson is simple, you can't be overly cautious and over checking can save you time and many headaches in the long run. One of the worst things in integration are intermittent faults, which are some of the hardest to find and solve. I share any pain you have if you encounter one in your maker journey. What happens when the project you've spent the last 10 hours on stops working all of a sudden? The data between two of my boards stopped sending data all of a sudden. But why? Everything was working before. Luckily, I had written code to test each individual part of my project. I ran them all and everything seemed to be working. Put them back together and now it works. Then it broke again. Okay, we have an intermittent issue.

But how did I figure out where it was breaking? And just by testing it even more. Lots and lots of testing. I ran the individual tests 20 or so times for everything and it turns out it was an issue with one of the board's wireless communications. I tried to solve this issue but it was still intermittently failing. But when I swapped it out for another board I had on hand it worked straight away. Every time. So I chalked it up to faulty hardware and moved on. This was one of the most difficult issues to fix in my integration because it was intermittent. But lots of testing will usually find it. A short and simple one. System integration will present you with problems that can require a great deal more work to solve it. Sometimes this work is really difficult and sometimes it's almost impossible and you need to know where to throw in the towel. So my robot has four mechanism wheels. And there was an equation you use based on how far apart they are to determine how much they should rotate. And that was good.

But something I didn't think about till system integration is that these distances changed. As the arms of my robot moved up and down the wheel distances changed and the equations that it needs to use change as well. If I brought the wheels in and told the robot to rotate 180-degrees it would move forward slightly and not rotate all the way and do these weird little drifts around. And there are a few ways to fix this. I could calculate the distance based on the angle of the servo being set or I could put on an accelerometer and compass on there and detect the rotation of it and implement a control system to negate this error. But with deadlines and time crunches I threw in the towel and said that those movement errors were good enough. We would just have to roll with it. And there are times that you might need to make these decisions in system integration. Another important thing is that a lot of beginner makers before you have a great deal of experience you may reach a problem that you can't solve in system integration.

Both of those potential fixes require a great deal of math and almost even bordering on university engineering level skills. This is what we kind of meant by it. You might hit problems that are impossible to fix and in this case if I didn't know how to implement all that math I would either have to roll with it or redesign, re-evaluate and figure out a workaround. A lot of system integration issues are invisible in that they are code or logic related. Being able to visualize what is going on is an amazing help and there are lots of ways we can do this. The simplest is with print statements. When my system was integrated I had print statements everywhere so that I could see visually that everything was working and the data was flowing as it should. Print statements are your best friend when you can use them. But that's when you can use them. What happens when you can't? When your project needs to be outdoors or in a place you can't plug in a computer.

This is where we need to get more creative. Most microcontrollers come with an on-board LED and this is the simplest way to debug in the field. I used the on-board LED to track the progress of my code. One blink means that it's got the sensor readings, two indicates it's about to send a message and three means it's sent and it's about to turn off. All of the important stages in the code. These tests were sweet and by seeing where things were not working it helped me debug what was wrong. It turns out the file wasn't uploaded on the ESP32. What a boring issue. But you'd be surprised to see how often this happens, especially when you're four coffees deep on a Friday night. And even better than the LED, another option is to use an OLED screen for more detailed information. You could print sensor values or anything you can put in a print statement and it's a great tool for debugging in the field.

Well that was a trip through hell. Integration hell. We hope you, the audience, had some fun and learned something at the expense of our pain. And if you have any other tips and tricks, drop them below in the comments. And if you want to check out this whole maker course, we have a link to that below as well. Thanks for watching.