How to setup micro-ROS on any STM32 microcontroller
HTML-код
- Опубликовано: 11 сен 2024
- In this tutorial we will explore how to set up micro-ROS on an STM32 microcontroller. At the end we will have a micro-ROS publisher that sends data to our ROS 2 software. With the approach shown here it should be possible to create a micro-ROS project for any STM32 microcontroller, not just the officially supported ones.
Link to code: github.com/lFa...
Link to micro_ros_stm32cubemx_utils repo:
github.com/mic...
Link to micro_ros_setup repo:
github.com/mic...
micro-ROS website:
micro.ros.org
What is newlib?
preparehub.org...
I am playing your video using laptop speaker, however it sounds like from earbuds. Amazing!
Mannnn bless your soul with good luck, this video is so amazing please keep up the good work. I wish I can do something in return, I am barely in college and Im learning ROS and other processor and you are helping me A LOT. I still don't get totally how it work but I will figure it out. Again thank you for this and your github big thanks you have no idea
This works on STM32F767ZI
Hi Christopher, thanks for the kind words, it made me smile. I wish you good luck on your journey. :)
And thanks for sharing the info that it works on the F767ZI.
Hi Chris, I am also try this using STM32F767ZI, but I'm not able to debug because I don't seem to have the "openocd.cfg" configuration as shown at 14:44 . Could you please explain the process you followed. Thanks
Your explanation is very good and clear. Thanks for video. Its work for me.
I use stm32f407vet
Thanks for the great tutorial.
Hi! My ros agent gets stuck on the "set_verbose_level | logger setup" part. I get no errors, code seems to be fine. It is said on the github page that check that your MCU doesn't crash anywhere (e.g. in the syscalls), but it does not crash, any solutions to this?
FIXED
Same problem here! please help @Robotics in a Nutshell
Do you remember how you fixed this? I am getting the same problem. I have found that my publisher is invalid but I have no clue how to fix this.
@@steopaelidrissi1370 I remember fixing it in the clock configuration settings. Check if the numbers in your clock configuration match the ones in the video. I think that was my problem.
If I want to run this on an L4 and using threadX not FreeRTOS what are the changes that need to be made ? (I am new to this field)
Hi, I don't seem to have to "openocd.cfg" file as shown at 14:44 . I tried with the "st_nucleo_f7.cfg" present in "/usr/share/openocd/scripts/board" folder for my STM32F767ZI. But it throws an error when I hit debug saying ' Prefer GDB command "target extended-remote 3333" instead of "target remote 3333" '. Any solutions?
Thank you very much for your tutorial. However, I have some questions that require your attention. As I follow the tutorial step by step, I encountered the following issues.
When I reached the step of generating the static library, that is:
docker run -it --rm -v $(pwd):/project --env MICROROS_LIBRARY_FOLDER=micro_ros_stm32cubemx_utils/microros_static_library microros/micro_ros_static_library_builder:foxy
The command line output is different from what is shown in the video. What I got was only 'Creating firmware for generate_lib platform generic.'
This seems like the 'make' process has not been executed. What could be the reason for this and how can I resolve it? I am looking forward to your reply.
Great Video....Kudos!!!
Hello i have completed till the handshake of the microcontroller and ros. Its shows the same as you have in step 23. Everything looks fine but when i try to list topic or echo the topic name its not happening
Hi! It is an awesome and really useful tutorial. Thank you! I have one additional question about ethernet transport. Do you have any knowledge about it? How does it work by default in the STM32 based devices officially supported by the Micro-ROS? I tried to find any transport layer or some details about how to send packages by ethernet and I found nothing. It is configured by the environment variables and nothing more.
I'm new to ROS / MicroROS, but you could look into STM32 + LwIP in combination with FreeRTOS.
There are some libraries not found error in drivers. what is the solution for this error?
how to physically connect stm32f103ret6 or stm32f403 or stm32f722
i have st-link v2
or j link seger??
@Robotics in a Nutshell Hi!
I don't see file openocd.cfg on my project. Where I create or download it?
My board is Nucleo-f446RE.
My STM32CubeID does not allow me to edit the Makefile at 3:41
Very useful video. Tried to make it work with the ARM RTX RTOS since it also supports CMSIS, but failed due to missing POSIX support..
great video. it is always challenging when we explore new area. micro ROS on STM32 is a challenge.
my question is:
Do we really need to build Ros lib? Because the C code is already there and when we compile stm32 main.c the ros lib code will automatically compile and build?? Please correct if I am understanding it right. Thank you
Hi there,
this is an interesting question.
With the way that I have described here (which is similar to how the tutorials explain it) you have to build the micro-ROS library before you can compile your program.
The reason is because of the way the Makefile of the CubeMx project is adjusted. You can see the additions made at 5:22. Here we extend the LD_FLAGS with a path to the libmicroros.a file. This means that the linker will expect to find a compiled static library called libmicroros.a at that path. When we compile the binary for the STM, the linker will resolve any references to micro-ros using that library. So the Makefile of the CubeMx project expects that file to exist already, it will not create it itself.
Still it would be interesting to have a different structure in which the library files are compiled when the CubeMx project is being built. I sometimes find myself making changes to the micro-ROS lib (e.g. adding custom messages) and then I have to run the docker command again to recompile the lib. This will then download the whole toolchain (arm-none-eabi-gcc, etc.) to execute the required steps which takes quite long. I'd prefer to simply build the lib with the rest of my code or at least by independent of the docker if I want to. I'm sure there is a way to make this possible but I didn't explore this option yet. It might also be possible to re-use the previously used docker container to prevent downloading everything again.
In summary: If you compile the main.c it is required that you already have compiled the libmicroros.a beforehand. This is because of the way we have adjusted the CubeMx Makefile. So you have to build the lib first, then compile your program. A different option where you build the lib together with the rest of your code is thinkable but wasn't shown here.
Cheers
Fynn
@@roboticsinanutshell Thank you for explaining the reasoning.
Yeah, having every code in the CubeMX would be much better. Like any STM32CubeMx project where all the other files (MCU specific & FreeRTOS for e.g. specific) automatically gets downloaded in the project, we should have something similar for ROS.
All in all, it is a good start.
You can actually add these in the CubeMx project settings and include the library paths of ROS lib. That way when you compile CubeProject, the ROS lib also compiles automatically.
@@MandeepSingh-ny9ok Yes it would be pretty cool if you could select micro-ROS as an option in CubeMx similar to FreeRTOS.
Yeah you're right, that should work. I will try it out some time.
Hi, I am trying to run ORB SLAM on STM32 boards so can you please guide me in the same.
Thanks
Hi ,
I am using STM32H7A3ZI-Q.
Used tools: STM32CUBEMX,
STM32CUBEIDE(instead of eclipse).
In STM32CUBEIDE->Debug configuration-> *GDB OpenOCD Debugging* not coming.so,I debugged with *STM32 C/C++ Application* .
But in that in task.c code has stucked.
Is *GDB OpenOCD Debugging* needed?
Or any other way to solve the issue.?
Hi there,
I have not used STM32CubeIDE so I'm not sure. If you can flash and attach a debugger it seems the general connection is working.
Try to set a breakpoint at the very start of your main() function and see if it is hit. If yes, step through the code and see where it hangs.
To reduce complexity I'd advise to create a very simple CubeMx project without FreeRtos, MicroRos, or any peripherals. See if you can flash and debug that. If yes, add FreeRtos and see if it still works. Once you have confirmed these two steps, you can build more complexity.
If none of this works, feel free to write again.
Okay @Robotics in a Nutshell .
I will do that..and update after it.
Thanks for your reply..!
I've got kind of the same problem here, the difference is that in my case it doesn't even debugged. It shows the message: "STM32 target device not found for selected build configuration. Please edit the "Build Configuration" and specify valid device settings.
There's a file f429_board.cfg and then it disappears and appears a new file openocd.cfg, I've tried to replicate, but I'm using a STM32F746. None of this files were created in any of my attempts
I have the STM32 H757XI Eval Board and it seems to meet the requirements haha
I mean, the memory is enough and it has all the usual communication protocol stuff (CAN, SPI, I2C, etc...), no Bluetooth or WIFI though.
It also has a LCD, and so on.
Do you think it could work?
I am still taking the basics courses (Linux, Python, ROS Basics, etc...), but am already thinking of how I could implement all that taking advantage of this microcontroller I got.
Could you please state your thoughts on that? 😅
Thank you very much.
Greetings from Germany.
Hi there,
since your micro controller is from the H7 series (which is STs most powerful family) I think it will definitely be possible to use micro-ROS with your chip. I would start by transmitting data from the micro controller to your PC, similar to how I did it in this video. I'd use UART at the beginning. micro-ROS also supports other protocols but I think UART is the easiest way to start. Set up a way to flash code onto your board (many tutorials online), follow the steps in this video, and have a look at the micro-ROS documentation. That should enable you to get the first results and then you can just go from there and see where the journey takes you.
I wish you good luck with your project :)
Beste Grüße
Hey, thanks for the tutorial, i have micro blaze on Zynq UltraScale FPGA platform, do you have any tutorials on how to set up micro ros on the microblaze using Vitis? i haven't found any resource that could help and i couldn't quite understand how to make the right Adjustments to my processor using the generic lib in micro ros git hub
Unfortunately I don't have experience with this system. I'd probably try to generate the static library (listed here: github.com/micro-ROS/micro_ros_setup) and include that in your build. That should allow you to include the micro ROS headers into your code. I assume the API for the lib doesn't change so similar steps as described in the video should still apply in general. Set up a publisher / subscriber, connect it via UART, run the micro-ROS agent, and see if it works. If it doesn't, attach a debugger to the MCU or see with prints (use another UART as micro-ROS) where it fails and analyze from there. These steps are just my best guess how it could work, so take the advice with a grain of salt.
Cheers and happy new year :)
Fynn
How would I create a subscriber with this setup
Hi!
When I run "docker pull microros/micro_ros_static_library_builder:humble"
It returns:
How to fix this error?
Thanks.
Hey there, it seems the short hand identifier "microros/micro_ros_static_library_builder:humble" is not supported anymore for security reasons. Can you try "docker pull hub.docker.com/r/microros/micro_ros_static_library_builder:humble" instead?
@@roboticsinanutshell Hi!
I don't see file openocd.cfg on my project. Where I create or download it?
My board is Nucleo-f446RE.
good job! but for me it's very hard to step by step to follow this tutorial, because I don't know how to connect each other(pc and mcu). and how to upload the code to mcu. Can you recommend other reference tutorials? Can it be understood that after generating the code for stm32cubemx, after making the modifications mentioned in the video, upload it to the development board, connect each other，and then start the agent on the PC to communicate directly?
Hi there,
> I don't know how to connect each other(pc and mcu). and how to upload the code to mcu. Can you recommend other reference tutorials?
If you have a development board (they look like this: www.st.com/en/evaluation-tools/nucleo-f429zi.html) then you usually have an ST-Link debugger / programmer on this board as well. You can connect to it by plugging a USB cable into your board (the one you also power the board with). With the ST-Link you can flash code onto your chip. There are multiple ways to do this. You could e.g. use st-link which is a software tool by ST. You can find an explanation here: ruclips.net/video/1cleO3mHjWw/видео.html (until 11:17, then continue at 21:08 to see how to integrate into your IDE). Other options are e.g. using the STM32Workbench (www.st.com/en/development-tools/sw4stm32.html). You need an ST account to download it but you can just create one. The way I do it is using openocd and arm-none-eabi-gdb / gdb-multiarch. In this way I can also debug the node (step through the code). This would look something like this:
Terminal 1:
cd path/to/elf_file/
openocd -s tcl -f interface/stlink.cfg -f target/stm32f4x.cfg -c "init" -c "reset halt" -c "flash write_image erase your_elf_file.elf" -c "reset run"
Terminal 2:
cd path/to/elf_file/
gdb-multiarch your_elf_file.elf
(gdb) target extended-remote localhost:3333
(gdb) load
(gdb) break main
(gdb) continue
(gdb) layout src
The exact interfaces and configs to load might be different.
I'm using it in my IDE so it's not in terminals but happens when I press a button in the IDE. It automatically attaches the debugger and I can step through the code. The openocd calls then look a bit different, they use a .cfg file (this can also be generated with the STM32 workbench). It looks something like this:
openocd -s /usr/share/openocd -f openocd.cfg
where openocd.cfg is:
___
# This is an NUCLEO-F429ZI board with a single STM32F429ZITx chip
#
# Generated by System Workbench for STM32
# Take care that such file, as generated, may be overridden without any early notice. Please have a look to debug launch configuration setup(s)
source [find interface/stlink-v2-1.cfg]
set WORKAREASIZE 0x8000
transport select "hla_swd"
set CHIPNAME STM32F429ZITx
set BOARDNAME NUCLEO-F429ZI
# CHIPNAMES state
set CHIPNAME_CPU0_ACTIVATED 1
# Enable debug when in low power modes
set ENABLE_LOW_POWER 1
# Stop Watchdog counters when halt
set STOP_WATCHDOG 1
# STlink Debug clock frequency
set CLOCK_FREQ 8000
# use hardware reset, connect under reset
# connect_assert_srst needed if low power mode application running (WFI...)
reset_config srst_only srst_nogate connect_assert_srst
set CONNECT_UNDER_RESET 1
# BCTM CPU variables
source [find target/stm32f4x.cfg]
___
It's a wide topic, this was just an overview. Do some research on your own and try around, you'll get it to run eventually. :)
> Can it be understood that after generating the code for stm32cubemx, after making the modifications mentioned in the video, upload it to the development board, connect each other，and then start the agent on the PC to communicate directly?
In theory yes. In practice maybe not. For example the MCU I used has a UART (serial port) that is connected with my PC via the USB-cable. This is not true for all STM discovery boards. If your chip doesn't have it, then you need a UART-to-USB adapter cable to create a UART communication line to your PC. You need some form of communication so micro-ROS can transmit data to your PC and vice versa.
Your first step should be to become able to flash and debug your chip. This is the prerequisite for any further steps. After that you can start trying to get the micro-ROS communication going.
Cheers
Fynn
Hi, I am trying to install the microROS into STM32L073RZT6.
Yet, I am getting this "region `RAM' overflowed by 24688 bytes" RAM error while I am building it.
Is it just because that this MCU does not have enough memory?
Hi there,
yes it sounds like your chip does not have enough RAM. On this page (micro.ros.org/docs/overview/hardware/) in the 3rd paragraph they mention that you need a few tens of kilobytes of RAM to run micro-ROS. According to the datasheet of your microcontroller, it has only 20 kByte of RAM. This seems to be insufficient. The guys at micro-ROS do have further resources on how to tune the memory consumption such as this (micro.ros.org/docs/concepts/middleware/memo_prof/) and this (micro.ros.org/docs/tutorials/advanced/microxrcedds_rmw_configuration/). So you could give these optimizations a try if you want to stick to your current MCU. You could also think about if external RAM could help you. Other than that you have the option to use a more powerful chip with more memory.
Cheers
@@roboticsinanutshell Thanks a lot.
Thank man, I really appreciate your works!. Now I can use this similarly idea on my project. I test on nucleo_f401re and it works well ;).
Great video! I'm build custom piece of hardware with STM32H743 (single core 480MHz, 2mb flash). Do you think it is enough to perform micro ros related tasks and another control routines, like communication over can and some control math in the real time? Or I should switch to something like STM32H745ZI with dual core?
I also wonder about transport of the data over USART3 - it has to be exactly that peripheral? I also consider if it possible to use that UART3 with Bluetooth module to achieve wireless micro ros node. Do you know maybe it is possible?
I also thought about MCU USB peripheral in CDC mode as UART replacement - it's more comfortable to connect via USB instead of additional serial to usb converters. Is this possible to achieve that with micro ros?
Sorry for so many question, I try to develop the most accessible from higher level piece of hardware I can :D
Hi there,
whether the H743 is capable of executing your task highly depends on the actual load your MCU will be under. So things like how many CAN messages do you send/receive per second, how much do you want to transport via micro-ROS, how complex is your control logic, what other things is your MCU occupied with etc. This is a question based on the requirements of your whole project and therefore difficult for me to estimate. The H7 series is one of the most powerful from STM32 and I've seen somewhat strenuous tasks done on chips of the F4 series which is less powerful. I've did tests with micro-ROS on a F429ZI and a F407. That worked without problems but the chips didn't experience any other load at the time. On the micro-ROS website they say that RAM is usually the limiting factor when it comes to deploying micro-ROS (micro.ros.org/docs/overview/hardware/ in the first sentences). I think the H743 will definitely have sufficient RAM here as it seems to have 1MB of RAM whereas micro-ROS only needs a few ten thousand bytes of RAM.
Still I can't give you a definitive answer here what you should take, it's too specific to your use case.
Regarding the USART3: No it doesn't have to be the USART3. It can be any Uart. In fact, it doesn't even have to be Uart. micro-ROS supports multiple way of communication, for instance you can also use UDP, TCP, and CAN FD. The last option might also be interesting for you since you use CAN already anyway. There are also CAN to USB converters that you can use to connect it to your desktop PC. On the other hand UDP / TCP can be interesting for wireless transport of course with some kind of WIFI chip. Using a UART Bluetooth module to transport the data should also be possible.
Regarding your last question: I haven't heard of USB CDC yet. I've had a quick look what it might be and it seems to be a way to use the USB of the microcontroller as a virtual COM port for UART, is that right? If so, then I can tell you that I did exactly that when testing with the F429ZI. Next to the USB cable I did not have any additional cables connected to it and communication via micro-ROS worked. It might be that this only works for certain USARTs though, I think on the F429 you can only do this with the USART3 for example. I can understand that you don't want to have additional UART-to-USB converters connected and I think this is a good way.
Cheers
Fynn
Hello,
Thanks for great tutorial. I've followed it and successfully tested on STM32F407VG Discovery.
One question I have now is how could we make the connection work when the code on the MCU runs first, and then the ros agent node is executed? Because in reality we have a lot of situations like that and we cannot reset the MCU each time.
Thanks for your help!
Hi there, I completely agree, having a limitation where you need to start the agent first and then the MCU is not acceptable in many use cases. There might be a way in micro-ROS as it is right now but unfortunately I don't know about it. You could have a look at the implementation of micro-ROS to see how the agent discovery works and why it might not work. Another option could be to have a look at this article (discourse.ros.org/t/embeddedrtps-the-new-experimental-middleware-for-micro-ros/22741) and the mentioned implementations. In there you will find micro-ROS middlewares that do not rely on an agent and therefore eliminate the problem.
Cheers
@@roboticsinanutshell thanks, if that is the case where we currently don't have an official solution for this, someone (like me) might dive deeper into the source code or search the net in order to figure out how we can modify the middleware or application code for a working solution.
I thought you had already know a way so I asked you first.
Thanks for the hints, I surely would try those !!
@@DinhChuot Maybe there is an official way to do it and I just don't know about it. But I think the idea to have no agent at all is even more appealing.
does it works with the blue bill stm32f103
Hi there,
I remember reading that the most constraining factor for micro-ROS is the RAM usage. They wrote in their docs that you need a few ten thousand bytes of RAM to run micro-ROS. I can't find that page anymore so it might not be valid anymore. In their Stm32 repo they still state that you need a thread with 10kB stack. The Blue pill uses a Stm32F103C8 it seems (stm32-base.org/boards/STM32F103C8T6-Blue-Pill.html ). Looking at STMs page they state that it has 20kB of RAM (www.st.com/en/microcontrollers-microprocessors/stm32f103.html ). There are officially supported boards. The board with the least amount of RAM in there is the Teensy 3.6 with 64kB of RAM (micro.ros.org/docs/overview/hardware/ ). The Blue Pill has 1/3 of the Teensy's RAM. So my initial guess would be that you can't use the Blue Pill with micro-ROS or at least that you will be very constrained. On the other hand, you might only need 10kB of RAM for micro-ROS and have another 10kB for your program. If that suffices for you, it may work. In the end, the truth is in the attempt. Only testing it will reveal whether it can work or not.
Micro-ROS also provides information how to tune its memory consumption. You can find links at the top of the page with the official boards. It might be possible to tune it in such a way that it can run on the Blue Pill.
Thank you, this video has been very helpful! I tried to follow your steps for a STM32F407VGT6, but didn't get it right. So I have a couple of questions:
1. In the build step, my project finished with 0 errors and 0 warnings but my project explorer still shows files with problems. So can I continue with the tutorial or do I have to solve those problems before?
2. I also got an error while running colcon build for the micro-ROS agent:
ERROR:colcon.colcon_core.package_discovery:Exception in package discovery extension 'prefix_path': object of type 'NoneType' has no len()
Apparently the colcon build did finish its execution, but I'm not sure if I can ignore this error.
Thank you again for your help!
Hi there,
1. I don't quite understand the question. Are you talking about building the library, the microcontroller binary or the micro-ROS agent? What kind of problems do you see in the project explorer? Do you mean the small white X on a red background that is shown next to files in Eclipse? That's fine. It's usually a problem with the setup of include paths, defines or something similar in the IDE. As long as it compiles when building the binary you want, all is good. The compiler speaks the truth, not the IDE. ;)
2. I have not seen this error before. I've tried the instructions to build the agent from a freshly cloned repo again and it works without problem for me. Make sure you have the right ROS distro branch checked out. Also be sure to follow the instructions for "Building" first. I've skipped the mkdir steps at first which caused some trouble so for your first test follow them exactly, maybe in a temporary test workspace.
source /opt/ros/$ROS_DISTRO/setup.bash
mkdir uros_ws && cd uros_ws
git clone -b $ROS_DISTRO github.com/micro-ROS/micro_ros_setup.git src/micro_ros_setup
rosdep update && rosdep install --from-paths src --ignore-src -y
colcon build
source install/local_setup.bash
Then execute the steps in "Building micro-ROS-Agent":
ros2 run micro_ros_setup create_agent_ws.sh
ros2 run micro_ros_setup build_agent.sh
source install/local_setup.sh
ros2 run micro_ros_agent micro_ros_agent [parameters]
Does that fix it? If not, when running which command does the error occur?
Cheers
Fynn
@@roboticsinanutshell 1. I was talking about the small white X on a red background that is shown next to files in Eclipse. So I guess there are no problems with that part, being that the binary building finishes without errors. Thanks for clarifying that!
2. I was able to solve the error, it was nothing serious. I also followed your steps carefully, but when I start the micro-ros-agent I get this:
jafet@jafet-Satellite-C55-A:~/uros_ws$ ros2 run micro_ros_agent micro_ros_agent serial -b 115200 --dev /dev/ttyACM0
[1643036775.906617] info | TermiosAgentLinux.cpp | init | running... | fd: 3
[1643036775.906762] info | Root.cpp | set_verbose_level | logger setup | verbose_level: 4
I already checked that I'm using the correct set of parameters (baudrate and device). In the Core/Src/usart.c file I have huart3.Init.BaudRate = 115200. I wasn't sure if this had anything to do with the error, but I wanted to make sure. I also looked into your repository for possible solutions and found that for this problem you wrote that I could check that my MCU doesn't crash anywhere. But I don't know how to do it, so could you please elaborate more on that?
@@jafetgutierrez95 In general the output from the micro-ROS agent you get is expected. It means that the agent was able to find your device. But it did not yet initialize any communication such as a publisher or a subscriber which is not the expected behavior (if you created any subs or similar on the MCU). The most easy fix you can try is to just stop your MCU and run it again. In general you have to start the agent first, then the MCU (at least with the code as it is right now, you could also write it so that it attempts reconnects I assume). If that doesn't work I'd try restarting the agent as well. You could also step through the initialisation process within the MCU using a debugger and see if it halts at any call. This could indicate to you where the problem resides.
Indeed I also had problems where the agent would simply not set up the publishers, subscribers, etc. and no communication was possible. Unfortunately I don't have a clear answer to that problem either right now. When I've encountered it I mainly tried restarting the agent and the MCU until it worked eventually. So I'm also in search of the best approach to solve that problem.
I hope this answer still helps you at least a little bit. If you find out anything how to fix the problem, consider writing it down here so I and others can learn from your findings.
Cheers
Fynn
@@roboticsinanutshell I understand. Thanks for the detailed info. I’ll keep you updated on anything else I find.
@@jafetgutierrez95
Sir , Did you overcome the problems
Coz , without any prior idea on whether or not the controller is compatible with ROS, purchased the controller and has been facing issues since a week . I was hoping to get in touch with you .
Hi, I found the video very clear until 8:48 minutes then you started in super-speed to open different IDEs and I couldn't follow you anymore, most likely it's just my problem that I don't know English well enough , is not that you can give me some explanation of what you did then? I'm following with the subtitles but the auto generated ones are really terrible (FreeRTOS is Friend :))
Hi there,
what I did there was set up a way to compile the program (the binary file for the micro controller) in Eclipse (IDE). You don't have to use Eclipse, I just like it for its debugging capabilities. At 3:40 we've set the project up to be Makefile based. This means that in general you simply have to run "make" in the root folder of your project. Since I don't want to type "make" into the terminal all the time, I set up the IDE to do that for me when I press a button.
There is one special thing about this though. Usually you would simply use a compiler like g++ to compile your program. But since we are compiling for an embedded system, we need to use a different compiler. For example you can use arm-none-eabi-g++, you will have to install that. You might know that a compiler looks at the C/C++ code and transforms it into assembly code. The available syntax for the assembly code changes depending on the system, they have different instruction sets (assembly syntax / commands). This is why you need a different compiler. It will do cross-compilation for you, which simply means that it will compile the code for the embedded system and not your own PC.
The Makefile generated by CubeMx already takes care of choosing the right compiler for you when you run "make". But you will need to install it first.
If the compilation ran through without errors, there will be an .elf or .bin file in your build folder. This is the file that you have to upload to your micro controller.
I hope it helps :)
Cheers
Fynn
@@roboticsinanutshell Thank you, then reviewing the video with more attention and calm I was able to make everything work.
There are two aspects that I would like to find explained in a new video if I feel like doing it :)
The first, which is driving me crazy, is the publication of a message of type sensor_msgs / msg / battery_state.h. As soon as I try to publish the program it jumps into HardFault_Handler ().
The second aspect is the subscribe of a message.
This tutorial is very good, but it goes very fast and often the audio and the video are out of sync; so one needs to pau and repeat many times. Next time you create a useful video like this one, please control your pace.
I few words from my side concerning microros
1.) For a STM32L4 the libmicros.a became about 30MByte. Really strange to me because there is no other lib from GCC for this uC that is close to that size. So I'm not sure if we still can talk about MICRO-ros. Anyway, usually you use just a friction of the lib and the linker is clever enough to copy it in pieces. I just have some concerns about the performance of the code. But couldn't really test something.
2.) To generate the lib via docker is 'unusual' in the embedded programming. Even small changes require a long turn around time to update the code. This has already be mentioned and hopefully the owners will add an option to generate it on a bunch of *.c/*h files to make it more flexible
Now the more serious things
3.) At 15:02 you mention that the program will stall in the function call rclc_support_init(&support, 0, NULL, &allocator); Actually it is not stalling - it is heavily crashing because the NMI interrupt is triggered. So far I couldn't get it to run and don't know the root cause. I will update this comment if I can fix it.
Even a running microros agent isn't preventing that behavior. So I disagree with the comment that this is related to the microros agent running or not. In any case I have a big question mark above my head if such things happen in a library that should be properly tested. You cannot proper debug because the corresponding lib function is only available in assembler (as a result of generating the lib separately). Yes, all the settings about the memory etc is according to the documentation.
4.) Having the demand of 10.000 Bytes for a uC task is - friendly speaking - unusual. I never saw something like this before. Most applications will have some subscribers and some publishers. So you have to setup the msg-frame for them and transmit/receive functions for it. I have no idea why 10.000 Bytes Stack are needed for this. What will happen if you need more than one task with mircoros function calls? If it is not preferred to have more than one task with microros function calls, we find our self not too far away from a typical endless loop we know e.g. from a lot of Arduino programs. So real-time and pseudo parallel execution is not possible.
5.) Is it really true that the communication is only alive if the microros agent is alive before the uC is? In many applications this will become a tricky thing because the host running the microros agent usually will take longer to wake up compared to the uC. Even the previous ROS1 and rosserial could do this better (but also not really good).
6.) for me the generation of the microros agent is a nightmare. On one of my linux machines it worked on the other not. The dependencies between ros, CMAKE and a few other tools seems to be very hard and a high risk that something will fail. I also ask myself why there isn't a ready to be used GUI for this function available. I know, the Linux world loves to build everything from scratch - but for what benefit?
There is a snap version of the microros agent available. Ready to be installed. Maybe that will help - I will test after I fixed my application to not crash.
In short: Microros might be a step forward from ROS1 and rosserial. Be aware that this might be also an uphill battle. The SW structure and the development process is not ideal for embedded systems. Performance isn't clear and the level of documentation is weak. The link on the host side seems to be even more complicate than the previous rosserial application without really offering better functionality. For infomation - I'm using FreeRTOS 10.4.6.
Thanks for this tutorial that allows a reproduction is an acceptable time.
Hi there,
thanks for your input. I'll state some of my thoughts:
1.) I can confirm that the libmicroros.a also has a significant size for me (25.1 MB). In the video at 11:16 you can see the size of the image that was compiled (text: 65249, data: 228, bss: 71512). So approximately 65 kB of flash and 71 kB of RAM is used in this case (F429ZI, FreeRtos, one publisher). Of course as you add more functionality the size will grow and more parts of the lib will be linked. Since even the most powerful STM32 chips (e.g. H7 family) don't go over 2 Mb of flash and 1 Mb of RAM, I don't think the lib will get close to using that much space. Still I'm also wondering why it is so big.
2.) Yes, I agree. While the docker can be handy, I'd also appreciate a more straight forward build process without time-consuming re-compilation steps.
3.) If you find the issue, let us know. I'd be interested. In the repository for the micro-ROS setup they write "This software is not ready for production use. It has neither been developed nor tested for a specific use case.". So it's still very much work in progress. Still I think that such an error should not occur. How did you notice the NMI was called? I believe it should also be possible to step into the library files. You just have to tell your debugger where it can find the .cpp files of the lib so it can resolve the symbols in the .elf to the right code line.
4.) I'd also like some transparency here why the thread needs this much stack. One approach I took is to have a single thread handling the subscriptions and then using the callback functions to distribute the information to the right thread. In the constructor of the thread that wants a subscriber I would register a subscriber with the micro-ROS thread. Registering simply means adding an entry to a subArray. When the micro-ROS thread starts it would iterate this subArray and create the subscribers. As the callback function it would register a C function. In this C function I'd get my C++ controller class and call it's sub callback function. Something like this:
void cWheelCommandCallback(const void* msgin) {
getWheelController()->wheelCommandCallback(msgin);
}
In this way I only had a single thread for the subscriptions. For publishers a similar approach was used. I remember that I had some issues with this approach though but I'm not quite sure anymore (it's been some time). I believe I had some issues with stalling due to thread priorities. So it was just a workaround, in the end of course I also want to simply create subs, pub, etc. in the thread that wants to use them and the requirement for 10 kB of stack is making that more difficult.
5.) I can not say if it is a requirement. I only noticed that I've had more success in getting it to run if I ran the agent before the MCU. I assume in theory the MCU should simply wait for the agent to become available. But when the agent started, no communication was set up and only after restarting the MCU, a connection was established. You might see different behavior. It might also be related to question 3. If there is actually a bug that lets the MCU crash, solving this bug might enable the two systems (MCU, agent) to start in any order.
6.) This issue I couldn't observe yet. I've followed the steps as described in the video and it worked without problem. But it may be system dependent as you write.
Yes I agree, micro-ROS is still young and there is still a long way to go. Still I think it's a step in the right direction and with further development, it can become an essential tool in the ROS ecosystem.
I'm glad the video could help you.
Cheers
Fynn
@@roboticsinanutshell Could you tell me how to transplant to stm32f103?
@@shodan1q870 Hi there,
to port micro-ROS to an STM32F103 you need to follow similar steps as described in the video.
Make sure that your device supports the requirements (a few ten thousand kilobytes of RAM & communication peripherals such as UART).
Looking at the chart here your RAM size really depends on the type of F103 you have: www.st.com/en/microcontrollers-microprocessors/stm32f103.html
It might be that the F103 has a too limited RAM size. To find out you probably just have to give it a try.