96Boards

96boards: Autoware everywhere | Updating Autoware.Auto 3D Perception Stack modules

Wed, 31 Mar 2021 01:00:00 +0000

Introduction

After the last post of this blog series we now have a very nicely distributed and scalable 3D Perception demo for Autoware.Auto.

In this blog post we will cover the last piece of the puzzle: how do we go about updating the k8s pods? Thanks to the k8s infrastructure the process to update or roll back images can be easily achieved. As we did in the previous post we will run the 3D Perception demo using a combination of AutoCore’s PCU and Qualcomm® Robotics (RB3) Dragonboard-845c Development Platform.

This post is organized as follows:

Introduction
Setting up the 3D Perception demo
k8s rolling update
Visualization
Conclusion

Setting up the 3D Perception demo

To avoid uncessary repetition and as we just need to set the k8s cluster and the 3D Perception demo in the same way as before, please check the previous post to follow the step by step process outlined there. As a brief summary we need to:

Bring up the k8s cluster.
- Kick-off the master on the laptop.
- Join PCU and RB3 to the cluster as workers, default names for the nodes are localhost and linaro-alip respectively.
Apply the k8s deployment yaml files that are hosted here.

We are now in a situation like the one shown below.

k8s rolling update

As mentioned above it is quite straighforward to perform an update of the running image in one of our k8s deployments. To illustrate the process we will perform an update on the sensing-rear-lidar deployment.

For the purpose of this blog post we have added 2 new images to the 96Boards Dockerhub repo namely sensing-1.0.0_v2 and sensing-1.0.0_bad. These images are just a retag of the sensing-1.0.0 and udpreplay images respectively, so the _v2 image contains the Velodyne driver nodes and the _bad image will lead to an error during the update as the Velodyne driver node is not available.

The first thing we need is to identify the name of the pod container within the deployment that we want to update. The sensing-rear-lidar is a single pod deployment and using the kubectl describe command we can find the name of the pod container as shown below.

We can see that the pod name is sensing-rear-lidar-5f78dd8f44-nmb9d and that the pod container name is rear-lidar-pod. To update the image from sensing-1.0.0 to sensing-1.0.0_v2 we just need to do:

$ kubectl set image deployment sensing-rear-lidar rear-lidar-pod=96boards/autoware.auto:sensing-1.0.0_v2 

and we can check the progress of the rollout as:

$ kubectl rollout status deployment sensing-rear-lidar

After the rollout is completed we can check that the new pod (named sensing-rear-lidar-799fddb689-jcc2m) is using the new image by using the kubectl describe command.

We can then check that all the pods are running.

Now we can go back on the rolled update by simply doing:

$ kubectl rollout undo deployment sensing-rear-lidar

We can see that the new pod with the old image is sensing-rear-lidar-5f78dd8f44-bt5q2. Now let’s try rolling an update with the sensing-1.0.0_bad image which will fail upon running as the Velodyne driver is not available.

As shown above the kubectl rollout status command gets stuck and also k8s keeps the older pod with the sensing-1.0.0 image running as the new one is stuck in a Error state. Upon finding this situation we can simply roll back the update to keep the previous pod that was running apropriately.

Visualization

Now that we know how to roll an update for an image let’s see what happens when we visualize the lidar pointcloud. Since the default config for the 3D Perception shows the front lidar data we will roll the update to this pod’s container. To do so we just need to do as above:

$ kubectl set image deployment sensing-front-lidar front-lidar-pod=96boards/autoware.auto:sensing-1.0.0_v2 

And as shown below we can see that upon successful completion of the update we keep getting a nice feed of the pointcloud in Rviz2.

Conclusion

In this post we have added the missing piece for our k8s deployment management capabilities: being able to roll image updates when needed, as well as exploring the way to take the update back in case the new image fails for whatever reason. With this blog post we complete our exploration on scalability of Autoware.Auto using k8s where we have shown how easy it is to deploy and manage the different software modules on multiple boards.

96boards: Autoware everywhere | Multi-board Autoware.Auto 3D Perception Stack using k8s

Fri, 19 Mar 2021 01:00:00 +0000

Introduction

Following our previous work to show how to distribute Autoware.Auto’s modules to complete the 3D Perception demo it comes as a natural question to ask about the benefits of using k8s as opposed to plain Docker or the ade-cli tool that is used within the Autoware.Auto official documentation to deploy the software.

Well, if you have been following the blog series we showed how to reproduce the 3D perception demo on a Hikey970 using plain docker, which is very similar to the ade-based steps in the documentation, where the level of manual involvement was quite high with multiple terminals to ssh into the board, launch nodes, etc. While it is true that we could put together a ROS2 launch file to kick-off all the nodes, we would still need to start the containers manually prior to using the launch file.

On the other hand, if we go down the k8s route, we still need to ssh into the board to add it to the k8s cluster but once that’s done everything is managed through the master node which provides an easier way to deploy and manage the different components as services within the vehicle. These benefits come closer into play for “stable” software, hence both ways (k8s vs docker/ade) live together as they are meant to target different use cases, development vs closer to production.

In addition, using the k8s infrastructure helps us keep the services running by means of re-spawning if a services dies or while performing an update to a particular module (which we will explore in the near future). Furthermore, while the above is considered for a single board, when we take scalability into account we can introduce redundancies using a k8s cluster with multiple boards or specify nodes attending to board capabilities or interfaces, for example if we had a LIDAR plugged into a k8s node to perform some preprocessing on the data before feeding into the rest of the system so we could use multiple less capable hardware as opposed to a single higher end approach.

All these can be easily achieved thanks to the Eclipse Cyclone DDS middleware for ROS2 as the masterless discovery capabilities mean that we do not need to manually set up the different IP addresses for all the individual containers within each k8s pod.

In this blog we look at this last point. As a proof of concept instead of running the 3D Perception demo modules just on the PCU we will assume that the LIDAR data comes into a separate board (Qualcomm® Robotics (RB3) Dragonboard-845c Development Platform), where the LIDAR drivers are run, with the 3D pointcloud data in ROS2 topics being fed next into the PCU for rest of modules.

This post is organized as follows:

Introduction
Setting up the RB3
k8s cluster bring up
Assigning deployments to specific nodes
Visualization
Conclusion

Setting up the RB3

To set up the RB3 board we just need to follow the steps here and then install Docker as we showed in the past.

We can then follow the default steps to install k8s as we did for the PCU.

NOTE we need to create the following symlink for kubelet to run nicely with its default settings.

$ ln -s /run/resolvconf /run/systemd/resolve

k8s cluster bring up

Now that both boards are ready we just need to create the k8s cluster as usual:

Kicking off the master node in the laptop first.
Then joining the PCU and RB3 as worker nodes.
Upon completion we can verify that the 3 nodes are up and running. RB3 named as linaro-alip and PCU as localhost.

Assigning deployments to specific nodes

As a recap for the 3D Perception demo we created 3 different deployment files and associated Docker images:

udpreplay: replays the Velodyne pcap data.
sensing: 2-pod deployment for the front and rear Velodyne driver nodes.
perception3d: multi-pod deployment for the robot state publisher, point cloud filter transform, ray ground classifier and euclidean cluster nodes.

Since we will run the LIDAR drivers on the RB3 we will assing the udpreplay and sensing deployments to that node and the perception3d to the PCU. To do this we just need to modify the deployment files we had and add the keyword nodeName and the associated node name to each file as shown below.

Once modified we can just create the deployments as usual, which leads to each deployment being created in the right node.

For convenience the modified yaml files can be found here and can be applied directly as:

$ kubectl apply -f https://people.linaro.org/~servando.german.serrano/pcu/k8s/autoware.auto-3dperception-demo/multi_board/udpreplay.yaml $ kubectl apply -f https://people.linaro.org/~servando.german.serrano/pcu/k8s/autoware.auto-3dperception-demo/multi_board/sensing.yaml $ kubectl apply -f https://people.linaro.org/~servando.german.serrano/pcu/k8s/autoware.auto-3dperception-demo/multi_board/perception3D-demo.yaml 

Visualization

Finally we can check that the system is working by using the laptop for visualization purposes as we did before.

Conclusion

In this post we taken the 3D Perception demo further by combining the PCU with the RB3 in a k8s cluster. We have also seen that it is quite straighforward to deploy different Autoware.Auto modules in multiple boards by using the k8s infrastructure as opposed to manually doing the same. We will continue exploring what we can do with k8s in the near future so keep an eye to this space.

96boards: Autoware everywhere | Autoware.Auto 3D Perception Stack using k8s on PCU

Mon, 08 Mar 2021 01:00:00 +0000

Introduction

In our previous blog post we showed how to we can use Kubernetes (k8s) to create different deployments to replay and echo a rosbag2 data file. Though it was an interesting first step it falls far from being close to what an actual deployment on a vehicle would be.

In this blog post we take the setup further and use the Autoware.Auto software stack to reproduce the 3D perception demo using k8s.

This post is organized as follows:

Introduction
Autoware.Auto
PCU setup
k8s setup
Running the k8s pods
Conclusion

Autoware.Auto

As we have covered in earlier posts, Autoware.Auto is the next generation successor of the Autoware.AI project through a complete rewrite of the different modules using ROS2 and improved methodology.

Following a succesful Autonomous Valet Parking demo, code and documentation cleanup, Autoware.Auto 1.0.0 has been released. We are using this release in this post.

PCU setup

The first thing we need to do is install k8s in the PCU and laptop. To do so we have first flashed the PCU with Autocore’s provided image as we explained in this post. We have used the latest release from AutoCore which, at the time of writing, is 20201214 Release Package.

After getting the PCU SD card ready we can boot the board, ssh into it and install k8s as we did before here.

Note We need to enable iptable forwarding rules on the PCU for the pods to communicate with each other, we can do so as:

$ iptables -P FORWARD ACCEPT

k8s setup

As we mentioned above the main idea behind the k8s configuration is to split the Autoware.Auto software components into different deployments so they can be managed independently and run as individual services across the k8s cluster. In this demo we will be using 3 deployments:

udpreplay: replays the Velodyne pcap data.
sensing: 2-pod deployment for the front and rear Velodyne driver nodes.
perception3d: multi-pod deployment for the robot state publisher, point cloud filter transform, ray ground classifier and euclidean cluster nodes.

Furthermore, we would expect that each deployment would use a docker image tailored to its needs rather than a more general one, so, instead of building the full Autoware.Auto we have put together 3 Docker images with the needed nodes for each deployment. These images can be found in the 96boards/autoware.auto dockerhub repo.

Taking this into account we are now ready to create the k8s cluster and the 3 deployments. In addition, as we did in the previous post we will be using Rviz2 on the laptop for visualization purposes.

Running the k8s pods

We are now ready to get things running on k8s, for the fully detailed steps please check our first post about k8s. As a recap, we need to:

Kick off the master node in the laptop.
Join the PCU as a worker node.
Enable the Flannel CNI add-on and copy the Flannel environment variables to the PCU.

We can check that the worker node on the PCU has joined the cluster by running kubectl get nodes on the laptop as shown below.

Now that our k8s cluster is up and running we just need to create our deployments. The yaml files are available here.

$ kubectl apply -f https://people.linaro.org/~servando.german.serrano/pcu/k8s/autoware.auto-3dperception-demo/udpreplay.yaml $ kubectl apply -f https://people.linaro.org/~servando.german.serrano/pcu/k8s/autoware.auto-3dperception-demo/sensing.yaml $ kubectl apply -f https://people.linaro.org/~servando.german.serrano/pcu/k8s/autoware.auto-3dperception-demo/perception3D-demo.yaml 

And the Rviz2 visualization on the laptop.

Conclusion

In this post we have explored a bit further on splitting some Autoware.Auto modules using k8s. In addition we have used different Docker images for each deployment as it’ll make it easier to update them when the time comes since they are lighter than a fully-built Autoware.Auto image. We will continue exploring what we can do with k8s in the near future so keep an eye to this space.

96boards: Autoware everywhere | K8s-based Autoware deployment on PCU

Fri, 26 Feb 2021 01:00:00 +0000

Introduction

In our previous blog post we showed how to setup a Kubernetes (k8s) cluster using a laptop as the master node and Autocore’s PCU as the worker node to deploy the different k8s pods. To test the setup we run a minimal deployment using the ddsperf tool that is available as part of Cyclone DDS.

In this first exploration we are going to create 2 k8s single-pod deployments on the PCU:

One that will read a rosbag data file. This data file has been recorded by TierIV using the new architecture implementation.
The other will echo the /sensing/imu/imu_data topic that is being published by the other pod.

In addition we are going to kick off Rviz2 and the rqt-image-view packages from ROS2 in the laptop to visualize the data. For this demo we are setting the pods to use the hostNetwork as both k8s nodes are in the same local network.

This post is organized as follows:

Introduction
New Autoware Architecture Proposal
PCU setup
Running the k8s pods
Conclusion

New Autoware Architecture Proposal

To improve the development of Autoware capabilities TierIV has developed a new Architecture. This architecture provides a layered approach to the different software stack components and definition of the interfaces between modules. We will use the ros2 v0.5.0 tag of the Pilot.Auto software stack which is built using the new architecture as reference.

PCU setup

After getting the PCU SD card ready we can boot the board, ssh into it and install k8s as we did before here.

Note We need to enable iptable forwarding rules on the PCU for the pods to communicate with each other, we can do so as:

$ iptables -P FORWARD ACCEPT

Running the k8s pods

We are now ready to get things running on k8s, for the fully detailed steps please check our previous blog. As a recap, we need to:

Kick off the master node in the laptop.
Join the PCU as a worker node.
Enable the Flannel CNI add-on and copy the Flannel environment variables to the PCU.

We can check that the worker node on the PCU has joined the cluster by running kubectl get nodes on the laptop as shown below.

Now to deploy the pods on the PCU node we are going to use the rosbag-echo-pod.yaml k8s deployment file available here. This file starts the 2 deployments we have mentioned earlier, a rosbag replay deployment and another to echo the IMU data. We can start both deployments as:

$ kubectl apply -f https://people.linaro.org/~servando.german.serrano/pcu/k8s/rosbag-echo-pod.yaml 

We can see that both pods are now running and they have been deployed on the PCU node (named localhost). To check that the rostopic pod is receiving data we can get the logs from the pod as:

$ kubectl logs --follow rostopic-echo-59967f6cc5-lpgjm

Now, we can use the laptop to visualize some of the LIDAR data that it’s being replayed in Rviz2.

Conclusion

In this post we have shown how to deploy a couple of k8s pods on the PCU. We can take this initial setup as reference to explore further splitting the different Autoware modules into individual pods that can be managed using k8s.

96boards: Autoware everywhere | Xenomai on PCU

Mon, 08 Feb 2021 01:00:00 +0000

Introduction

Xenomai is a Free Software project in which engineers from a wide background collaborate to build a robust and resource-efficient real-time core for Linux© following the dual kernel approach, for applications with stringent latency requirements.

In this post we explore how we can build Xenomai to use on Autocore’s PCU. We will explore how to enable Xenomai’s 2 options to provide the real-time capabilities on the board.

This post is organized as follows:

Introduction
Xenomai
- Mercury core
- Cobalt co-kernel
Conclusion

Xenomai

As mentioned above Xenomai provides capabilities to support applications with hard real time requirements. It does so either supplementing Linux with a real-time co-kernel running side-by-side with it, the Cobalt co-kernel, or by relying on the real-time capabilities of the native Linux kernel, through the Mercury core.

In this blog post we will show how we can use either of the approaches on AutoCore’s PCU.

Mercury core

The single-kernel approach, through the use of the Mercury core, relies on the real-time capabilities of the antive Linux kernel. This means that we need to provide the Linux kernel with those capabilities through the use of the PREEMPT-RT patch which involves patching the kernel with the right patch version, build it for the PCU, etc.

Getting the PCU image

In our case, and thanks to the work of the AutoCore team, the default image for the PCU already comes pre-patched with PREEMPT-RT, meaning that we just need to download it, flash it to the SD card and get down to building the Xenomai libraries for the Mercury core. To do so we just need to Autocore’s Resource Download site and get the latest image for the PCU. At the time of writing the latest avaialbe image is located in the 20201214 Release Package, it contains (among others):

Ubuntu 20.04 pre-patched with PREEMPT-RT
ROS2 Foxy

Once download we can just flash it on to the SD card and pop it into the PCU. If you need a bit more details to get the PCU up and running, please check our previous blog.

Getting the Xenomai sources

As the Xenomai libraries are lightweight we will build them directly on the PCU. So, after flashing the PCU we just need to boot it and log in using the default user username and password.

As men tioned in the Xenomai build instructions for arm64 architecture we need to get the next branch from the Xenomai repository.

$ git clone https://gitlab.denx.de/Xenomai/xenomai.git -b next

Building for Mercury

To build Xenomai Mercury core we just need to do the following.

$ cd xenomai $ ./scripts/bootstrap $ ./configure --with-core=mercury --enable-smp --enable-pshared $ sudo make install 

Once the libraries are installed we can try the cyclictest to get some results running on the real time kernel as shown below.

$ sudo /usr/xenomai/demo/cyclictest --mlockall --smp --priority=98 --interval=200 --distance=0 -D 20 

We can see that we are getting a maximum latency of 120 microsecs in the worst case. We’ll compare later on with the Cobalt co-kernel output.

Cobalt co-kernel

We will now get the dual kernel configuration up and running on the PCU. The Cobalt co-kernel deals with the time-critical activities and has higher priority over the native Linux kernel processes.

The process of enabling the Cobalt co-kernel is a bit more involved than for the Mercury core but we’ll make it as straighforward as possible. As outlined in the Cobalt core installation instructions we need to:

Prepare the Linux kernel by patching it with I-pipe.
Build the patched kernel and get it on the PCU.
Build the Xenomai libraries for the Cobalt co-kernel.

Getting all sources

We will use NXP flex-builder tool to put together the bootpartition with the patched kernel we need for the PCU. To do so, we’ll follow Autocore’s guide to build a suitable image for the PCU together.

NOTE: Ubuntu 18.04 is needed to use the flex-builder tool.

First of all we need to get all the source code as outlined here.

$ mkdir 1046a $ vcs import 1046a < 1046a.repos

Patch I-pipe on the Linux kernel

Once the sources are downladed we need to get the Xenomai sources and the appropriate I-pipe patch. The default I-pipe patch in the download area fails to apply on the customized kernel v4.14 from Autocore, for convenience a modified I-pipe patch is available here, which is the one used in the next steps.

$ cd 1046a/flexbuild/packages/linux $ git clone https://gitlab.denx.de/Xenomai/xenomai.git -b next $ wget https://people.linaro.org/~servando.german.serrano/pcu/xenomai/ipipe-4.14.78-arm64.patch 

Next we use Xenomai’s shell script to prepare the Linux kernel.

$ cd 1046a/flexbuild/packages/linux/xenomai $ ./scripts/prepare-kernel.sh --linux=/1046a/flexbuild/packages/linux/linux --ipipe=/1046a/flexbuild/packages/linux/ipipe-4.14.78-arm64.patch --arch=arm64 

Building the patched Linux kernel

We are now ready to build the patched kernel for the PCU. As mentioned earlier, we’ll use the flex-builder tool. We will build the patched kernel and bootpartition and replace them in the default PCU image.

$ cd 1046a/flexbuild $ source setup.env $ flex-builder -c linux -a arm64 $ flex-builder -i mkbootpartition -a arm64 

After the kernel and boot partition builds complete we need to flash the SD card with the PCU image from Autocore’s Resource Download site and replace the boot partition with the newly created one.

The boot partition files are located in 1046a/flexbuild/build/images/bootpartition_LS_arm64_lts_4.14 and we just need to copy them over to the boot folder that has been created in the SD card during the PCU flashing process.

Building for Cobalt

Following the steps in the previous section we are now ready to pop the SD card in the PCU, boot it and log in using the default user username and password.

We build the Xenomai Cobalt co-kernel following similar steps as for the Mercury core after logging into the PCU.

$ git clone https://gitlab.denx.de/Xenomai/xenomai.git -b next $ cd xenomai $ ./scripts/bootstrap $ ./configure --with-core=cobalt --enable-smp --enable-pshared $ sudo make install 

Following the installation of the Cobalt co-kernel we can try to boot it to check that everything went fine.

$ dmesg | grep -i xenomai

As we did for the Mercury core we run the cyclictest to get some results running on the real time kernel as shown below.

$ sudo /usr/xenomai/demo/cyclictest --mlockall --smp --priority=98 --interval=200 --distance=0 -D 20 

We can see that using the Cobalt co-kernel we are getting a maximum latency of 20 microsecs in the worst case, which a big reduction compared with the 120 microsecs we were getting with the Mercury core.

Conclusion

In this post we have shown how to build Xenomai to provide the PCU with hard real time capabilities. We have seen that taking the dual kernel approach through the Cobalt co-kernel it is possible to achieve more stringent latencies than those of the Mercury core.

96boards: Autoware everywhere | Running Cyclone DDS on Kubernetes

Fri, 16 Oct 2020 01:00:00 +0000

Introduction

Kubernetes (k8s) is an open-source system for automating deployment, scaling, and management of containerized applications. Kubernetes allows us to easily handle multiple distributed applications that might need to be deployed, managed (scaling up or down) and updated on a regular basis.

In this post we explore how to use k8s to deploy two Cyclone DDS based applications on Autocore’s PCU and whether introducing the k8s infrastructure impacts the performance of Cyclone DDS. In order to do so we will use the ddsperf tool that is available as part of Cyclone DDS.

This post is organized as follows:

Introduction
Conclusion

Testing setup

For the k8s test we will use the PCU and a laptop as follows:

Laptop: used to run the k8s master node
PCU: used to run k8s deployment pods for the Cyclone DDS tasks.

We need to install k8s on laptop and PCU and the steps below are the same for both.

Installing k8s

The first thing we need to do is install k8s in the PCU and laptop. To do so we have first flashed the PCU with Autocore’s provided image as we explained in this post.

After getting the PCU SD card ready we can boot the board and ssh into it.

The following installation steps are the official ones from the k8s documentation to install kubeadm, kubelet and kubectl.

$ sudo apt-get update && sudo apt-get install -y apt-transport-https curl $ curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - $ cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list deb https://apt.kubernetes.io/ kubernetes-xenial main EOF $ sudo apt-get update $ sudo apt-get install -y kubelet kubeadm kubectl $ sudo apt-mark hold kubelet kubeadm kubectl 

Running the performance test

As part of this post we have built a suitable Docker image which contains a compiled Cyclone DDS and a couple of its examples.

Now that the PCU is set up and running with k8s we are ready to run the performance test for Cyclone DDS. To do so we are using the perftest script available in the examples/perfscript folder within the Cyclone DDS source code. This script relies on having ssh connection between the multiple machines that run the ping-pong or sub-pub sides of the performance tests.

To avoid security issues between containers, as we would need to enable a common key pair for the container image to allow the automatic ssh connection without password, we have modified the perftest slightly and split it in 2 pieces which we can run independently for each deployment. The split scripts are available as part of our Docker image and are not meant to replace the original perftest script since the split has not been done in a clean way, i.e. just commenting and deleting what was not needed for the sake of this blog post and test.

Docker containers

Since we are going to assess the impact of the k8s infrastructure in the Cyclone DDS performance we need to first run the test manually using 2 docker containers. We will use 3 terminals where we have ssh’ed into the PCU.

First, we pull the docker image from Docker Hub.

$ docker pull 96boards/pcu:cyclone_k8s

We will use 2 terminals to start 2 containers and the other to create a network and connect the running containers as we show below.

$ docker run -it --rm --env image_args="/bin/bash" --name subCont -p 8001:80 96boards/pcu:cyclone_k8s 

and

$ docker run -it --rm --env image_args="/bin/bash" --name pubCont -p 8002:80 96boards/pcu:cyclone_k8s 

Now that the containers are running we can use the split scripts to run the performance test as:

./../../cyclonedds/examples/perfscript/perftest_sub

and

./../../cyclonedds/examples/perfscript/perftest_pub

We run both scrips at the same time using the Broadcast group option in terminator as can be seen.

After the test is finished the data we need will be in the subCont container named sub-process_pid.log. We can log into the subCont container to check the file name to copy it to our host:

$ docker exec -it subCont /bin/bash

And to copy the log we just need to do:

$ docker cp subCont:/usr/local/sub-process_pid.log .

We will rename the log as raw_containers_test_data.txt to use it later.

$ mv sub-process_pid.log raw_containers_test_data.txt

Using k8s

We are now ready to get things running on k8s. To do so we will first create the master node in the laptop.

Note as k8s currently does not support SWAP enabled we need to disable the check on kubelet when creating the master. To do so we add a KUBELET_EXTRA_ARGS and disable the swap preflight check.

$ sudo sed -i '4a\Environment="KUBELET_EXTRA_ARGS=--fail-swap-on=falses"' /etc/systemd/system/kubelet.service.d/10-kubeadm.conf $ sudo kubeadm init --pod-network-cidr=10.244.0.0/16 --ignore-preflight-errors=Swap 

As we can see above, upon successful start of the master node we will see:

We need to follow the instructions to be able to manage the cluster using kubectl, so:

$ mkdir -p $HOME/.kube $ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config $ sudo chown $(id -u):$(id -g) $HOME/.kube/config 

And we need to copy the kubeadm join ... that we will need to use to ser up a worker node on the PCU. In our case:

kubeadm join 192.168.1.121:6443 --token ijliwh.eic48rh4nq580jpa --discovery-token-ca-cert-hash sha256:c491fda8e914efca3df9a0de87bf9cfe050f3d3d4e6ba0d55a6109a1d28354d5 

We also need to get a CNI add-on that will take care of configuration and cleanup of the pods. We will use the Flannel CNI add-on, which we can deploy just after starting the master node doing:

$ kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml 

Running the kubeadm will throw some preflight errors that for the time being we will ignore. So we can join the PCU as a worker node doing:

$ sudo kubeadm join 192.168.1.121:6443 --token ijliwh.eic48rh4nq580jpa --discovery-token-ca-cert-hash sha256:c491fda8e914efca3df9a0de87bf9cfe050f3d3d4e6ba0d55a6109a1d28354d5 --ignore-preflight-errors=all 

We can check that the worker node on the PCU has joined the cluster by running kubectl get nodes on the laptop as shown below.

And we need to copy the flannel environment variables to the PCU by doing:

On laptop:

$ sudo cp /run/flannel/subnet.env . $ scp subnet.env user@192.168.1.100:~

On PCU:

$ sudo cp subnet.env /run/flannel/subnet.env

We are now ready to deploy our k8s pods to run the cyclonedds pertest. On the laptop, we download the k8s deployments manifest files as:

$ wget https://people.linaro.org/~servando.german.serrano/pcu/k8s/cyclone-perftest-sub.yaml $ wget https://people.linaro.org/~servando.german.serrano/pcu/k8s/cyclone-perftest-pub.yaml 

And deploy them using kubectl on 2 terminals at the same time doing:

$ kubectl apply -f cyclone-perftest-sub.yaml

and

$ kubectl apply -f cyclone-perftest-pub.yaml

and check that the pods are created.

We can check that the test is running by using the kubectl logs command as shown below.

We can log into the running pod using kubectl exec to find out the process pid to be able to copy the log after the test finishes by doing:

$ kubectl exec --stdin --tty cyclone-perftest-sub-55bf66b5fc-wv5rb -- /bin/bash

And that’s it for running the performance test, we just need to wait now for the test to be finished and we can copy the sub-process_pid.log file from the cyclone-perftest-sub-... pod as:

$ kubectl cp cyclone-perftest-sub-55bf66b5fc-wv5rb:/usr/local/sub-process_pid.log ./raw_k8s_test_data.txt 

Performance comparison

Following the completion of both approaches for the performance testing we can now plot both sets of results together to compare them.

We need first to preprocess the subcriber logs. To do so we use the throughput-test-extract script from the perfscript folder of the Cyclone DDS source code.

$ wget https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/master/examples/perfscript/throughput-test-extract $ sudo chmod +x throughput-test-extract $ ./throughput-test-extract raw_containers_test_data.txt > containers_test_data.txt $ ./throughput-test-extract raw_k8s_test_data.txt > k8s_test_data.txt 

To plot the data from both tests in the same figure we rename the k8s test data file to k8s_test_data.txt and the one using Docker containers manually to containers_test_data.txt. A simple python script can be downloaded into the folder containing the data files and executed to get a figure like the one below:

$ wget https://people.linaro.org/~servando.german.serrano/pcu/k8s/dds_data_plot.py $ python dds_data_plot.py 

The above figure shows that the k8s infrastructure does not impact the outcome of running Cyclone DDS performance test. Taking this result into account we are now ready to consider the deployment of Cyclone DDS based applications using k8s to manage the different containers we might need across a range of boards.

Conclusion

In this post we have shown how to deploy Cyclone DDS based applications on Autocore’s PCU using k8s to manage the infrastructure and whether the k8s infrastructure impacted the performance of Cyclone DDS.

Taking this initial setup as reference we are now ready to take it further with other configurations, such as increasing the number of applications (e.g. Autoware packages) or the amount of worker nodes using a wider range of 96Boards.

96boards: Autoware everywhere | meta-arm-autonomy in AutoCore's PCU

Fri, 07 Aug 2020 01:00:00 +0000

Introduction

In our previous post of the “96boards: Autoware everywhere” blog series we introduced AutoCore’s PCU as the first heterogeneous hardware platform of the Autoware.IO project.

In this post we will show how to set up the arm-autonomy software stack to be used on the PCU.

This post is organized as follows:

Introduction
Conclusion

arm-autonomy Yocto layer

The arm-autonomy layer is part of the meta-arm Yocto repository. As stated in the documentation, the arm-autonomy layer provides an hypervisor based solution (currently based on Xen) for autonomous system. It contains recipes and classes to build host and guest systems.

We will outline how to build the host and guest images, how to setup the micro SD card for the PCU and the way to boot the system and log into the domU.

Yocto Images build

The arm-autonomy documentation provides instructions on how to build the host and guest images. We will start with the guest image in order to get it automatically built in the host image in the next step.

Getting the sources

First we need to get the sources for our Yocto images, we can use the repo tool. To install it, please do:

$ mkdir ~/bin $ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ PATH=${PATH}:~/bin 

Then we can get the repos as:

$ mkdir ~/arm_auto_pcu && cd ~/arm_auto_pcu $ repo init -u https://git.linaro.org/people/servando.german.serrano/pcu_arm_auto.git/ -b dunfell $ repo sync 

We are now ready to start building the guest and host images.

Patching the sources

To get arm-autonomy to run on our PCU we need to introduce a couple of patches into the downloaded sources.

$ cd ~/arm_auto_pcu/sources/meta-virtualization/recipes-extended/xen/files $ wget https://people.linaro.org/~servando.german.serrano/pcu/patches/0002-temp-hack-for-IRQ-Share.patch 

And add the patch to ~/arm_auto_pcu/sources/meta-virtualization/recipes-extended/xen/xen_git.bb to SRC_URI:

SRC_URI = "git://xenbits.xen.org/xen.git;branch=${XEN_BRANCH} \ file://0002-temp-hack-for-IRQ-Share.patch \ " 

Guest image

We will start creating the guest image so we can add it automatically to the host image at build time.

$ cd ~/arm_auto_pcu $ source sources/poky/oe-init-build-env guest_prj

Now we need to modify the bblayers.conf and local.conf files.

We need to add the needed layers to the guest project bblayers.conf file, so it will look as shown below:

# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf # changes incompatibly POKY_BBLAYERS_CONF_VERSION = "2" BBPATH = "${TOPDIR}" BBFILES ?= "" BBLAYERS ?= " \ /home/linaro/arm_autonomy/pcu_yocto/sources/poky/meta \ /home/linaro/arm_autonomy/pcu_yocto/sources/poky/meta-poky \ /home/linaro/arm_autonomy/pcu_yocto/sources/poky/meta-yocto-bsp \ /home/linaro/arm_autonomy/pcu_yocto/sources/meta-openembedded/meta-oe \ /home/linaro/arm_autonomy/pcu_yocto/sources/meta-openembedded/meta-python \ /home/linaro/arm_autonomy/pcu_yocto/sources/meta-openembedded/meta-filesystems \ /home/linaro/arm_autonomy/pcu_yocto/sources/meta-openembedded/meta-networking \ /home/linaro/arm_autonomy/pcu_yocto/sources/meta-virtualization \ /home/linaro/arm_autonomy/pcu_yocto/sources/meta-arm/meta-arm-autonomy \ " 

and we add the following to the local.conf file:

MACHINE ??= "arm64-autonomy-guest" DISTRO_FEATURES += "arm-autonomy-guest" BB_NUMBER_THREADS ?= "6" PARALLEL_MAKE ?= "-j 6" DISTRO ?= "poky" PACKAGE_CLASSES ?= "package_rpm" EXTRA_IMAGE_FEATURES ?= "debug-tweaks" USER_CLASSES ?= "buildstats image-mklibs image-prelink" PATCHRESOLVE = "noop" BB_DISKMON_DIRS ??= "\ STOPTASKS,${TMPDIR},1G,100K \ STOPTASKS,${DL_DIR},1G,100K \ STOPTASKS,${SSTATE_DIR},1G,100K \ STOPTASKS,/tmp,100M,100K \ ABORT,${TMPDIR},100M,1K \ ABORT,${DL_DIR},100M,1K \ ABORT,${SSTATE_DIR},100M,1K \ ABORT,/tmp,10M,1K" CONF_VERSION = "1" IMAGE_INSTALL_append = " git bash sudo" XENGUEST_IMAGE_AUTOBOOT = "0" XENGUEST_IMAGE_NETWORK_BRIDGE = "0" INITRAMFS_IMAGE_BUNDLE = "1" INITRAMFS_IMAGE = "core-image-minimal" IMAGE_FSTYPES += "cpio" 

Following that we build a minimal guest image as:

$ bitbake core-image-minimal

Host image

Once we have the guest image built we can create the host project as follows:

$ cd ~/arm_auto_pcu $ source sources/poky/oe-init-build-env host_prj

Now we need to modify the bblayers.conf and local.conf files. Your local.conf file will look as:

MACHINE ??= "ls1046afrwy" DISTRO_FEATURES += "arm-autonomy-host" BB_NUMBER_THREADS ?= "6" PARALLEL_MAKE ?= "-j 6" ARM_AUTONOMY_HOST_IMAGE_EXTERN_GUESTS = "/home/linaro/arm_autonomy/pcu_yocto/guest_prj/tmp/deploy/images/arm64-autonomy-guest/Image-initramfs-arm64-autonomy-guest.xenguest;guestname=myguest" XENGUEST_MANAGER_VOLUME_DEVICE = "/dev/mmcblk0p4" XEN_DEVICETREE_DOM0_MEM = "2048M" XEN_DEVICETREE_DOM0_SIZE = "0x03000000" XEN_DEVICETREE_DOM0_BOOTARGS = "console=hvc0 earlycon=xen root=/dev/mmcblk0p3 rw rootwait" DISTRO ?= "poky" PACKAGE_CLASSES ?= "package_rpm" EXTRA_IMAGE_FEATURES ?= "debug-tweaks" USER_CLASSES ?= "buildstats image-mklibs image-prelink" PATCHRESOLVE = "noop" BB_DISKMON_DIRS ??= "\ STOPTASKS,${TMPDIR},1G,100K \ STOPTASKS,${DL_DIR},1G,100K \ STOPTASKS,${SSTATE_DIR},1G,100K \ STOPTASKS,/tmp,100M,100K \ ABORT,${TMPDIR},100M,1K \ ABORT,${DL_DIR},100M,1K \ ABORT,${SSTATE_DIR},100M,1K \ ABORT,/tmp,10M,1K" PACKAGECONFIG_append_pn-qemu-system-native = " sdl" CONF_VERSION = "1" DL_DIR = "/home/linaro/arm_autonomy/pcu_yocto/downloads" SSTATE_DIR = "/home/linaro/arm_autonomy/pcu_yocto/sstate-cache" INHERIT += "own-mirrors" SOURCE_MIRROR_URL ?= "http://git.freescale.com/source/" ACCEPT_FSL_EULA = "1" IMAGE_INSTALL_append = " git bash sudo" 

and we need to add the following layer to the bblayers.conf file:

# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf # changes incompatibly POKY_BBLAYERS_CONF_VERSION = "2" BBPATH = "${TOPDIR}" BBFILES ?= "" BBLAYERS ?= " \ /home/linaro/arm_autonomy/pcu_yocto/sources/poky/meta \ /home/linaro/arm_autonomy/pcu_yocto/sources/poky/meta-poky \ /home/linaro/arm_autonomy/pcu_yocto/sources/poky/meta-yocto-bsp \ /home/linaro/arm_autonomy/pcu_yocto/sources/meta-openembedded/meta-oe \ /home/linaro/arm_autonomy/pcu_yocto/sources/meta-openembedded/meta-python \ /home/linaro/arm_autonomy/pcu_yocto/sources/meta-openembedded/meta-filesystems \ /home/linaro/arm_autonomy/pcu_yocto/sources/meta-openembedded/meta-networking \ /home/linaro/arm_autonomy/pcu_yocto/sources/meta-virtualization \ /home/linaro/arm_autonomy/pcu_yocto/sources/meta-arm/meta-arm-autonomy \ /home/linaro/arm_autonomy/pcu_yocto/sources/meta-freescale \ /home/linaro/arm_autonomy/pcu_yocto/sources/meta-freescale-distro \ " 

Following that we build the host image as:

$ bitbake arm-autonomy-host-image-minimal

SD card setup

We need to prepare the SD card for the PCU image. For our testing we have a 16GB card, the table bellow contains the set of partition sizes we have used, they are orientative and will depend on your particular use case.

Partition	Size	Type
Free	68MB	Unformatted
EFI	24MB	FAT16
boot	1.1GB	Ext4
rootfs	4GB	Ext4
guest	9GB	Ext4

After the SD card is formatted we need to put the image together as follows.

$ cd ~/arm_auto_pcu/host_prj/tmp/deploy/images/ls1046afrwy $ mkdir output $ dd if=atf/bl2_sd.pbl of=output/firmware_ls1046afrwy_uboot_sdboot bs=512 seek=8 $ dd if=atf/fip_uboot.bin of=output/firmware_ls1046afrwy_uboot_sdboot bs=512 seek=2048 $ dd if=fsl_fman_ucode_ls1046_r1.0_106_4_18.bin of=output/firmware_ls1046afrwy_uboot_sdboot bs=512 seek=18432 $ dd if=boot/iram_Type_A_LS1021a_r1.0.bin of=output/firmware_ls1046afrwy_uboot_sdboot bs=512 seek=18944 $ dd if=ls2-phy/cs4315-cs4340-PHY-ucode.txt of=output/firmware_ls1046afrwy_uboot_sdboot bs=512 seek=19456 $ mkimage -T script -C none -d ./../../../../../sources/meta-qoriq-demos/recipes-bsp/secure-boot/secure-boot-qoriq/flash_images.sh flash_images.scr $ dd if=flash_images.scr of=output/firmware_ls1046afrwy_uboot_sdboot bs=512 seek=19968 $ dd if=fsl-ls1046a-frwy-sdk-xen.dtb of=output/firmware_ls1046afrwy_uboot_sdboot bs=512 seek=30720 $ tail -c +4097 output/firmware_ls1046afrwy_uboot_sdboot > output/firmware_ls1046afrwy_uboot_sdboot.img && rm output/firmware_ls1046afrwy_uboot_sdboot $ sudo dd if=output/firmware_ls1046afrwy_uboot_sdboot.img of=/dev/sda bs=512 seek=8 $ echo 'load mmc 0:2 0x80080000 Image;load mmc 0:2 0x85000000 fsl-ls1046a-frwy-sdk-xen.dtb;load mmc 0:2 0x86000000 xen-ls1046afrwy;booti 0x86000000 - 0x85000000' >> output/ls1046afrwy_boot.scr.tmp $ mkimage -A arm64 -O linux -T script -C none -a 0 -e 0 -n "boot.scr" -d output/ls1046afrwy_boot.scr.tmp output/ls1046afrwy_boot.scr 

And we can now copy over to our SD card and extract within the rootfs partition:

$ sudo cp Image /media/linaro/boot $ sudo cp fsl-ls1046a-frwy-sdk-xen.dtb /media/linaro/boot $ sudo cp output/ls1046afrwy_boot.scr /media/linaro/boot $ sudo cp xen-ls1046afrwy /media/linaro/boot $ sudo cp arm-autonomy-host-image-minimal-ls1046afrwy.tar.gz /media/linaro/rootfs $ cd /media/linaro/rootfs $ sudo tar xzf arm-autonomy-host-image-minimal-ls1046afrwy.tar.gz 

Booting the PCU

We are now ready to insert the micro SD card in its slot and turn on the PCU. We will see Xen booting first followed by the dom0 as shown in the images below.

Creating the domU and logging in

After logging into the dom0 we can create the guest image and log into the guest console as:

$ xenguest-manager create /usr/share/guests/myguest.xenguest myguest $ xenguest-manager start myguest $ xl console myguest 

We can log into the guest VM using the root username as shown in the image below.

Video demo

We have posted a video demo of the steps to get the arm-autonomy software stack running on the PCU below.

Conclusion

In this first look at the arm-autonomy layer we have shown how to build the stack for AutoCore’s PCU and the way to start the Xen hypervisor, dom0 and domU within the board.

We are now ready to build on top of this and we will look at deploying ROS2 into the guest VM in the next blog, this way we will have all the components that we need to integrate Autoware.Auto to run in a guest VM handled by the Xen hypervisor, so keep an eye to this space.

OpenGLES 3 Demo on the Rock960 running Panfrost drivers

Wed, 27 May 2020 01:00:00 +0000

Hi all,

Just a quick blog showing OpenGLES 3 applications now running on the Rock960 using the Panfrost GPU drivers.

A Quick Recap on Panfrost:

Panfrost is a free and open source driver for Mali Midgard and Bifrost GPUs.

The driver is capable of running a few demos and has been upstream to Mesa & Linux (currently in linux-next). It has been tested on Rockchip RK3288/R3399, and Amlogic S912 with the Arm Mali-T764, Arm Mali-T864, and Arm Mali-T820MP3 GPUs respectively.

For more details you can look at one of my previous blog

A Status Update on Panfrost’s Accessability

As of now, many Linux distributions like Fedora, Arch etc already build and use Panfrost based mesa drivers for compatible GPUs, provided that the SBC’s device-tree has it enabled upstream.

GLES 3 Demo: SuperTuxKart

AeroCore2 | Zephyr Porting and Upstreaming Efforts

Wed, 20 May 2020 01:00:00 +0000

Introduction

This Blog will summarize the recent porting efforts for the AeroCore2 Mezzanine in Zephyr RTOS.

AeroCore 2

The AreoCore 2 for 96Boards provides MAV control to 96Boards compliant platforms. With an ARM Cortex-M4 microcontroller, STM32F427VIT6, running NuttX RTOS and an integrated connection to the connected 96Boards device, AeroCore 2 gives users a complete Linux installation on a PX4-compatible platform.

Why Port to Zephyr RTOS?

The AeroCore2 by default runs the NuttX RTOS with the PX4 autopilot stack on top. The last supported verion that this board runs is 1.8.2 since the PX4 autopilot out-grew the capabilities of the MCU. And at the time of writing this blog, the latest verion is 1.10.

So as it stands, this board does not have an up-to-date RTOS stack avilable. And that is the reason why I wanted to add this board to zephyr as it had a pretty decent MCU and a lot of life left.

Porting

The pitfalls and challenges

Documentation:

… Or lack thereoff. This board was created by Gumstix using their Geppetto which is a “Drag-and-Drop” level of EDA. Because of the astonishingly high level of automation from design to manufacturing, there isn’t any “human readable” for of schematics that we can follow.

This made for a fair bit of pcb tracing, making sense of the automated documentation and even following the NuttX commits with regards to the Aerocore2. Not the easiest thing for your first try at upstreaming a board.

Constant changes in Zephyr Source

Since the time I sent out my initial Pull Request the Zephyr RTOS repository has gone through a lot of changes on how it handles SoCs and Devices at build time, moving from KConfig to Device Tree.

This resulted in the PR being re-submitted multiple times and took about 4 months (O_o) to get merged.

Changelog

Added all required board files in /boards/arm/96b_aerocore2
Modified pinmux for stm32f4
Add stm32f427 support based on previous work done for the stm32f429.
Rework current stm32f429 implementation to now be based on stm32f427.
Introduce dedicated dtsi for the VI variant of both stm32f427 and stm32f429. This is done to prevent stm32f4.dtsi from being included twice.

What Works and What Doesn’t

Pretty much everything broken out from the STM32 MCU works and is enabled. Better question may be what doesn’t work?

Most of the sensors:
- Sadly most sensors on-board the aerocore2 don’t have a driver in the Zephyr Source tree and hence were out-of-scope for this pull request.
PWM Input: Most drone controller boards have a PWM-in header for controller input, Zephyr at the moment doesn’t have a mechanism to do this.

Conclusion

At the end, I’d like to thank the maintainers of the Zephyr RTOS project and Gumstix for helping out along the way.

You can check out the Aerocore2’s Dedicated page at Zephyr RTOS at: https://docs.zephyrproject.org/latest/boards/arm/96b_aerocore2/doc/index.html

96boards: Autoware everywhere | First look at AutoCore's PCU

Mon, 11 May 2020 01:00:00 +0000

Introduction

We are back with a new entry of our “96boards: Autoware everywhere” blog series. In previous entries we showed how to run a subset of Autoware’s features due to hardware limitations, but thanks to AutoCore we are now able to run Autoware on their Perception Computing Unit (PCU), the first heterogeneous hardware platform of the Autoware.IO project.

In this first post regarding the PCU we will look at the steps we need to take for our initial setup of the board and how to get Cylone DDS installed and set up to be the default DDS for ROS2.

This post is organized as follows:

AutoCore’s PCU
PCU Setup
Getting the pre-built image
Getting Cyclone DDS

AutoCore’s PCU

AutoCore announced their PCU publicly on January 21^st through this ROS Discourse post. The PCU is the first reference design of the Autoware.IO project.

A full description of the PCU specification can be found here. As a summary, it features a heterogeneous architecture with a lock-step MCU and a high performance MPU. Based on the MCU-MPU architecture, different ADAS/AD or relevant functions can be integrated with different functional safety levels up to ASIL D after ISO 26262. A wide variety of interfaces are provided to support vehicle networks connection, sensors and peripherals. Furthermore, additional hardware accelerator could be connected via PCIe to provide additional computing power.

The video below from AutoCore shows a car fitted with the PCU performing some autonomous maneuvers.

PCU setup

The image below shows the back of the PCU. As we are booting using a micro SD card we have shorted pins 2-3 in jumpers 1, 2 and 3, as explained in the PCU Hardware manual. Note for shorting the pins we have used 2.54mm jumper cap shunts.

Getting the pre-built image

AutoCore provides a set of software packages for our development on the PCU. The AutoCore Resource page lists all the available components to get the most out of our PCU. At the time of writing, the latest release package is 20200417. For the purpose of this first post we will download the MPU Image, and we will look at the rest of components in the next post.

We can use balenaEtcher as AutoCore suggests to flash our SD card with the downloaded image.

To log into the image we can use any of the following username/password combinations: user/user or root/root.

Once we log in we can see that AutoCore’s image provides a full installation of ROS Melodic and ROS2 Dashing ready to be used:

user@localhost:~$ ls /opt/ros/ dashing melodic

In addition, Docker is installed by default so we could directly go ahead and pull the pre-compiled arm64v8 Autoware.AI image from autoware/arm64v8 Dockerhub repository or an Autoware.Auto image from our 96boards/autoware Dockerhub repository.

Getting Cyclone DDS

We have 2 options for getting Cyclone DDS into our PCU. If we connect the PCU to the internet we can simply ssh into the board and install Cyclone DDS via:

$ apt install ros-dashing-rmw-cyclonedds-cpp

Otherwise we can add the source code to the SD card after flashing AutoCore’s image and build it locally on the board afterwards. In order to do so:

$ cd /path/to/rootfs/mount-point/rootfs/home/user/ $ mkdir -p ros2_cyclonedds/src $ git clone https://github.com/ros2/rmw_cyclonedds -b dashing-eloquent $ git clone https://github.com/eclipse-cyclonedds/cyclonedds -b V0.5.0 

The steps above will get a compatible version of CycloneDDS with ROS2 Dashing. Once we log into the PCU we need to change the owner of the folder we created earlier and compile CycloneDDS:

$ sudo chown -R $USER ros2_cyclonedds $ source /opt/ros/dashing/local_setup.bash $ cd ros2_cyclonedds $ colcon build 

To set it to be the default DDS we can add the following to the bashrc file:

$ echo "export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp" >> ~/.bashrc $ source ~./bashrc 

In addition, if we have built CycloneDDS from source we will need to overlay our CycloneDDS workspace after sourcing ROS2 or, if we want it to be sourced by default when logging into the PCU:

$ echo "source /opt/ros/dashing/local_setup.bash" >> ~/.bashrc $ echo "source /home/user/ros2_cyclonedds/install/local_setup.bash" >> ~/.bashrc $ source ~./bashrc 

Conclusion

In this first look at AutoCore’s PCU we have just prepared the board to run Autoware and set up Cyclone DDS as the default one for ROS2 and Autoware.Auto.

Next time, we will use some of the available software packages from AutoCore for our Autoware development, so keep an eye to this space.