Skip to main content
BlogEventsIndustry Conference

Report about OSC24 Hokkaido in Japan

By October 22, 2024No Comments

This blog is written by Hiroshi TOKITA (@soburi) and Yasushi SHOJI (@yashi), both active contributors to the Zephyr Project.

The Open Source Conference, Hokkaido, Japan took place on June 30 in Sapporo, the largest city in northern Japan. The event attracted approximately 400 visitors throughout the day, highlighting the strong interest in open source technologies in the region. As part of this event, we hosted a session focused on introducing Zephyr to the Japanese tech community, aiming to increase awareness and build a strong local community around this powerful RTOS. Despite being relatively new to the region, Zephyr received significant interest, with an engaged audience eager to learn more about its capabilities and applications.

Hiroshi TOKITA and Yasushi SHOJI, both active contributors to Zephyr, led the session with a comprehensive overview of Zephyr’s history and its development community. They also showcased real-world examples of Zephyr in action, from spacecraft and satellites to robots designed for nuclear reactor decommissioning and quantum computing systems. The audience’s engagement during the session reflected a growing curiosity and interest in how Zephyr can be leveraged in various industries.

Our session attracted around 20 to 30 participants, which we consider a strong turnout given the current awareness of Zephyr in Japan. The presentation sparked lively discussions, with attendees asking in-depth questions about Zephyr’s technical aspects, such as its device tree structure and best practices for driver development. The level of interest and the quality of the questions were pleasantly surprising, indicating that Zephyr is starting to resonate with the Japanese tech community.

Hiroshi provided an insightful overview of Zephyr’s structure and history, offering the audience a clear understanding of how the project has evolved over time. He also highlighted the various ways new developers can get involved in the community, emphasizing the welcoming nature of Zephyr’s contributor base.

“I think the Zephyr community is welcoming new developers. Zephyr also considers new participants to be an important metric for community management. Therefore, they are very kind to newcomers, and I have experience supporting new contributors, including how to commit to GitHub. So, if you have the opportunity, please send a PR. Sensor drivers are an easy area to get into, as they are highly independent. If you can get an unsupported sensor, please try it.”

Yasushi provided a glimpse into how Space Cubics leverages Zephyr RTOS across various cutting-edge projects. As a company specializing in avionics and onboard computers for all kinds of spacecraft, Space Cubics uses Zephyr as the operating system for their developments. During the session, he showcased their 3U Cubesat, a project they could openly discuss, given the confidentiality surrounding many of their customers’ spacecraft. Additionally, he highlighted how Zephyr RTOS is being employed in a robot designed for the decommissioning of nuclear reactors and in quantum computing modules.

After the presentation, we were pleased to see a lively Q&A session unfold. The audience’s questions were not only numerous but also surprisingly in-depth, reflecting a strong interest in Zephyr’s technical aspects. Some of the questions and answers we discussed are shared below.

A community member asked about the difference between the Linux and Zephyr devicetree. Soburi explained that the Zephyr build system processes the device tree at build time, converting it into C header files that define hardware configurations as preprocessor macros. This method is crucial for Zephyr, which is a real-time operating system (RTOS) designed for embedded systems where minimizing memory usage and runtime overhead is important. Unlike Linux, which processes the device tree at runtime, Zephyr integrates this information directly into the binary during compilation, optimizing for the resource constraints typically found in embedded environments.

Another question asked about was the best way to incorporate additional functions, and Yashi replied that it’s always a good idea to upstream new features when possible, as it benefits the broader community. However, if the features might not be of general interest to the Zephyr community, creating a module can be a practical solution. Yashi also noted that if you already have a library that’s been deployed in real-world applications or used across multiple OSes, it can be easily converted into a Zephyr module to integrate with your project.

Another question received from the community was whether they should use the BSP provided by the vendor for the driver or create one from scratch. Soburi responded that it’s common to create drivers based on the BSP as an intermediate layer that supports the Zephyr API. However, there are also cases where optimized drivers are developed from scratch, depending on the specific requirements of the project.

Next question was for a recommendation on an easy-to-use board. Soburi recommended Raspberry Pi Pico as the cheapest board that Zephyr can run, mentioning that he is one of its maintainers. He also recommended boards from Nordic Semiconductor, NXP, and other companies that contribute to Zephyr. Soburi also noted his work on adding support for the Renesas chip for the Arduino UNO R4 and mentioned that Renesas has now switched to a BSD-3 license and is contributing actively to Zephyr.

Another community member asked in what cases to use the native simulator. Yashi replied that the native simulator can be used anytime and mentioned that his company, Space Cubics, uses it for software-in-the-loop simulation (SILS) because it offers faster runtime and is easier to deploy in the cloud.

Soburi added that the native simulator is useful for debugging and testing, especially for things difficult to test on a device, such as display devices. They shared an example of adding a read implementation to a display emulator using SDL to test the CFB library in Zephyr.

While we were planning the OSC24 event, Susan Remmert, from the Zephyr Project team, sent an interesting photo. This photo is of a Japanese restaurant in Düsseldorf, Germany. The restaurant features Hokkaido foods, and the “Susukino, Sapporo” letter, which is near the event venue, is visible in the photo.

So, Soburi started the presentation with this photo:

“From this photo, I learned that Susukino, the entertainment district of Sapporo, is also found in Germany and is ubiquitous worldwide. Just like the “Susukino”, Zephyr is also ubiquitous all over the world and is an OS used in many places…”🙃 I was so busy with the presentation that I couldn’t take any photos during it.

At the OSC24 event, SpaceCubics (@yashi’s company) and @soburi, as part of the Automotive Grade Linux space, showcased Zephyr Demos.

SpaceCubics is a startup company in space development. They are based in Sapporo. SpaceCubics demonstrates Robot and Super Small Satellites. Robots being researched for decommissioning nuclear reactors.

It’s been a long time since I’ve seen it, but there was a big earthquake in Japan in 2011. At that time, a nuclear power plant experienced some trouble, and they are still searching for ways to safely dismantle it.

SpaceCubics is participating in research to solve this societal issue, and the robot on display was developed as part of that research.

Control is done with ROS2, and Zephyr is used as a microROS node to execute ROS control instructions.

As the robot is intended to dismantle nuclear reactors, the computer needs to be protected from radiation.

The box in the photo is the control unit, which houses the computer system. By concentrating radiation protection measures on this area, the design allows it to operate even in high-radiation environments.

This control box contains many boards, which run Zephyr. This visually impressive robot captured the attention of visitors.

(As you can imagine from its powerful appearance, this robot consumes a large amount of energy. Unfortunately, because the exhibit was in a community hall and not an industrial facility, it couldn’t move around very much.)

CubeSat (Super Small Satelitte)

CubeSat is a standardized 100mm square-form modularized satellite. It can connect some modules to make them bigger. SpaceCubics exhibited its satellite module. Radiation is a problem in space as well.

This XILINX FPGA-based board, developed by SpaceCubics, has duplicated memory, and the logic circuit synthesized by the FPGA can operate while checking whether either memory is affected by cosmic rays.

They are also planning to test a Raspberry Pi Pico-based board on satellites. This is also interesting.

Zephyr – Automotive Grade Linux connectivity (trivial) demo

soburi collaborated with the Automotive Grade Linux Instrument cluster development team, to explain how AGL works with modern car systems.

This demo is a simplified model of a real car. The information system runs Linux, and it communicates with various small computers in the car called ECUs (Electric Control Units) via CAN bus.

This AGL displays an instrument cluster that is built with flutter. (This is one of the newest features of AGL!)

AGL has a system handling vehicle signals that run throughout the whole car based on Vehicle Signal Standard.

AGL instrument cluster receives the signal and shows the RPM of the motor to display.

Zephyr can speak CAN easily, so it is easy to connect to AGL. Zephyr controls the 3-phase-brushless motor and the control information form to Vehicle Signal and sends it to a CAN bus. The speed can control volume, that reflect to the display.

The miniature car is a modified version of a popular Japanese toy named MINI4WD. For many people, this is what inspired them to become mechanical engineers. So this demo was popular despite its simplicity.

soburi collaborated with the AGL IC team to exhibit more large-scale demos at another event.

This is a demo of a commercially available electric vehicle education kit with AGL built into it. It was difficult to transport, so we didn’t exhibit it this event, but it also uses a Zephyr to drive a three-phase brushless motor, so (the computer system) is almost the same.

A little guide to Sapporo (as an excuse for not being able to take photos that convey the atmosphere of the place)

Sapporo is the closest Japanese city to Europe (Helsinki-Sapporo, currently suspended), and is located 800 km north of the capital, Tokyo. It is one of the coldest cities in Japan (although it does get up to about 30 degrees Celsius in summer), and with an estimated 5m of snowfall per year, it is also one of the snowiest cities in the world.
In recent years, the area has been active in attracting space development and semiconductor companies, and the number of embedded system developers is likely to increase in the near future.

The area is also blessed with food, and as we can see from Susan’s photo above, it is being marketed as something the area is proud of. You can enjoy meals in the market in the morning. Sushi and seafood bowls using salmon roe are popular.

Sapporo is also famous for another thing: Hatsune Miku, a character in voice synthesis software created by a Sapporo company, has become a local celebrity. (This company also attended last year’s conference.) There is a special souvenir shop at Sapporo airport that sells her goods.

Next week, we’ll be at the Open Source Summit Japan! If you’d like to meet us and be part of the BoF (Birds of a Feather) session to discuss all things Zephyr, feel free to ping us on the channel #2024-oss-asia under the Zephyr project Discord server. We would be glad to connect with you!

Photo mentioned below: The Zephyr kite soars high at the SpaceCubics offices.