 In the next 40 minutes, I'm going to show you how to build a simple remote control robot with Automotive Grade Linux. My name is Leonor Navi, I'm a Senior Software Engineer at Kansako Group. Kansako is an open-source embedded software services company which specializes in system architecture, development, building, maintaining upstream open-source projects such as Automotive Grade Linux. So today we already had two talks about Automotive Grade Linux in this very room. The beginning of the day, Walt Miner gave us an overview of Automotive Grade Linux, the new stuff that we get there. It was a great talk, Walt is over there. And after that, my colleagues from Kansako Group, Scott Murray and Matt Porter gave another talk which was more specialized. So today, now, today I'm going to present to you AGL in a little bit different angle. The agenda for this talk contains a brief overview of Automotive Grade Linux. Without that, I'll speak about the supported hardware in AGL and how we can use this hardware with some peripheral devices to build a different product, let's say a toy. Later on, I'll explain how to do integration and contribution of software to Automotive Grade Linux. Finally, we'll have some time for making conclusions and, of course, questions and answers at the end of the talk. Although the title of the talk says that we are going to build a robot, this is not the main purpose of this talk. The main purpose of this talk is to do an experiment, an experiment to find out if other industries can benefit from the features existing in Automotive Grade Linux. If you're building Internet of Things connected devices, there are certain requirements if you want to run Linux on them. You require from the Linux distribution to have a built system and a whole development tool chain. You require a certain security level. It's nice to have over-the-air updates. And of course, for certain devices, you need a graphical stack and applications if there is a user interface that is on a display for the users. Doing all this from scratch can take a lot of time. And on the market, there are a lot of open-source Linux distributions which cover these requirements. One of these Linux distributions is actually Automotive Grade Linux. So in the next few slides, we'll see how Automotive Grade Linux fits into this. How many of you are familiar with Automotive Grade Linux? Can you raise your hands if you have been involved somehow? Are you developing applications or platform developers with Automotive Grade Linux? So I hope that I'll inspire you to contribute more code and to use more Automotive Grade Linux. Automotive Grade Linux is a project of the Linux Foundation. It was created to provide in-vehicle infotainment the new Linux distribution for the Automotive industry. It's already based on top of popular open-source projects such as the Yocto project and Open Embedded. Automotive Grade Linux was founded in 2014, and in the past three years, there is a tremendous progress. A lot of companies are contributing to Automotive Grade Linux. If I'm honest, these are not all of the companies. I didn't have enough space on the slide to fill in all the companies. A lot of people are contributing to AGL. AGL is having a six-month release cycle. If you notice the dates, you can see that every six months, we have a new release. Currently the stable release is darling DAP. Now we're working on the next release, Electric EO, which is scheduled for December 2017, and actually the first release candidates are already available. This six-month release cycle is pretty much following what is happening in the Yocto project, so we try to be up-to-date with the Yocto project. We have a look at the architecture of Automotive Grade Linux, the core technologies that we have there. It's obviously a Linux distribution, so we need a Linux kernel. It's a Linux distribution that is built with security in mind since day one. So we have security based on SMAC and Sinara. This is something that you might be familiar with from other projects, such as Tizen. There is an application framework. On top of this, we have SystemD, D-Bus, and we have a mechanism for doing software-over-the-year updates. There is a sort of client called Actualizer, which is integrated with a popular open-source tool for doing binary diffs and shipping these diffs to the embedded devices on which AGL is running. It's called OS3. You might be familiar with it from the project called GNOME Continuous. On top of this, we have a graphical user stack, which is relying on the Wayland protocol and the Western compositor, which is a reference system of the Wayland protocol. The user interface, as of the moment, if you build the default target of AGL, contains a bunch of really nice-looking Qt and QML HMI applications. Furthermore, AGL supports HTML5, G-streamer, and a lot of other technologies. As I already said, Automotive-grade Linux relies on the Yocto project and open-embedded for building the whole distribution. This means that Automotive-grade Linux incorporates a lot of different layers, meta layers, from the Yocto project, such as Pocky, the reference system of the Yocto project, and a lot of specific projects that bring features that are specific for AGL. I listed a few of those layers, not all of them. Keep in mind that we have a bunch of board support package layers for all the hardware that we're supporting in AGL. Just a brief look at what is supported in AGL. We have support for Renaissance generation 3 and generation 2 boards. Keep in mind that we're speaking about an Automotive Linux distribution, so the supported hardware devices are devices that are heavily used in the Automotive industry. AGL also runs on Intel devices, on Texas instruments platforms, such as the VAU board, on Dragon board, on Raspberry Pi 2 and 3, Raspberry Pi is a community-supported board. And since a few days, it also works on IMAX 6, Sabre and Humming board. Humming board is the latest addition to the supported hardware platforms by Automotive-grade Linux. This is a screenshot of the home screen of Automotive-grade Linux. Let's have a look at the toolchain that we have for development. All projects within Automotive-grade Linux are hosted in Git. The Garrett is used for managing and reviewing code. We have Jenkins for continuous integration and furthermore testing some of the changes automatically. There is a Jira where you can file issues by reporting bugs or requesting new features. There is a wiki article and there is a new documentation site where you can find docs how to get started with the exact steps. So with this, the short overview of AGL is over and now I'll move to something more practical. And it's the experiment how to build a remote control robot. So in order to do this, and we're speaking about a hobby project that any one of you can do during the weekends, that's what I did actually. So we're speaking about low-cost hardware that you can buy easily. You need a single board computer. Obviously this has to be a single board computer from the list of hardware devices that we mentioned because we already know that AGL works on them. You need a chassis and a DC motor. If you're good with 3D printing, you can construct your own chassis. Maybe if you want, you can buy some of the existing robot chassis that you can find around the internet or in eBay. You need a motor driver to drive the DC motors, a few sensors to make things more interesting. And of course, you need batteries to run all these. So those of you who know me before the talk know my choice. I'm a Raspberry Pi fan, especially when we're speaking about hobby projects. So for this experiment, I decided to rely on Raspberry Pi 3. I believe all of you know Raspberry Pi pretty well. It's very affordable. A lot of people have it. It has a good software support in general, as well as an automotive grade Linux. There are a variety of atom boards that you can easily plug on the Raspberry Pi in order to build a robot or another hobby project. And there is a huge community. One important remark. This is not an automotive grade board, so it doesn't cover certain requirements. And it's good for hobby projects. And keep in mind that this experiment is in this category. The good thing about Raspberry Pi, actually, how many of you have Raspberry Pi? OK, all of you. That's perfect. I hope you understand my choice. So a lot of people are building remote-controlled robots with Raspberry Pi. It's a nice toy. Even a child can build it. And there are a lot of motor controller atom boards that you can just buy, plug on top of the 40 pins of the Raspberry Pi and get fixed working. I have listed some of the popular atom boards that you can buy. Here you see the exact controller that they're using. As you can see, I have nailed down just a few of them. I decided not to use the one that I can buy, but actually to make my own. Do it yourself. Motor driver board. This took me a bit of time. I'm not very good at soldering, as you can see. I had a look at the few popular half-H motor drivers that I already saw that are being used by other boards, such as the ones that I showed on the previous slide. I decided to select one from Texas Instruments. That is the easiest one for soldering, this one over here. This is how it looks. As I said, I'm a software engineer, not very good with soldering, as you can see. But it works. It controls two DC motors. You need an external battery pack to power this thing and to make it run. Now, controlling the motors, the problem with Raspberry Pi is that we don't have enough hardware PVM. There is just the single one of them, and this is kind of problematic because if you want to have a good control of the motors, you need to rely on hardware PVM. Alternatively, we can emulate with software the PVM, but the results are not that good. They're good enough for making a simple demo. But if we want to go one step further to make it more interesting, it's better to pick up a microcontroller with PVM and to have a hardware control over the PVM. There is a popular open source library called Wiring Pi, which is very convenient for integration with CNC++ projects. And it can emulate PVM from the software side. So these are super cheap, dirt cheap motors with wheels. You can buy them from eBay for one or two US dollars. That's absolutely nothing. Of course, you need to wait for quite some time for their arrival. But if you find them in a local store, just get them. They're really useful for making these hobby projects. So my idea for the robot is to have just three wheels, two of them to control, and one additional wheel. And this is a very simple code box just to show how simply with Wiring Pi, I can enable the software emulation of the PVM and to make these motors move forward or backward. So let's have a look at the sensors. When you're building a hobby robot, there are a bunch of sensors that you can use. Probably the most popular that I have seen in a lot of projects, almost all projects, is the ultrasonic sensor for measuring distance towards objects. This is a cheap and effective sensor that allows you to measure the distance to walls, for example, or other obstacles and to make a simple algorithm to move around them. A lot of fun thing is that actually I haven't done this yet on my robot, but it's infrared line tracking. So basically the idea there is with this sensor, you can distinguish, for example, a black line, and your robot can follow the line. So it's a path-following robot. Other cool sensors are like the compass that you can find as an I2C sensors. There are other I2C sensors for measuring temperature, humidity, colors, lights, so you can even distinguish the ambient light. Furthermore, Raspberry Pi has official Raspberry Pi camera coming from the Raspberry Pi Foundation, which you can also integrate within the robot. The integration is pretty simple because there is a board support package layer called Meta Raspberry Pi. It's for the Yocto project in general, as well as to other Linux distributions such as Automotive Grade Linux, which are based on the Yocto project and Open Embedded. Since we're building a robot that has to be remotely controlled, we have to think about the communication. And in terms of communication, Raspberry Pi has built-in Wi-Fi, Ethernet, and Bluetooth. It's very easy to extend the capabilities of Raspberry Pi by adding radio transmission modules or infrared receiver and or transmitter. In our case, it's enough to add a receiver. And of course, we can buy some GSM modules and even control the robot this way, because Ofono is built-in in Automotive Grade Linux. This is an example of how you can add to your DIY board, actually. This is what I did. To add an infrared receiver, these are schematics that I took from another project that I'm having. It's a very popular infrared receiver, which can be easily integrated on AtomBoards for Raspberry Pi and receive commands using the Linux infrared remote control project, known as LIRC. It's a 20-year-old project that works perfectly fine on Linux. So putting all this together on a Raspberry Pi, on top of Raspberry Pi, requires making a DIY board. I'm currently working on it. I already have the prototype soldered on a breadboard prototyping. The next step would be to design this board on a kick-hat. This is my setup. I'm using these pins, general-purpose input-output pins, for attaching the DC motors. I need four pins for this. With wiring Pi, as explained in the previous slide, I'm emulating the PBM. The infrared is attached over here. This is actually the only hardware PBM pin that I have on the Raspberry Pi. I also keep the UART for easier debugging of the board and, of course, I2C sensors for attaching the sensor that I've explained on the previous slides. So, getting back to the software side of things, here is how we built Automotive Grade Linux. It's a very straightforward process. It's very easy to do it. You just have to follow the exact steps, which are explained actually in two places. One of the places is the AGL Wiki. The second one is the official documentation. So, the process has three major steps. First, you have to get the source code. As you can see from the commands over here, AGL is using the Google repo tool to keep together all the layers for building the distribution. If you want to use a specific version of Automotive Grade Linux, this is where you have to specify this version. In general, the way I have written it here, I'm going to use the AGL master. This is the current branch of AGL that is being in-developed. So, this is the cutting edge. If you want to rely on something more stable, because, you know, when we are using the master branch, there is a development going on, so something might not work as expected. But if you want to use something stable, make sure that you are using the latest version of AGL, for example, DarlingDap, as of the moment. After that, we have to set up the build environment. And here comes the interesting part, because with these magical words here, we can activate or deactivate certain features available in Automotive Grade Linux. For my remote control robot, I don't plan to add a display, and since there is no display on it, I really don't need the whole graphical stack. So, what I'm building here is the very, very simple, the very basic Automotive Grade image, which is convenient for headless devices, as the one that I'm building right now. One more thing to say, you need a Linux machine to run these procedures, or it's possible to do it in a virtual machine as well, but it will take quite a lot of time. The build of this Linux distribution will take some time, so please be passionate, grab a cup of coffee while you're waiting. Let's have a look at the three most commonly used Automotive Grade Linux images. The first one is the one that I'm actually using for this project, AGO Image Minimum, the bare minimum of Automotive Grade Linux. The other one is IVI, IVI stands for Inviso Infotainment. And finally, we have the AGO Demo Platform. The AGO Demo Platform is the image that provides the whole demo UI, shipping with Automotive Grade Linux as of today. You have a bunch of demo applications, a home screen with a bunch of demo applications. All these demo applications as of today are written in Qt. They're running on top of Wayland and Weston, and Weston is relying on IVI Shell to render. So how to customize the image? The way to customize it is actually straightforward. If you're familiar with the Yocto project and open embedded, you already know how to do it. There are two key files that you would like to edit while you're still working on the product. The first one is called BB Layers. It contains the list of the Yocto layers within the distribution. The second one is called conf.local.conf, where you can customize what exactly to get into the image. And in this example over here, I'm adding Lyric. This is the software that I need to scan and control the robot through infrared. Keep in mind that Lyric is provided by MetaOpen Embedded Layer, and this layer is already available in Automotive Grade Linux. Therefore, I have not described it in BB Layers because it already exists. For example, if you're working on another project that requires another software, which is provided by a layer that doesn't exist in Automotive Grade Linux as of today, you need to describe the layer in BB Layers. This is a quick and dirty way to add new packages really quickly, but if you want to build a new distribution based on Automotive Grade Linux, a new product, the better way is to do the full integration, to do your own Yocto recipes, and finally to have your image based on top of AGO. This is how you're customizing the image just quickly during development. So I would like to spend just a few slides for speaking about how to contribute to AGO upstream. So the first step, if you want to add a new project or a new feature within Automotive Grade Linux, is to report an issue in JIRA. You need an account for Linux Foundation to log in into the JIRA. It's super easy to create one. You can request a new feature, report a bug that you have experienced, and once you have this listed, the next step is you or someone else to modify the source code of AGO and to contribute it to Garrett. It's not mandatory, but it's nice to include the JIRA ID within the git commit message that will appear in Garrett. This is easier. This is a good option to continue tracking the progress of this bug within Garrett and the git commits. Have you used Garrett? How many of you are familiar with it? Okay, I would rather say half of the people around here. So Garrett is an open source web-based team called Cooperation2. First of all, it's for a number of git repositories. It's written in Java. It's available under open source license, Apache license, actually. So here is how you can create this account and get started with Garrett and JIRA actually in AGO. Here is the workflow of Garrett. So we have one major repository. For example, here we have AGO repo. This is the repository that holds the manifests for the Google repo tool that keeps all the layers needed to build automotive grade Linux. So if we want to make a change, for example, to bump the version of a certain layer, to add a new layer or to remove a layer, we have to pull this into a developer repo on our local machine. After that, we have to make some changes and to push them back to Garrett. Garrett is going to create a repository where the changes are pending for a review. There are three types of roles within Garrett. One are the developers, the people doing the push and pull from Garrett from the official Garrett repository to the one that's pending in the reviews. The second role are the reviewers. They can be again developers. They have to fetch, test your changes and give their opinion. They can vote with plus or minus. If you have enough positive votes, the maintainer, the third role, should merge your change within the official repository by doing a submit. All right. So you're welcome to Automotive Grade Linux at any time. We have a mailing list. I highly encourage you to subscribe. We have a weekly developer call that Walt is doing every Tuesday. And we have an IRC channel. We're at the end of the presentation, so I would like to do a few conclusions. So according to my experience, open source is compressing the development cycle for a faster route to the market. And I think this is a great benefit for the whole ecosystem because this way you can make your products faster and provide them with better quality because open source means that more and more people are looking into the source code and are putting efforts to get it better. AGL is based on top of already proven open source software technologies. We mentioned them during the presentation, like the Yocto project, Open Embedded, Wayland, Weston and Qtan and so on. I won't list them all now. So AGL is entirely open source project so don't hesitate to contribute to it. It offers an open source software stack which can be useful not only for the automotive industry but for certain cases if you're doing Internet of Things. I hope that my experiment with this simple remote control robot proves that it's possible to do it. You have already seen how to do integration within AGL if you're developing another project on top of it. So what's next? In terms of my own hobby project for the robot, I need to do a better board that is designed in KeyCat, a two-layer board on which I'll put all the components as I explained them in the previous slide to get it more professionally working. In terms of AGL, the next steps are releasing a stable final version of Electric EO. This is going to be the next release of AGL and this has to happen by the end of this year and hopefully to have nice presentations for the consumers electronic show next year. Starting as of January 2018, we should start developing the next release of AGL which is called Funky Founders. This is the name of a fish. The cold names of AGL are actually names of fishes. We have to say big thanks to Walt, who found in alphabetical order names of all those fishes. So the sixth release of AGL is Funky Founders. Thank you very much for joining this presentation. We have five or six minutes for doing some Q&A session and I have listed here a few interesting links. So thanks and any questions? The robot. Well, the problem is that I still don't have the whole robot built and I don't bring it over here, but as soon as I design the board within Keycat, I'll show it as a whole robot and hopefully it will be working better at the moment because it was not in that good shape and I left it at home. Okay, so if I hear well the question, is there any specific advantages of using automotive grade Linux for hobby projects such as this one instead of using Raspbian? Yeah, okay. So yes, for hobby projects you can also use Raspbian. The process is similar. The advantage of using automotive grade Linux is more for projects that are also targeting some long-term relationship and even going to the market because Raspbian is a Debian-based distribution with desktop. When you do a headless device like this robot, you don't actually need the whole graphical user interface like X11 that is shipped within Debian. While automotive grade Linux with a headless profile can be more flexible for the needs of a project that doesn't require a display, for example. If you want to do another device with graphical user interface similar to what we have in the cars, automotive grade Linux can also be useful for that. Yes, over there? Sorry, could you please repeat it a little bit louder? Okay, so the question is how large is the system image of automotive grade Linux? I'm not exactly sure in terms of megabytes how large is this. Well, do you know exactly how big is it? Yes, I also don't remember, but I believe it's below... The final image should be around 200 megabytes, but take my words with a pinch of salt. I'm not exactly sure about the size. You can optimize it if you're searching for a smaller size. Just for a reference that you can build a pocky image that is like 30 megabytes or something like that. Yes? Okay, so the question is what is the boot time of AGL on Raspberry Pi 3? I also don't have the exact number in seconds. It depends on the profile. The AGL minimal image boots pretty fast. With the graphical user interface it could take, for example, like 10 seconds or something like that. It depends on how fast and which Qt applications will be loaded as part of the demo image. Okay, one question over there. Okay, so the question is, I'll just repeat it. The question is regarding the licensing of Qt within automotive grade Linux, and more specifically, are the applications written with open source license, or if a proprietary license is required? Did I get it correct? Okay, so the applications that we have as of today within the demo version of automotive grade Linux are under the open source license of Qt. If you require to use a proprietary Qt applications and to ship them in AGL, you have to do it as part of your own layer because AGL is open source distribution, and if you want to contribute something to the upstream, it has to be under an open source license. Okay, any other questions? Okay, thank you very much for joining.