D2.5micro-ROS default simulation

environment releaseInitial Y1

Grant agreement no. 780785Project acronym OFERAProject full title Open Framework for Embedded Robot ApplicationsDeliverable number D2.5Deliverable name micro-ROS default simulation environment releaseDate June 2019Dissemination level publicWorkpackage and task 2.2Author Juan Flores Muñoz and Iñigo Muguruza Goenaga

(Acutronic Robotics)ContributorsKeywords micro-ROS, robotics, ROS, microcontrollers, simulator,

simulationAbstract micro-ROS simulation tool initial release

D2.5: micro-ROS default simulation environment release – Initial Y1

Contents

1 Summary 2

2 Acronyms and keywords 2

3 Links to Software Repositories 23.1 Docker of the simulation environment . . . . . . . . . . . . . . . . . . . . . . . . . 23.2 NuttX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23.3 micro-ROS-simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

4 Introduction 3

5 Requeriments 3

6 List of Available Options 46.1 NuttX official simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46.2 QEMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

6.2.1 Qemu_STM32 (By Beckus) . . . . . . . . . . . . . . . . . . . . . . . . . . . 56.2.2 GNU MCU Eclipse Qemu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56.2.3 Pebble Qemu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

7 NuttX official simulator 57.1 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

8 Qemu_STM32 78.1 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

8.1.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88.1.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

9 Eclipse GNU QEMU 99.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

10 Final conclusion 10

11 NuttX simulator test 11

1

D2.5: micro-ROS default simulation environment release – Initial Y1

1 Summary

The document discusses the different tools we have found for simulating micro-ROS in a regularcomputer. Analyzed simulators are presented, describing its characteristics and stating its suitabilityfor micro-ROS execution. At the end, the selected simulator is presented and the tests we havebeen able to execute are mentioned.

2 Acronyms and keywords

Acronym ExplanationMCU Microcontroller UnitROS Robot Operating SystemRTOS Real-time Operating SystemRMW ROS Middleware interfaceUART Universal AsynchronousTCP Transmission Control ProtocolUDP User Datagram ProtocolRTC Real-Time ClockRAM Random Access MemoryCPU Central Processing UnitSPI Serial Peripheral InterfaceI2C Inter-Integrated CircuitGPIO General Purpose Input OutputDMA Direct Memory Access

3 Links to Software Repositories

3.1 Docker of the simulation environment

• Git repository: https://github.com/micro-ROS/docker• Branch: docker_sim• Commit Hash: e4630e3

3.2 NuttX

• Git repository: https://github.com/micro-ROS/NuttX• Branch: master• Tag: v0.0.2-alpha

3.3 micro-ROS-simulator

• Git repository: https://github.com/micro-ROS/micro-ROS-simulator

2

D2.5: micro-ROS default simulation environment release – Initial Y1

• Branch: stm32• Commit Hash: 210d417

4 Introduction

The objective of this task is to develop a solution which can simulate, in a regular computer, ideally,the complete stack of micro-ROS, or as many layers as possible. The usefulness of such a tool isvarious, as it could abstract the MCU’s architecture. For example, it could be used for code basicvalidation or for continues integration purposes.On the other hand, due to the fact that simulation is a difficult task, there are not many accuratesimulators available. We will explore the different implementations we have tested, explainingtheir constraints and explaining which has been the selected simulator. Additionally, user needsto take into account, that such programs, are not able to emulate low level resources normally,such as peripherals. This sets a restriction in their use. But, despite of this restriction, we have amicro-ROS client that sends and receives topics that is ready to run.

5 Requeriments

In order to understand if a simulator is useful, we are going to set a list of minimum requirementsthat it needs to comply with. Our main objective is to execute a simulation which includes thecomplete set of micro-ROS layers, which includes NuttX RTOS, Micro XRCE-DDS middleware,RMW and the micro-ROS client library.In order to have an accurate simulation that emulates properly the software that real hardwareexecutes, it is important to run each layer. Due to the constraint resource of the MCU, we aregoing to be able to see how each layer can affect the simulator performance.First, we will analyze the minimum requirements NuttX needs. NuttX is an RTOS which can runin a huge variety of boards with different architecture. If we analyze in detail each architectureimplementation, we can find some common points. We can take those common points as the basicrequirement for running NuttX:

• UART support: This give us console access.• RTC and Timer support: Some basic functions of the RTOS, like threading, requires

timing tools to work.• Enough flash and RAM memory to fit NuttX: The tests on the Olimex Board give us

that consumes in total 128 KB of flash and 9KB of RAM.

Once we have set the requirements to execute NuttX, we need to establish the ones the rest ofthe software layers requires. Based on the test performed on the Olimex-STM32-E407 board, wededuced the next basic requirements for the aforementioned layers:

• External connectivity to have communication with micro-ROS Agent: Use of serial,6LOWPAN or UDP/TCP through Ethernet to communicate with the micro-ROS Agent. Theminimum requirement is the serial, as it already gives us communication means, and as mostof the MCUs have it.

3

D2.5: micro-ROS default simulation environment release – Initial Y1

• Polling support: The communication on micro-ROS is asynchronous, so we need a tool tocheck the incoming message. In this first version of micro-ROS, this mechanism is implementedby polling, we need this feature at this version (v0.0.1).

• C++ support: As ROS 2 uses heavily C++. This is already asked in the micro-ROSCMake, here for instance.

• 36 KB of RAM and 383 KB of flash. This requirement is based on the memory analysismade on the Olimex-STM32 E407 board and it shows the minimum memory size that isrequired for micro-ROS execution.

After this study we can conclude that we need to find out a simulator that fulfills the next list ofrequirements:

• UART communication with two available ports, where one is used for interfacing andthe other one for micro-ROS Agent communication

• RTC and Timer support• Polling support• C++ support• 36kB of RAM and 383 kB of Flash

Also, we could add to this list a set of desirable characteristics:

• Simulated Ethernet support: Despite of we can use micro-ROS only with serial commu-nication, it would be desirable to support it, as the micro-ROS Agent does it.

• MCU architecture simulation: To have a simulator as close as to the real hardware’sarchitecture.

• Peripheral simulation

6 List of Available Options

After some research, we found two possible option that could meet our requirements:

6.1 NuttX official simulator

This simulator, has been developed by the NuttX community with the aim of easing the developmentprocess in code and applications which are not peripheral dependent. This simulator does notemulate any specific architecture, NuttX RTOS solely. It is compiled and executed as a regularbinary for X86/X64 architecture, and, as stated, it doesn’t simulate an MCU architecture or anyperipheral.

6.2 QEMU

QEMU is a MCU and CPU architecture simulator. This simulator is open-source and is widely usedby kernel developers. As it is focused on low-level simulation, it has better, but limited, supportfor peripherals; such as GPIO, serial, SPI or I2C.

4

D2.5: micro-ROS default simulation environment release – Initial Y1

The master branch of this tool’s repository includes different MCU architectures, including ARM’sARMV7, which is the architecture of the Cortex-M3/M4/M4F/M7 cores. This allows us to developcode for different MCUs that are based on that architecture. For example, the Olimex boardcontains a Cortex M4F MCU. By default, the only MCU supported, in the official QEMU sourcecode, which is functional is the Stellaris LM3S6965EVB.From the master branch there have been done a few forks. Some of them are interesting forour purposes, because they have given support for other MCUs of other vendors, such as ST-Microelectronics. These are the most interesting examples we have considered:

6.2.1 Qemu_STM32 (By Beckus)

This fork contains the development of the Cortex-M3 cores for STM32 MCU family. This versionincludes the STM32P103 and the STM32F103C8 microcontrollers. On this basis, it would bestraightforward to develop any other STM32 Cortex-M3 MCUs, as all of them share the sameregister addresses.This repository has been also the base for other implementations that could satisfy our requirements,explained in the next sections.

6.2.2 GNU MCU Eclipse Qemu

This Qemu fork is a module of a project called GNU MCU Eclipse, which wants to create acollection of MCU development tools for Eclipse. This simulation utility is focused on easing thedebugging process, avoiding the use of physical boards. It includes a huge variety of Cortex-M3boards, and includes some Cortex-M4 and Cortex-M4F boards.

6.2.3 Pebble Qemu

The objective of this fork was to create a developer tool for Pebble wearable clocks. This versionis focused on the STM32F205 MCU and probably is the most complete version of all the forksmentioned here, due to the high number of peripherals developed.After this fast review of the available options, we’re going to study, in detail, all the options exceptthe Pebble Qemu and the Qemu standalone. The reason of not studying these options is that, thefirst one is totally focused on the custom architecture of the device. This implies that it is expectedhaving difficulties adapting the simulator to our needs. The second one is at very early stages andit doesn’t have support for the STM32 MCU, so it doesn’t make sense to use it, as our hardwaredevelopment platforms uses STM32 chips.

7 NuttX official simulator

The NuttX simulator is a version of the RTOS that runs on a X86/X64 machine as a nativeapplication. The simulator isn’t a virtual machine, it is a single thread that implements a non-preemptive version of NuttX. The software developed and included in the simulator by the user can

5

D2.5: micro-ROS default simulation environment release – Initial Y1

only interface with the NuttX simulator resources, so it can’t access, by default, to the resourcesand peripherals of the host PC. Link to the NuttX official simulator

7.1 Usability

This utility tries to use the same tools as for a real board. So it is required to configure, compile,and execute the NuttX source-code, as in regular NuttX application. The process of the executingan application in the simulator is the following:

• Use the simulation config profile as in a regular board, typing ./tools/configure.shsim/nsh in the command line.

• Compile it, typing make in the command line.• Execute it, by going to the NuttX folder and executing the application called nuttx.

Once you execute this application, the NSH -NuttX Shell- console will start and you can use NuttXas usual.

7.2 Limitations

The objective of this utility is to simplify the development process of code that has no dependencyof peripherals, such as the development of the C++ library. After some test, we found the followinglimitations:

• The behavior of the RTOS is different: Comparing the MCU behavior against thesimulation, as the does not simulate the MCU architecture. It is just a compilation of Nuttxfor computers.

• ucLibc++ library support is very limited: Despite this library has been ported toNuttX, it doesn’t compile on X86/X64 architecture. We have tried several times. This wasconfirmed by the community, check the next forum discussion.

• As said previously, this simulator has been created as a developer utility. So the peripheraland resources support from the host PC is very restricted. It only allows to use somecommunication means with a high quantity of modifications. We performed the followingtests:

– Networking: Creating a network bridge in the host PC and redirecting the connectionto the simulator, we can achieve a local connection between the host PC and thesimulator. But the Internet connection was lost and we have got a local network betweenthe simulator and the host PC. In the next post, you can check, in detail, the discussionabout this functionality: NuttX forum simulation networking

– External Serial: As mentioned in the requirement section, it is a mandatory require-ment for micro-ROS. In the NuttX forum confirmed that, theoretically, it should bepossible to run a virtual serial port. But unfortunately, due to the lack of information,we weren’t able to use it.

6

D2.5: micro-ROS default simulation environment release – Initial Y1

7.3 Conclusion

Even though we consider this tools interesting for some users, it is not a good option to use it asmicro-ROS simulator. As mentioned previously, the lack of support C++ support and the difficultyof setting-up communication with the host PC, makes extremely difficult to run a micro-ROS client.

8 Qemu_STM32

This is a fork of the original QEMU source-code, which includes support for the STM32 Cortex-M3 microcontrollers. At writing time, only the STM32F103C8 and the STM32P103 MCUs areavailable. In this fork, the following peripherals and resources have been developed:

• ADC• AFIO• CRC• DAC• DMA• EXTI• GPIO• IWDG• RCC• RTC• TIMER• UART• External Systick

Thanks to the high quantity of peripherals included, we can have a simulation more similar to areal board’s architecture. The link to QEMU_STM32 Project page is this one.

8.1 Usability

After some tests, we achieved to run NuttX for the STM32F103 part number inside the simulator.We obtained the next results:

• Up to 4 UART can be used, and any of them can be used as a console.• It is possible to use the emulated hardware timer.• It has DMA support.• You can read and write the GPIOs.

In conclusion, NuttX is functional under this MCU simulator. Once we have validated NuttX underthis simulator, we started performing test to know if it’s possible to run full stack micro-ROS. Weachieved it doing the following modifications:

• Setting a RAM and Flash size of 196KB and 1MB, respectively.

7

D2.5: micro-ROS default simulation environment release – Initial Y1

• Setting the same number of UARTs that the Olimex Board has.

So, it is possible to run the micro-ROS client. Additionally, is able to have communication withmicro-ROS agent, but with very unstable behavior. This problem will be analyzed in the nextsection.

8.1.1 Limitations

Our objective is to achieve a simulation comparable to run micro-ROS in an Olimex-STM32-E407board. Checking the technical details of our development platforms, the mentioned board hasa STM32F407ZG which is a Cortex-M4F MCU. On the other hand, the simulator MCU is anSTM32F103C8, which is a Cortex-M3. After some research, we concluded that, basically, a Cortex-M3 and Cortex-M4 core are mostly the same. The only difference is the addition of some blocksthat the M4 contains. The following comparative image shows the architecture of each one:

In this project we don’t use any of the extra features that the Cortex-M4 includes, thus, at thismoment, we can use a the Cortex-M3 cores at simulation, without any serious drawback.Regarding the stability problems, despite that we have achieved full connectivity with micro-ROSAgent, it is not stable. This is due to the memory overflows it suffers. We have detected thefollowing problems:

• The simulation doesn’t manage the memory right, so some resources need to be oversized,like, for example, the main thread stack. This conclusion is based on the observations duringthe tests.

• The UART buffer also is not managed right. When we send a huge quantity of data with ahigh baud-rate, it overflows. So, the solution was to decrease the baud-rate to the minimum.

• QEMU offers an option to connect a serial port of the MCU to a virtual port. This a verygood solution, but when you need to work with the system console, you are in risk of causingan overflow in the buffer. Luckily, we have an alternative. This implies redirecting the serial

8

D2.5: micro-ROS default simulation environment release – Initial Y1

port to a TCP server, which accepts external connections, as stated in the discussion ofUART overruns. This option gives more stability to the system.

After these modifications, we stabilized the simulator considerably, having a better functionality.Even though it is not hundred per cent stable, the simulation is functional.Additional points to take into account are:

• It does not have any networking support for the connection. Please see networking peripheralsupport

• As we are still in the first stages of the micro-ROS client, we consider that could be optimized,having a better behavior in the simulation.

8.1.2 Conclusion

As we saw in the previous sections, we have been able to run the complete micro-ROS stack usingthis emulator. We think that, probably, in a future version of micro-ROS, the stability problemswill be solved. We suspect this because we have also performed some tests running NuttX andMicro XRCE-DDS, where we have obtained excellent results in terms of stability.On the other hand, there are some problematic points to address which are:

• The development appears to be almost frozen, consulting the last commit date.• We’re not using the same MCU as in the development boards we use.

But despite the previous issue, this is the option that gives the best results.

9 Eclipse GNU QEMU

GNU MCU Eclipse is an open source project that includes a family of Eclipse plugins and tools formulti-platform embedded ARM and RISC-V development, based on GNU toolchains. This projectincludes as simulation tool, the Eclipse GNU Qemu, which is a Qemu_STM32 fork.This fork includes support for the next STM32 MCU part numbers:

• STM32F103RB• STM32F107VC• STM32F405RG• STM32F407VG• STM32F407ZG• STM32F429ZI• STM32L152RE

9

D2.5: micro-ROS default simulation environment release – Initial Y1

From the list of supported boards is remarkable to notice that the MCU that the Olimex STM32-E407 board uses is supported. You can find the whole list in the next link: Supported boards andMCUsThis approach simulates the MCU/Board, and uploads the firmware to the simulator, copying theconfiguration and compilation of the firmware steps, as done in the in a real board. Once youupload the firmware to the simulated board, you will have an animation where you can interactwith it and, also, it includes a debug console which shows the state of the board.

The link to project is this one

9.1 Limitations

This option only has support for basic GPIO operations. So, is necessary to further develop eachperipheral for our purposes, based on this basic GPIO operations. One of the critical limitations isthe lack of UART support. This was confirmed by the creator of the fork in a forum discussion.This issue invalidates this candidate, because if we don’t have UART support, it is not possible toaccess to the system console and neither to the external UART, which is necessary to set micro-ROSclient/Agent communication.

9.2 Conclusion

This candidate is an active project, which receives periodic updates, so is interesting. It offersvisual tools, such as a graphical interface, and the support of the Olimex-STM32 E407 board. Butthe lacks of UART support, which is one of the requirements we have to run the micro-ROS client.

10 Final conclusion

After this research, we can reach to the conclusion that the official NuttX simulation could be agood solution, because it has support from the community and is easy to use. But the difficultyof using a secondary UART, the tedious networking bring-up process and, above all, the lack ofuLibc++(C++) support, invalidates this approach.

10

D2.5: micro-ROS default simulation environment release – Initial Y1

On the other hand, we have the Eclipse GNU Qemu approach. This is an interesting option due toa large number of boards ported and as it is in active development. But the ported boards havevery little peripherals support, so this also invalidates this approach.The last analyzed option is Qemu_STM32. This tool has included the STM32 Cortex-M3 architec-ture for QEMU. Despite it doesn’t support the same MCU that we use by default, if we performsome modifications on the already available MCU, we can achieve a fully functional client versionbased in NuttX and Micro XRCED-DDS. Furthermore, we achieved a functional, but sometimesunstable, version of a full micro-ROS client.As we can see, the most reliable option is the Qemu_STM32, and this is the emulator we haveselected for micro-ROS.

11 NuttX simulator test

The simulator is available in GitHub, and any developer can use it, following two methods:

• Install and set it up manually, by following the next guide: Install Qemu and Load the NuttXfimware.

• Trying a Docker container, which has everything ready to execute: Docker micro-ROSsimulator

11