Good afternoon, Howard Wiig, Code Green, Think Tech, Hawaii. You know, when we were kids, we read about revolutionaries. It's his name, Lenin, Stalin, Mao, and so forth. Well, it brings me great pleasure to bring to the table a totally different type of revolutionary. Nathan Toothman, he's the co-founder of Elevate Structure, which we'll be talking about. But before that, he was a nuclear sub-officer. Be aware, he's also the owner of beer engineering. He is a licensed civil engineer, and he is here to almost literally turn homes on their head. And we have so much material to cover. Nathan, welcome to the show, and let's bring up the first slide, and let's get rolling, because we've got to roll fast here. Thanks, Howard. Thanks a lot for having me here. So I just wanted to kind of go over some updates on Elevate and introduce it. And you can go back to the previous slide there. You know, I've been on the show a couple of times and we've talked about different versions of it. But this entirely new version here is a different spin in that it has a lot more opportunities, a lot more flexibility in the structure. And so I just wanted to first kind of introduce that, and then over time, it kind of becomes clear. So if we can show the desk view here, if you can zoom down the other camera. There it is. Yeah, OK. Yeah, so this is a form of what Elevate has been inspired to turn into in the sense that this would be kind of a starting position for it. And it's a very wide, very large structure with very symmetric, simple members with a pivot point. So it's a very easy structure to assemble. And that's kind of what you see here is it just pivots advance amongst a certain point and comes up into its elevated position, hence the term Elevate structure. Now, this could be a group of homes or one home or a whole neighborhood. Or so the original concept was kind of a micro home concept, like an individual home, a small home, a raised home, elevated for a number of reasons, safety from items below, better views, better breezes, a large void in the middle for water storage. And so that was kind of the initial concept. But then as we realized, as we came up with this radial design for the support structure, when it's in its down position, now it creates a really efficient structure that can then be used for very low cost housing. And so each of these cells here is about 100 square feet. So you're looking at 1200 square feet around the radial area and 200 square feet in the center. And the center could be either manned or it could be a courtyard sort of area. But different covering options fabric architecture could be one prefab panels, others, floor, walls, ceiling. But it's a very efficient way to do a structure. It gets a lot of strength from the the radial balance of it. And again, it's very easy to assemble, very quick, can be set up in a couple hours by a couple of people. And it could be. This could be a whole bunch of people living in one person per structure. Yeah, it could be a range of one of the things we want and we like and the flexibilities that can adapt to whoever the customer is in the culture and how they want to use it. So each person could get one. You could even divide these up into two, so 250 square foot areas. And then but it creates this community sort of feel and that it's centered around this courtyard. Yeah. And so it kind of kind of inward looking structure to get some security there. But it's it's a different thing that we're kind of just evolved into, you know, innovation aspect is it just kind of things come up that you see and then it comes into other aspects. This is revolutionary. Yes. But then so it's but it's really it's transformable, really multifunction in that when you bring it up, this is still kind of one of the core aspects of elevate is, you know, the when it's up. And so what do we do with it? That's that's kind of a question. I mean, it started on a on a purpose. And it's, you know, as you come along through different iterations, different things come up and you see different things and you kind of explore that route and that area. And so now what we want to do with this is we want to make an impact and we want to make an impact in the areas of global housing because we think we have a good solution, both in the up position and in the down position and then also making an impact relative to climate change. So if you can go to the next few slides here and next slide, next slide. OK, so this is kind of where the inspiration point was here, was a point on the North Shore. And that's kind of what inspired the concept was a tree to blend in to be safer to fit the site. And so it kind of it went from that along a process of evolving and evolution to this. So then the next slide, please relative to there, you see the images going through and go to the next one. That's kind of the process we went through there. Next slide, radial balance. We kind of went through that. We'll we'll talk about that a little bit more. Keep going and keep going one more. And that's kind of the simple parts will come back to the couple of these. Keep going. OK, so here for the climate change impact is so is what we see that can happen with the structure is that because it's inspired by a tree and it can look like a tree, it can fit in in the same sense as the tree can. It can fit in places that no other structure can. So in a sense, we're sort of hacked nature to to bring a structure into places that other structures can't fit. You know, it's got a small. But you use the word hack and I keep seeing that more and more generally use among young people. What in this instance is hack? Well, like hacking, obviously, when you hack into like a computer system, you gain entry, you use like a tricky way to get into it, to figure a different way around that wasn't initially thought to gain an advantage from that. So it's kind of a term that we're borrowing relative to structures. In this case, it's a positive term. It's a positive term. Yeah, in a lot of terms, you know, it's used in a positive way when you hack something to make it better or find a new way to do something with it. And so this is using a nature theme to put something where other structures can't fit because it's got a really small impact area on the base here. So 50 square foot here, 200 square foot above. That's a four fold increase of space. And so people can still walk underneath of it. You get shade and that helps with walkable cities. The aesthetics of the outside are important, such that it blends in. And we'll talk about some of the different revisions of that. But it's using that concept. And so relative to impacts we see for it, you can go to the next slide. So as we see, this is a test bed for different technologies up in the upper area here. And so in this case here, we have CO2 scrubbing panels and we have smog removal walls. So it's using some existing technologies and testing different technologies in cities that have issues with pollution and other areas of obviously CO2 is to scrub that from the air in core areas of a city that wouldn't otherwise be achievable. Yeah, I've heard about the CO2 scrubbers and there was something green there, obviously called plants. They're the ultimate CO2 scrubber. Yeah, so we're kind of just enhancing that because the original concept, as you've seen the structure before, was lined with plants. And so that's a natural method for it. And that'll still be present on very many of the revisions of this. So we're looking at ways also to enhance that, to make it more than what you get from just one tree. So, yeah, obviously this would be multiple trees or it could be shrubbery hanging from the walls and so forth. Yeah, yeah, it could be a variety of looks and iterations of these 12 cells that can test out different aspects and different features of that, including different ways to capture, you know, make electricity. Solars on obvious fit for the roof. There can be solar leaves there. They're making leaves that like fake leaves that are solar powered. Many wind turbines. Yeah, the leaves are more efficient than real life for those synthetic trees. Yeah, yeah. So it's finding a lot of different ways to creatively use nature to our benefit in ways that haven't been thought of before. So what do we have on our next slide then? And so it's it's it has a very strong commercial aspect. Each slide is getting the concept is getting larger and larger. It's a very visual concept too. But so here you see the commercial aspect of it. So it's it's intended to really stand on its own merits, whether or not it has any ego aspects to it or not. But in this case, the concept here is that the small that the area in the bottom is used for a small business like a coffee kiosk, a tea business, a juice shop, a small retail. And then this volume up above can be used to store items and then tap into that and lower it down. So so that's that's one used to fit more for small businesses as they get driven out from cities and back into the city, but do it in an aesthetic way that that fits in. And then another really good use that we that's kind of come up through our research was using it for a place making structure. So a city sometimes wants to bring people together and activate a space to get people to watch the football game or the basketball game. I mean, that's what makes a city is bringing people together. Right. Right. Right. So it's an interest. Yeah, that's that's what this can do is essentially in the version you saw in that previous slide, if you bring that back up during during the day, it kind of hides itself as a tree at night time. The walls open or in this case, we have in the center area that's is wider. And so it's a projector or an LED screen. And then the community can come around and gather it, watch, watch the movie on it. Company can be selling popcorn out of the base or whatever. Or you could have vendors around that. Yeah, yeah, yeah. Vendors around it and just kind of activate a place, make it fun, make it enjoyable. And so there's as you have something that's really tall in a big open area, it makes it really viewable and really visible from a distance. And so you can project really important images on that. And you can show fun stuff. But you can also show things in relative to climate change. That's how it kind of ties back to that aspect is more awareness. So this is kind of like an iconic structure in an area, if it's doing improvements for the environment, that you can then learn about it as well. And so it kind of it gives importance to that. And it's a way cities or groups can just show that importance to it and then practically make a difference. So it's not going to solve all the problems, but it's a step towards them. Wow. We have time for one more slide before our break. But you're just bringing up so much stuff here. Well, I mean, you know, this is, we've been at this for a while, but we do have a defined plan to make this happen. So we built the first prototype. We'll get to one of those pictures at the end. That's over. Kailua built that about a year and a half ago. But now we're at a stage where this structure alone that you see here can fit in the back of a van. Okay. So we can, we can set it up for a few hours. We can set it up for a few days and we can show it off. We can test it. We can test it really rapidly. So we think we now have a really good, minimum viable product that we can take around and get a ton of feedback on what's what works, what doesn't work, where is it really fitting? So that's one of the first next steps. What would you do about the walls? I mean, this is, this is the frame. Yeah. Just the frame itself isn't too impressive. So just in a few hours with a little material, what would you do to cover the walls? The walls is just like a lift up panel that you just lift up and hang on a hook at the top. So the panels are pretty lightweight. And so it's something that's used design. The whole concept is that every piece is less than 50 pounds. So two people can carry every one of those pieces and hang them on there and then take them off. And so there'd be permanent, more longer term installations where it's more anchored down. It's more, you know, fixed for a longer term, but it runs a span from, you know, two date, two hours to two years, the time that it can be up, depending on location and the needs of that area. And then it would be accompanied by a lot of publicity in the beginning. Come and see this. Yeah, it's something that's obviously different. So it's not hard to draw people to it. When we first built the prototype, there was interest in what is that. So it would naturally gain some attention in social media, things like that. Well, on that cherry note, we need to take a very brief break, Howard Wigg, Think Tech Hawaii with Mason, Mason Tussman, revolutionary and visionary back in a minute. Hi, this is Jane Sugimura. I'm the co-host for Condo Insider. And we're on Think Tech Hawaii every Thursday at three o'clock. And we're here to talk about condominium living and issues that affect condominium residents and owners. And I hope you'll join us every week on Thursday. Aloha. Hi, I'm Stan Enigman.  Noon, thinktechhawaii.com, watch the show. Be there. I pity the fool who ain't. Hello, this is Martin de Spang. I wanna get you get excited about my new show, which is Humane Architecture for Hawaii and Beyond. We're gonna broadcast on Tuesdays, 5 p.m. here on Think Tech Hawaii. Hi, I'm Stacey Hayashi and you can catch me on Mondays at 11 on Think Tech Hawaii. Stacey to the rescue. See you then. Hi, I'm Chris Letham with Think Tech Hawaii and I'd like to ask you to come watch my show, The Economy and You, each Wednesday at 3 p.m. Good afternoon once more. I would like to call Green, thinktechhawaii. Have with me, Mason Tussman, nuclear engineer, licensed civil engineer and head of his own company, which is revolutionary and we're talking about whole new concepts.  You've got something permanent up in Kailua or you've, yeah, so why don't we get right into where we are now and then maybe we can jump back to some of the other slides there. Yeah, yeah. So this is the prototype we built in Kailua and so this is kind of the Rev 1.0 along the lines of a micro home and it's really, I mean, it's evolved as things do but it's really important that we did this to get to where we are now because it really helped refine the design, it helped get people interested in it, helped attract a team. Now, this is a real, this is not Photoshop, this is a real-life photo. No, no, that's a real structure. Yeah, that's the real structure. And so it's really important for our sense and for what we're trying to do to have done something and then really learn from it rapidly and take from it what we learned and go further with it. Yeah, you can use all the modeling under the world.  And then stuff happens. Right, you have to build something. So we studied it for a long time before we built it but there's no way to tell how where it's gonna, eventually end up and there's still not but we have something now that we can rapidly prototype. Like I said, we can fit this in the back of a van, transport it around and the area we'll be doing this is the Bay Area and get a lot of feedback both from the down structure, the up structure. So in this sense here, the next goal is two prototypes. One we transport around the second one it's kind of like a mini headquarters. So we kind of operate out of this down position. Like, what are these spaces feel like? How much space is it? What are different roof type structures that we could do for it? How to use that? So really personally use it as well. That's one of the best ways is to Nothing like hands on experience. Hands on personal experience. And it helps to not have to talk about these things so much. And when you have something that you can come to and visit it helps, it's better to show and tell obviously. I've worked with so many engineers on so many concepts and it looks so good.  Stuff happens here. So, and for you guys, your team to actually physically experience it. Absolutely nothing like that. Yeah, it's been really important. Like I said before, it helped really attract the team. So we have a great architect working with us and Dennis Olmsted, Martin Despingh has helped out in the time. My wife's been really central to this from the start. She's a civil engineer as well. We attracted a material scientist that's now working with us who also has a background in 3D printing. So that's been really valuable for us. An MBA guy from Stanford and also a software engineer. So we got kind of a techie team and that's what we're trying to do here, too, is we're really taking a fairly simple concept and a simple construction method. Like the prototype you saw was giant I-beams and standard framing. So now we're challenged by some individuals in Silicon Valley who've done a lot in the area of innovation to expand what's possible and add more technology to it, bring the cost down significantly. So we realized that early on, the cost was just, it needs to be really radically different in the cost standpoint. And that's what we think. One thing that comes to mind immediately when now that you're mentioning it is carbon fiber as a material. It's light, it's stronger than the heck. It'll take a licking and keep on ticking. Right, it's extremely great material. And so we've thought about areas relative to wraps, like just the bare minimum, what's the minimum wrap that you need to give as a support and then maybe use other materials. Because obviously carbon fiber is really expensive now and it probably will be for a while. So we're really looking and seeing what parts of it can really improve by adding innovative materials. Yeah, well, you know something about stress being a civil engineer. So what are the high stress points? Yeah, yeah. And that's where it'll help too to build this prototype when it's down and up is that you can really see, like, let's really focus on this area. Let's add a lot more to it in that area. 3D printing's another area. Like this whole structure was 3D printed, but 3D printers right now aren't really at this size. Like this is 45 feet across and these individual members are 14 feet. But what areas can we really add value? So one area might be the roof. So roofs are a really important part of the structure. And so it plays a lot of roles too. You know, it needs to have ventilation, it captures solar, it provides lighting. Oh, and then you mentioned water capture also, didn't you? Yeah, the other aspect is that water capture. And that's really what this... Yeah, here we have it on the slide here. Yeah, here's some of the technical things we want to push forward further is more 3D printing, looking at a roof first. 3D printing of foundations, no one's done that that we've found. So how do you possibly do that? Then also another big one is self-sufficient from a water and wastewater standpoint. And so one of the things I do as a civil engineer is design wastewater systems. And there's ways that it could really be, houses could be more self-sufficient if it's allowed and it's proven even in more urban areas. So we still have septic systems, of course, it's just basically a septic system, but making it to where it really fits in with the house. Making water systems that are really efficient to be off the grid from water. And so those are some of the kind of initial concepts with Elevate was to store water in the base in the trunk of the tree. So this void here, that was a whole original concept, was this is the giant cistern that your house sits on top of. So it's just evolved from that. But those components are still there, those aspects are still there. It's just kind of evolving. Wow. Okay. Well, let's, I don't even know where to go from here. Let's go back to the one with the, what slide number six, or this one here? Oh, slide seven. Seven. Yeah, if I could go back to slide seven. Which one? One, the next one after that. Yeah, here we go. So here's, you know, whenever we built the initial structure when we had the plants on it, you could really feel a cooling effect as the breeze would blow across the plants. And that's a pretty well-known natural phenomenon, evapotranspiration, kind of like a swamp cooler. But this is an area that we can start doing some testing. Like what is that impact of the living walls around the structure, as far as the temperature pooling from the wind, and then also the insulating properties of that. And so there hasn't been structures that are this small all raised up around to test and monitor. So we think that's another thing we wanna be able to test, get some data behind it, see what the efficiency of that is. And the living wall systems we built were like a pre-made panel that was spaced off of the structure. So it's not gonna, it's gonna get airflow. It's not gonna rot. The water's controlled. It's a very controlled system.  And so there's ways to do it practically. There's ways to then maybe 3D print the walls to have that living wall part integrated into it and the water catchment and filtering into it. So it's a really well done system to make the living walls very practical. And then it's great too for looks and also for edible plants. And so there's a lot of practical reasons for that. But that's not, it's not a requirement of the structure. Edible plants, now there's a concept. One thing, cherry in our climate, cherry tomatoes are really, really easy to grow. There's a lot of movement towards that grow your own food, social sustainability communities. And then in the lower and down position, you know, what if we draw air in and have that kind of a stack effect out of the center? And how do we cool a very large area? And this is more in developing countries and stuff where we would use this where you know, there's, you gotta do a lot with very little. And but how can we get a comfortable environment from airflow through a structure like this? Either incorporating living walls or other technologies to make this really feasible, mass solution for housing in areas. That's also very transportable, right?  This foundation base here is all made to level to the ground that it matches. So within a four degree slope, it has hinges on each end to get it level. You gotta, ground generally slopes for drainage. And so that's factored into all that. So it's, it's trying to pre-think a lot of the basic things that go wrong with structures. Here you see some of the basic drawings of, it's just seven parts to make this core structure. 10,000 dollars for half material, half labor to fabricate this. So it's a really efficient way to make a structure with these just two by two, two be their steel. And again, you're thinking of 3D printing, when you... Yeah, there's definitely some parts.  There's no way to compete, but that's a very low cost sort of way. But there's other parts where we could add a lot to it, maybe in the hinge area, in the roof area, maybe in the foundation piece. And then over time, as the cost of 3D printing becomes as low as anything, then it could, anything can happen. Yeah, and speaking of dollars, I understand that there's a major, major foundation that might be interested in you. I mean, there's all kinds of interesting things out there. There's the Breakthrough Energy Fund is one that's come out recently, but there's a lot of movement around the green space. And... Absolutely, yeah. Actually doing something about it, making decisions not based just on the pure financial return, but more social and ecological return. Well, to talk about the need for housing, we are a first world country, or Hawaii is a first world state, but the need for housing is just aching out there. And we've been trying to realize that in fits and starts in very expensive ways. Yeah, I think we've found that there's, we need different ideas besides status quo type structure. But a lot of those status quotes are driven by building codes, right? So I'm not ignorant to any of that, but there's also changes that can happen over time in a stepwise manner. Well, I'm a building code guy myself. I can say that building codes are flexible, they are dynamic, you just have to meet the basic health and safety issues. And then you're pretty well free to go from there if you can persuade the officials. Right, we try to always think about that from the start. You know, I'm a licensed engineer and I'm a licensed architect. People working on it that know the basic science and the basic requirements and regulations. And so that's a really critical part that at the end it's based on reality and not fiction.  Oh yeah, you gotta get dirty. You look at a lot of innovations, there are things it's just, you think of it and then you do it and you physically do it. And that's the way it advances. Cause there's no one else that really understands exactly why that is. Like, so it's hard to convince to do things. It's best to sometimes do it yourself. Yep, absolutely. Thomas Edison being the best example of that.  And I certainly wish you all the best, Nathan. I mean, this could be the start of something really, really big. I'm thinking of homeless shelters, the whole business, and the possibilities are endless.


So, hopefully you're here to hear somebody, namely me, talk about why the ACTO project for my IOT project. If you are not here for that talk, you're welcome to stick around. I don't want to bore you with something you don't care about. But if you're in the wrong room, this isn't like an airplane where you're stuck. You're welcome to get up and go to the right talk, but hopefully we're all here for talking about the same thing. I have a mic up here. I would encourage if you have questions as we're going, I'd much rather handle them as we go rather than waiting and batching them up at the end. So just do your best to get my attention. I got the mic up here. I know we're recording in the back, so we'll try to pass the mic around if there's any questions or discussion as we move through the presentation. So briefly, what the heck are we doing here? Why are we here? So I'm going to start just a little bit with some motivation about why IOT is interesting and that kind of thing. I suspect for most of us it'll probably be redundant, but it's always good to kind of start with that level of detail at the beginning. We'll dig a little bit into some of the challenges for just general embedded development, for Linux development in more particular and even deeper for IOT development. Again, probably a review for a lot of those in this room given the audience of this show, but still good to have it in there, especially since this will be captured for posterity somewhere. Then we're going to describe the basic IOT workflow, kind of getting started, you know, when you're getting started with an IOT design, what the heck do you have to do and what are the first five or six big questions you need to ask? Then we'll dig a little bit into an overview of Yachto, ultimately that is the meat of this presentation and talk about some of the benefits of both Linux and Yachto as it relates to IOT development. And with that I kind of wanted to kind of pull the audience here. How many in here are familiar with and have used Yachto in the past? So pretty much everybody. So the benefits of Yachto, I probably don't need to sell you guys on unless you're just starting with it. What about IOT development? So a little bit less than half it looks like. So a decent arrangement of folks. This isn't really intended to be a deep dive into Yachto or anything like that. I've got some links at the end for some other talks. There were quite a few other talks going on at this conference. So if you're really looking to get real deep into Yachto, this isn't the place for it. A little bit about me. My name is Drew Mosley. I currently work on a project called Mender.io. You might have seen our booth upstairs. It's an open-source project for deploying over-the-air updates to connected embedded Linux devices. I've been in the embedded Linux development space for about ten years, focused primarily on Yachto and then longer than that in general embedded software. My role lately is more about technical marketing, customer solutions architecture and that kind of thing. The Mender project is a completely open-source project. And if you have the need for some over-the-air updates for your connected devices, we sure would love to have you use in our product. So as I said, motivation, this is typically the business side of things and the links to things like Forbes in various places where they talk about dollars and things like that. I think it's pretty obvious to everyone in this room. Our embedded projects are increasingly using Linux. Again, this is the embedded Linux conference. Not hard to sell most of the folks here on that. The market opportunity, obviously, is pretty big. $267 billion by 2020. I think we would all like to have at least some portion of that. And Linux is an extremely big player in that market. Nodes and gateways are estimated at over 17 billion units by 2023. And that's driven by a lot of things, but the relative inexpensive hardware that's out there, relative ease with which you can gather them, things like Raspberry Pi, Beaglebone, I'm sure we're all familiar with. And then production hardware with manufacturers like Toradex, Verisite, Boundary Devices. And then the semiconductor manufacturers are also playing a big part in making this available and more widespread. So some challenges as embedded, in general, as embedded developers, as embedded Linux developers, and IoT developers that we face compared with typical enterprise or desktop style development. We deal with a wide variety of hardware. On any given day, we may have multiple chip sets on our desk. Our design may have a multi-core ARM where it's run in Linux. It might also have a single core MCU running on RTOS, that kind of thing. We'll deal with ARM one day, maybe x86, maybe MIPS, so we're kind of all over the place. We also have a much wider variety of storage media we have to deal with than is typical in the desktop application. Most of the boards we deal with in the prototyping space, they generally use SDMMC or just onboard EMMC. But more commonly these days, we're seeing raw flash devices. We're seeing SATA devices. There's quite a range of choices there. And each one of them has their own pluses and minuses and challenges with getting images deployed to them, longevity, and that kind of thing. When we're dealing with embedded Linux, the software we're using might not be maintained in the canonical upstream location. A lot of times we have kernels that are maintained by the chipset providers. Eventually the changes will make their way back upstream, but at any given time we might be working with different forks that are not necessarily the same from project to project. And of course we're generally speaking dealing with cross development.  But that's generally a pretty painful approach given the performance of most of these devices. And if you haven't been in the embedded space for a while and you're not familiar with the workflows involved with cross development, that can typically be a pain point that we want to try to help ease for people coming into the space. And getting the initial images on the device and keeping them updated is a constant battle. Every device has its own mechanism. If it's an SD card, it's pretty simple. You usually pop the SD card out, you put it in your desktop. You're able to write the image. But if it's got onboard EMMC or raw flash, it's going to have its own mechanism, which is typically going to be unique to at least the board vendor. So you're going to have a different provisioning setup that you use for any given device at any given time. So you're getting started in embedded Linux and IoT development. The first thing you do is you go to the web and you say IoT Getting Started Guide. So that's what I'm trying to get at here with the next couple of slides. So the first step, buy and pick your hardware. Obviously, the picture here shows a number of Raspberry Pi devices. I think we've all seen those. There's all sorts of selection guides. The link at the bottom of the slide here from Make Magazine covers somewhere between 30 and 3000 boards, depending on the day you go look at it. The number of boards that are available is astounding. And they come in a wide variety of form factors. Certain different amounts of memory, different chip sets. So there's plenty of resources on the web for you to start digging into some of these things. But that's the first step, what kind of hardware are you looking at? How much power do you need? Do you need display capabilities? Do you need video input capabilities? That kind of thing. Second step is what is your connectivity? What I'm showing here, this is a Toradex Astor board. That's their base board, actually on the back side of it is their system on module. So that can be either be an IMX6, IMX7, IMX8. But typical connectivity, especially in early portions of the development, obviously you got your power in Ethernet, you may have USB. In this case, we have an LCD panel connected. So you look at the connectivity you need for the development side, where you're gonna need things like JTAG maybe, maybe serial consoles and things like that. And then also the connectivity for the end use of your application, whether it's gonna be Wi-Fi, whether it's gonna be ZigBee, whether it's gonna be any of these new protocols that are coming out. So all of these things, you wanna start thinking about early on when you're putting together your high level plans for your IoT design. Once you've got the hardware and you've got it connected somewhere in your lab, you need to install the operating system. And generally speaking, in the embedded space, in the embedded Linux space in particular, there's three main ways that you're gonna get a target operating system. One is you're gonna use a binary distribution. So this is very much like you do in your desktop laptop PC.  At that point, you've got a fully functioning system. You can run app, get update, get the latest updates, get the latest kernels, install whatever programming languages you need, that kind of thing. And with a binary distribution like this, it looks very much like you're working on your desktop operating system to begin with. One step or move from that is moving backwards to the build tools that are generally used by the distribution folks themselves. Things like DE Bootstrap or whatever the build tools are that are associated with your distribution of choice. That gives you a little bit more control and a little bit more flexibility as far as having a starting point that you can share from developer to developer. But it's not quite the equivalent of what we call a build system, which is where Yachto fits in. And the distinction really is with things like Yachto and Buildroot, there is no separation in the developer's mind, typically between the build environment and the run environment. They're all the same thing. Whereas with something like an OpenWRT or a Debian, most of your users are going to grab the binary and that's all they're going to work with. And then you have some set of core developers that will be working on the packaging and the build system. But with Yachto, it's all one and the same. And once you have a system up and running, next step, develop and test your application. A lot of details that I'm glossing over in these two bullet points. And that's not really the meat of this topic. So I figured I'd kind of put them together. We all know we have to do it. And once you have this base system up and running, you have numerous options. We'll touch on a few of them as we go through. And then we want to test the system. Do all the blinky lights come on when you expect them to? Are all the peripherals working the way you want? Is your application running? Do you have the proper network connectivity? Do you have, you've got an Internet of Things device. You might have a fleet of multiple devices. Are they communicating with each other as expected? Do you have your cloud infrastructure on the back end aggregating all the data? There's a lot of details, again, that go into that test. And some of that is related to Yachto and some of that's kind of peripheral to it. So we won't dig too deep into that. And finally, deploy the system. Again, glossing over a lot of details. You might have analytics. You might have logging. You might have fleet management. You'll have updates of your system over the life of your system. So there's a lot involved there. And the choices you've made all the way up till now will play very, very much into your ability to do this successfully with your IoT designs. And I kind of lied. There is a step eight, because ultimately this is why we're here. We want to make some money off of this. So step eight is obviously, once it's out there, end users, consumers love our products. And they rush to the stores to give us money for our products. So ultimately, that's our goal. So I ran briefly through what a build system is. But let's dig into that. What exactly is a build system in this context? It's a mechanism to specify and build the software, the system software, all the way up to the application stack that runs on your embedded device. It may include the bootloader. Typically, it will. But some designs, it's going to be different. It has a mechanism to define the hardware and the BSP. And it allows you to integrate your application, any additional libraries, any additional custom code that may be provided by your manufacturers or anything like that. The build system is going to give you a way to integrate that all in a well-defined workflow that allows you to easily bring those components in, mush them all together into a single distribution or a single binary that you're able to then deploy and provision to your devices. One important thing about a build system is it allows for easy reproducibility. This is one of the big differences between something like the OctoBuild system and starting with a Debian system where you log into the system and run app, get update, and pull everything down. When you run a build with the OctoBuild system, what you get at the end of the day is the fully functioning system. You don't then expect to log into the system and add extra packages in there. So you know that exactly what you have in your lab and your testing is what's going on in your end user devices. So that reproducibility is very important. Because of that, it allows you to support multiple developers. If you're dealing with a golden SD card image that some developer in your lab has installed everything on exactly as you need it, and then they back that card up and they hand that out to all the other developers, that adds a point where things slow down because there's one or two developers in charge of that golden image, and every time you have an update, then you've got to get that pushed out to all your other developers. With a build system like Octo, that's baked in to the workflow that is part of the build system. A couple nice to have, it should allow for parallel processing in your build. That's pretty straightforward. But generally speaking, the amount of code going in to build any one of these embedded Linux systems is staggering. It's just you're building a lot of packages. It takes a lot of time. And if you're trying to do it without running a lot of things in parallel, you're going to start your build, go away for the weekend, and come back in a couple of weeks, and you'll be fine. But the more cores you can throw at it, the better. If you can throw more memory at it, even better. If you can go into a cloud-based infrastructure, you can always go to the very biggest AMI instances that are out there and run it there. So that'll get you speed in your build. I mentioned cross-building early on as a typical workflow. The tool chains when you're talking about cross-building tend to be a pretty big pain point. If you've ever tried to build a tool chain and get all the libraries and all the components you need at the right versions and get them built and staged together in the right bootstrapping order, you understand how complicated that would be. Fortunately, these days, there are a lot of choices where you can go get pre-built tool chains. All the build systems have their mechanism for building the tool chain. So that takes that pain away from you as a system developer. You don't have to worry about, OK, do I have the right versions? Are they going to play nice together? That's all integrated into the build system, and you don't have to spend any more time worrying about it. And finally, for some designs, license management is a very important consideration. Some design is not so much some, but in some cases, you want to make sure there's no GPLv3. You want to make sure there's no proprietary code, whatever. The Yachto build system has a very good mechanism for keeping track of the licenses, letting you exclude certain licenses, having it throw errors if you pulled something in that pulled in a dependency you weren't expecting that may have maybe pulled in something that's questionable from a licensing standpoint. So that's all part of the build system. So what isn't a build system? The build system is not an IDE. Generally speaking, Yachto, you're not going to be developing your application in Yachto.  But typically, your actual day-to-day back and forth of typical application development, you don't do as part of Yachto. Yachto then acts as a packaging step once you have the base code, and you're ready to actually release it to the next step in your development pipeline. It's also not a distribution. Yachto focuses on mechanism-not-policy. So they have sensible defaults so that you don't have to specify every little detail of your system to begin with. But if you want to change from, say, SystemD to Sysvianet or vice versa, that's easy to do. Whereas typically with things like Debian or Ubuntu, they tend to apply a lot more policy on top. And if it doesn't fit with your design, then you might be in for some pain to get that addressed if you're using a system like that. It's also not a deployment and provisioning tool. And what I mean by that is once you have the images out of Yachto, typically it's a separate step to then get the images from your build system to the device, whether it's writing it to the SD card or using some kind of USB system where the board is mounted as a OTG device and you're actually writing it as if it were a block device on your system, those are typically going to be outside of the scope of Yachto. Although in a lot of cases, in the platform, the BSP repositories you're looking at, they'll have instructions showing you how to do that. But like I say, it's typically a post-processing step. And finally, it's not an out-of-the-box solution. You're not going to go download Yachto, press run and have a system doing everything you want it to do. The whole point of something like Yachto is the configurability it gives you and the ability to pick and choose protocols, application, development environments, languages, everything you might need. You will have to do some customization and designing of your system through the Yachto workflows. So we've kind of talked around a lot of these things. The quote you see here at the top of the screen is not an embedded Linux distribution. It creates a custom one for you. That's a tagline directly from the Yachto projects website. And that kind of goes back to what I was saying just a minute ago. It focuses on mechanism not policy. There are, actually in Yachto, there is the concept of a distribution that you can specify as part of your configuration. So if you want the angstrom distribution, that is a packaging step in Yachto that brings together a number of policies and gives you a certain level of functionality. If you don't want that, you can specify others. So it gives you the ability to pick and choose at the very highest level of functionality in your system. What the Yachto project really is at its core is a collection of recipes, metadata, dependencies and configuration. So recipes in this case refer to what are the steps needed to build any given package. Configure, make, make, install is the most basic, but there's all sorts of packages that use many different build and deploy methodologies. So that's all encoded in the Yachto recipes. Metadata is just a general term that you set metadata for some of the selections you make in terms of the policies you want to implement for your design. You set, it's the data that goes into the build system that actually controls everything that the Yachto build is gonna be doing for you. The dependencies amongst these packages get very hairy. And if you had to track that manually, you would, again, not be very happy about it. Fortunately, Yachto, the recipes specify automatically the dependencies that they have. So when you build a particular package, it knows whether it needs the C library or if it needs Python or a particular Python library. And the build system of Yachto called BitBake pulls all that information together and is able to build a dependency graph and know exactly what needs to be built first, second, third, and it's able to actually scale that out to as much parallelism as you can throw at it and make sure that you're not running into issues where I'm ready to link something but I don't have the library to link it with. So all that dependency tracking and scheduling is handled by the BitBake package manager that's built into Yachto. And then just general configuration. You have configuration files at the BSP layer that specify the chip set, the architecture, the instruction set for your board, you specify what boot load or what version, things like that. So the configuration in Yachto is extremely detailed and gives you very fine-grained control over the way your system is built. The primary output of a Yachto build is a package feed. And this is essentially a directory on your build system that contains a whole boatload of .rpm files or .deb files or .ipk files depending on which packaging choice you have made. It also has the configuration to allow you to install those packages into an existing system if you so choose. So from that perspective, the output of your Yachto build can look much like a system, your desktop system where you can just run app, get update and get new packages. That's great at development time, you probably want to turn that off before you deploy the thing. The secondary output of your Yachto build is the actual boot images. Now, in practice, for the level of work I do, I don't deal with the package feeds all that much. I use it mostly to get those boot images.  It's important to note that everything in Yachto is built from source, that is the methodology. Now there are some things like firmware binary blobs obviously that aren't really built from source but ultimately if it's possible for the Yachto system to build something from source, that is the preferred mechanism to do it. And I mentioned mechanism, not policy but I want to mention it again because that's a very key portion of a system like this. And then again, the main products that root file system image, kernel bootloader, the tool chain is there, which is nice because then you can hand the tool chain off to your application developers and they're able to actually cross compile their code. So the Yachto project is organized into, it's got a very regimented layering structure and this is how we get a lot of good functionality. The base layers have the minimum necessary to bring a system up and running. If you go to and check out the base Yachto layers, the only platforms that exist in those layers are there's I think the Beaglebone black and then a couple of emulated platforms. So typically your platform support is going to be handled in a separate layer. There's a lot of functionality at higher levels. There's graphic stacks, there's things like QT. We'll get into some of the IOT specific stuff in a couple of slides. But the idea is to separate that functionality out into logical blocks that you can pull together based on the specific needs of your system. So you're going to start with a platform or a machine BSP of some kind. You're bringing the Yachto base layers and then you might, if you need QT you'll bring in those layers. If you need some of the IOT specific protocols you'll be pulling those things in. It allows these systems to progress at their own rate. Some of them have less developers. They may not be doing point releases at the same pace that the Yachto project is doing. So it allows each of these individual layers to proceed at their own pace. Additionally there's an SDK mechanism. I mentioned that the tool chain is an output of the build. In addition to that you can actually package up libraries, header files and everything needed for application developers so that you can give them a separate package that they're able to use and your application developers will not need to get involved with the full Yachto system level builds. That makes things a lot easier for them. You can, as the system developer, I can have a policy of I publish a new SDK every week, every month, whatever's appropriate. My application developers know that then they can come in and get the very latest in their building against something that has been at least tested to some level by me and then they don't have to deal with all the details of understanding how to do Yachto project builds. Some of the optimizations that are built in, parallel builds, I mentioned that, that's very important. Yachto also has a mechanism called shared state and this is basically caching the intermediate steps of each of the packages that you're building. All the tasks that go into building a particular package, the intermediate product at each point can be packaged off as a shared state and reused. So that means if I'm building Busybox, the first time I build it, yeah, it's gonna build it from source and then it's gonna save off the original source, it's gonna save off the patched source, it's gonna save off the output of the configure step and the make step and the make install step. So the next time I come back and build, if the configuration has not changed such that it would affect any of those pieces of output, then it can just reuse that cache data that it's already saved. And that's a great time saver. If you have a continuous integration system, you take the shared state output from your nightly CI builds and you export that over just a web URI and then all your individual developers can point at that so that if they're using the same exact thing, it cuts down their development time quite a bit. So if you haven't looked into the shared state and specifically the shared state mirrors with your YAKTO development, I highly encourage you to do so it will save a lot of time. So in general, getting started with YAKTO, I think based on the number of folks that have already worked with YAKTO, this is probably old hat, but these four commands are enough to check out the basic system from the YAKTO project, get repository and then run a build for an emulated x86 platform and invoke it. You're not gonna do a whole lot with this. It will launch a terminal window as you see here, but this set of statements is a copy and paste way of getting something up and running if you're unfamiliar with it and you wanna kinda get a feel for the workflow. So the emulator integration into YAKTO is very good and it's useful for a lot of things. So again, that's something else you might wanna look at if you haven't spent much time looking at that before. So we can kinda step back and talk about why Linux were embedded. So a little bit of the higher level, I think most of this should be reviewed for all of us. Obviously, Linux is everywhere. There's a lot of available software out there on your Linux system. You can run just about every network protocol ever conceived. There's a lot of Linux expertise as can be gathered from the number of folks at this conference. Plenty of training materials, that kind of thing. So if you're having a hard time convincing your management, that's kinda what these slides are for. Broad device support, again, Linux probably supports more chipsets and things like that than just about any system out there. And it gives you a very common system architecture on both your build host and your target, which is very useful. It speeds up your developer's times. They don't have to spend a whole lot of time learning new systems. And it's open source. If that's important for your design, obviously that's just one thing to keep in mind. Industry support, there's a lot of industry trade groups and that kind of thing. There's Genevieve and AGL in the automotive space. Obviously, there's the Linux foundation and things like that. So there's just a lot of activity in the Linux space. And like I say, these slides are generally for those that have a hard time convincing their management that this is something they wanna contend with. But I suspect we can kinda get past most of that here. So, specifically about Yachto and IoT, I just wanted to go for a few minutes now and kinda talk a little bit more about that. Generally speaking, Yachto is very well supported by most of the semiconductor vendors and the board manufacturers. So chances are if you're looking at a board for an IoT design, chances are your vendor already has some level of support for a Yachto layer for that board. It does have a very well-defined workflow. Once you get into Yachto, it's very similar from system to system. So once you know it for one system, you know the basics for what you need to do when you're ready to move on to the next design. Because of the reproducibility of these builds and the fact that you're not dealing with a single golden image that one person has the right to update, it does support large developer teams very well. I can add things in my local configuration when I'm ready. I push them up to my get repose and the other developers on my team can then sync with that, pull it down, they do the build. Now they have a matching image on their system. So it works very well for that. It does, there is very easy access to IoT specific protocols, and I've got a few examples of that in a minute, but basically the layering mechanism that I mentioned makes it very easy for these things to be packaged up and stored and accessed in any given design. And it does have very good connectivity and coexistence with the RTOS's. In the IoT space, a lot of times we're dealing with multi-node systems. We might be dealing, we might have Linux on some of the nodes and we might be running free RTOS or Zephyr or something on a smaller MCU-based design. So it's good to know that there's a lot of collaboration in those communities and that these things work very well together. And another very critical, important update, the thing to mention is that the upstream Yachto project has a very regimented release cycle. They do keep up to date with any of the critical vulnerabilities that are out there. So if you're using a Yachto stable branch, you get a lot of that in your design you're able to pull from without having to do a whole lot of extra work. So you get to reuse a lot of the work that the folks at the Yachto project are doing to maintain the stable branches over the lifetime of your project. So I mentioned IoT-specific protocols. I assume some of these on this list, many of you are familiar with things like MQTT. There's a package in one of the Yachto layers called Python PAHO MQTT, which is just the Python implementation. It's very easy to use, very easy to add to your system. That's actually in one of the core open embedded layers. MQP is implemented by RabbitMQ. I don't believe that's one of the core Yachto layers, but there is a thing called the Yachto Layer Index that pulls all this information together. And then other things that are used, co-app, zero MQ, GPS, Bluetooth, obviously is pretty widely used in the IoT space. So all of these kind of protocols are very well supported in the Yachto project. And it's usually just a few minor steps to get those things pulled into your design and into your configuration. Networking, there's quite a few choices for network management, obviously, keeping track of Wi-Fi, SSIDs and passwords is kind of, can be tricky. SystemD networking is a component of SystemD that's built in, that's fairly easy to use. If you want something more full-featured, then there's things like Conman, which is used pretty extensively in the automotive space, and the network manager, which I know is a part of my Ubuntu desktop, so that those kinds of things are also available. You can switch between one or the other depending on your specific needs. And finally, moving up the stack to your application developers, Python and Node.js seem to be the most commonly used application frameworks for IoT designs, and they are very well supported. They have layers with the base language support as well as many supplemental libraries and that kind of thing. So it's very easy to get the libraries and languages supported that are needed for your application developers as well. And this is a screenshot from the Yachto layer index that I mentioned. You probably can't read it very well. The source at the bottom of the screen is actually the direct link to the layer index. And all I did here was search for the term IoT and you see there's quite a few layers here that contain components related to IoT. Another interesting search was cloud. I found a number of components for accessing some of the commercial cloud providers like Azure or AWS or Google Cloud or some of those. There's a lot of integration with those providers already built in to the Yachto layers. So it really does give you a leg up in getting your system design up and running very quickly. So just to kind of sum up why Yachto for IoT designs, it's very widely supported. Chances are any board semiconductor that you're looking at already has some level of support in the Yachto project, has a very active developer community keeping track of security updates and that kind of thing which isolates you from a lot of extra activities. The layering mechanism, I can't overstate how important that is in Yachto. That is one of the key core components of any Yachto project design. Making it extremely customizable, extremely enhanceable, very easy to configure for your particular use case. It does rely on minimum native tooling which makes it very easy to run on a wide variety of desktop PC operating systems. I generally use Ubuntu but it typically, if Yachto needs a particular package as part of the build time, it's gonna build it itself. So you know that it all works very well together and it's very easy to deploy to whatever distribution your developers may like. And finally, I do want to mention one more time the ability to predict the exact software contents. If you have a system in the field where the end user is able to install new packages, it makes it very difficult to know exactly what's on the device, know that you've tested every possible combination. If you use something like Yachto, it gives you a very good starting point to know exactly that what I'm testing in my lab is exactly what's going out to the end user. There's no, I don't have to worry that a distribution provider may have pushed an update that my end users end up pulling, that is not good. So that's a very important thing. Couple of downsides, it has a pretty steep learning curve. Those of you that have already gone through the learning curve probably are familiar with that. It is a pretty unfamiliar environment to non-embedded developers, especially in the IoT space. We see a lot more folks with the web and UI UX experience coming into the IoT space, wanting to learn how to design these systems. And the whole idea of cross building and things like that, that's very foreign to them. So that's definitely one of the downsides. And it's very resource intensive. These builds take a long time. They're gonna require a lot of disk space. When you're starting from scratch, you're looking at, depending on the configuration, anywhere from an hour to six to eight hours, depending on the strength and power of your machine and possibly multiple gigabytes of space. So this is not something you're gonna run in a Chromebook in a half hour while you're at lunch. So I would encourage you to keep that in mind. So with that, I got a couple resources here and we definitely have time for some questions, I believe. So the first link here was a talk I gave last year that goes in a bit more depth on this topic, comparing Yachto to other build systems and giving you a little bit more comparison there. The second link is actually the article that I wrote that led to this talk. So it goes into a little bit more depth about this specific topic. And the last link there is kind of a next step up from that getting started page that I had that will actually walk you through in less than a half a dozen copy and paste steps, getting started doing a build of Yachto for a Raspberry Pi 3 and in a self-serving fashion, it also happens to be running the Mender Updater. So at that point then you actually are able to update your device over the air. So I would encourage you to take a look at those links, ways to get in touch with me, obviously down at the bottom. I'd love to hear from you if you have any questions. We'll certainly take them now. And if you have any thoughts or anything you'd like to share afterwards, there's plenty of ways to get in touch with me. Of course, all the way in the back corner is the first question every time, isn't it? Thank you. What is your opinion to use Yachto on a real server? In what sense? To actually generate the code for your server? No, to use Yachto as a distribution for on a real hardware server. So DNS server, NFS server, FTP server, all that? I assume all those things are supported is not something I've ever looked at doing. But with the amount of functionality that's available in the various community layers, I'd be very surprised if that wasn't feasible. But it hasn't been my focus because my focus is generally on the embedded client side of things. Yeah, I missed the talk earlier about comparing Yachto to build route, but could you elaborate just the bullet points from that perhaps, or if you could tell me if that link answered that question? Well, that link definitely will answer that question. That was the talk I gave at ELC Portland. But at a high level, they both solve the same problem. So ultimately, they're both very similar at the very highest level. It's really in the details. One thing that build route doesn't do is it doesn't have the concept of a package feed. So build route itself produces the binary that you run on your target. But there's no concept of now I have a package for something that I can install later on. So that's one of the big differences. Build route is focused on simplicity. It has a lower learning curve, generally speaking, than Yachto. Out of the box, the build configurations are gonna have just about everything turned off. Whereas in Yachto, they have more defaults that are turned on. In build route, generally, you're gonna start with a much more minimal system and then have to build up from there. But it's really an Emacs versus VI discussion. They both have their pluses and minuses and they both have plenty of people using them in active communities. I would encourage you to check out both of them for sure. Thanks. All right, anybody else? All right, thank you very much. Let's all go home. All right.


Welcome to All Hands Update, I'm Petty Officer Jonathan Pankaw. Hiking is a great way to spend time outdoors but there are some things to keep in mind before you head to the trail. Know the terrain conditions, local weather and your equipment before you start. Wear adequate hiking boots and bring an extra layer of clothing to stay warm. Make sure to consider your physical limitations and know when to postpone your hike. Never hike alone during long trips and you should bring at least two friends. Do not interfere with wild animals and be aware of poisonous plants and remember to bring plenty of drinking water because water from ponds or streams can make you sick. Bring in a poncho, first aid kit and waterproof matches will ensure you're ready if the weather suddenly changes. For a complete list of tips and information on hiking safety, visit the Naval Safety Center website.


OK, so let's do another one of these gas law problems. This one's a little more convoluted, but we'll be able to figure it out a bit. So it says, if you have 10 liters of carbon dioxide gas, 10.0 at 300 Kelvin and 1.008 M, if we double the volume and double the temperature, what is the new pressure? OK, so what are we looking for in this one? Pressure 2, right? P2, OK? And it says that we're going to double the volume. So what would the new volume be? 20 liters, right? 20.0 liters. And the new temperature is also going to be doubled. So what would that be? 600 Kelvin. And remember, we've got to put that dot there. To make sure we know that it's three significant figures. So do any of the variables change? Does volume change in the process? So does temperature change? Does pressure change? Yeah, it's going to change, too. So when we write Pb equals Nrt, are we just going to use this form of it? Or are we going to divide by the other Pb equals Nrt? So we'll put 1s on everything. Pb equals Nrt, and we're going to put 2s. OK, and now we're going to cancel out the things that didn't change, OK? So pressure changed, right? So that stays in there. Volume changed. That stays in there. Number of moles, did that change? No, no, so we're going to cancel that out. R never changes. So we cancel that out, and T changed, right? So we're going to leave that in. So we're looking for P2, right? So let's write out what we've got now. P1, P1 divided by P2, P2 equals T1 over T2, like that. So remember, we're looking for P2. So the first thing we're going to do is flip, right? We're going to flip them over, OK? So P2, P2 divided by P1, P1 equals T2 divided by T1. OK, remember, we've got to isolate P2. So can anybody tell me what we need to do? Multiply both sides by 1. And divide both sides by 1. P1, P1, and divide both sides by 1. So P1, P1, P1, P1, and divide it by what did we say? P2. P2, because we want to get P2 by itself, right? So if we divide by P2, let's cancel that. Does P1 cancel? Yeah, does P1 cancel? Does it cancel, guys? Yeah, OK. Does P2 cancel? Does it or not? Yes, OK. So what do we left with on this side? Just P2, right? We've isolated it. OK, so let's write what we've got. P2 equals T2 times P1 times V1 divided by T1 times V2. If you're not, get better at it. I erase this part here. All of this part that we've done. OK, so P2 equals, well, let's just plug in. So we've got T2, which is 600 Kelvin. And we're already in Kelvin, so we don't have to change our temperature. That's right. P1, 1.08, and P1, 10.0, divided by T1, which is 300 Kelvin, times V2, which is 20.0 liters. So hopefully, you guys can see we can cancel Kelvin. We can cancel liters, and we're left with ATM. ATMs are good pressure units. So 600 times 10 divided by 300 divided by 20. I guess we didn't need to do that. What did we get? 1.0018. So that was kind of a tricky problem, because when we doubled both of those, they offset each other. So are there any questions about this one? It is a tricky one.