It has been close to a year since embeddedRTPS was last discussed here. This announcement was very exciting for me personally and I’d like to extend my delayed gratitude to everyone who contributed to this work.
I had since been looking to try it out and I finally got a chance to work on it last week. Migration to the latest CubeIDE and APIs (LwIP, ETH) wasn’t very smooth. While I managed to get my STM32F767ZI talking, some basic tests showed that the communication was quite unreliable for some reason. I started troubleshooting and collecting some data. I could share those and my version of the Cube project on GitHub if there is any interest (@jackp510 , @takasehideki , @tomoyafujita , @vmayoral , @Daniel_Cabezas ).
At this point, however, I’d like to see if there are plans to continue the work on the fork in Micro-ROS and/or to sync it with @AKampmann 's repo.
I’d appreciate it if @pablogs and @AntonioCuadros have any comments.
I believe that Micro-ROS/embeddedRTPS has an older version of embeddedRTPS.
I am mainly developing/testing embeddedRTPS for the Xilinx UltraScale+ ARM R5 and Infineon Aurix TriCore (without Micro-ROS on top). I’m not testing it regularly for the STM32 (ideally we would have CI doing this). We are using it in production in a larger system, where the controller also talks to multiple systems running FastDDS without great issues.
When referring to reliability problems, are you also using Micro-ROS on top of embeddedRTPS?
Yes, on the micro-ROS side we are willing to maintain the fork but currently, we do not have enough bandwidth. If you could open an issue/discussion we can discuss if is possible to just sync our fork with the @AKampmann mainline.
Regarding your improvements on your Cube Project, I would like to see it and check if we can integrate /merge anything in the micro-ROS Cube MX/IDE module.
Thank you @AKampmann for your response. I’m aware of the more recent commits to your repo. In fact, I started with that one and the sample test startRTPStest worked fine. However, I haven’t done any further testing on it. I then moved onto Micro-ROS fork as I wanted to base my project on ROS2. In both cases, it seems STM’s ETH HAL and LwIP API and project organization has changed somewhat since when the two repos were Cube updated last. I will outline the changes I see as noteworthy in a separate message here. As for the reliability issues, I encountered them in the Micro-ROS based code. I will also provide more details on my observations separately. It may be that my migration effort caused unintended misconfiguration of LwIP & ETH.
Thank you @pablogs for your response. I can imagine the bandwidth challenges in maintaining all these codebases besides what you have to do to keep the daily operation going. I hope to be of some use and contribute to the upkeep. However, I myself struggle with lack of time that I can dedicate to this project. So, please bear with me as I slowly report my progress.
I have just uploaded my project here with some network captures to aid in troubleshooting. Here is one migration requirement I have seen:
To setup MAC filters (previously ETH_MACDMAConfig()), the latest API provides ETH_MACFilterConfigTypeDef and ETH_MACFilterConfig(). What is done with macinit structure previously is now split into two methods. So, I included the following in ethernetif.c->low_level_init(). Anything other than PassAllMulticast and PromiscuousMode could be left at their default (DISABLE) state but I’d like to see if anyone has any input on these settings.
I also checked ETH_MACDMAConfig to see if the API update has altered any default behavior but I couldn’t find anything glaring.
Enabling PromiscuousMode somehow allows a second sub to work and overall improves the robustness of communication. When I say that, I currently use no quantitative method to measure but I’m gaging purely based on my observation of the traffic flow.
There are times when a message is lost. And after several minutes of operation, the MCU goes out to lunch:
data: 175
---
2022-09-21 00:27:15.221 [RTPS_READER_HISTORY Error] Change payload size of '58' bytes is larger than the history payload size of '11' bytes and cannot be resized. -> Function can_change_be_added_nts
A message was lost!!!
total count change:1
total count: 3---
data: 178
---
data: 179
---
A message was lost!!!
total count change:1
total count: 4---
A message was lost!!!
total count change:1
total count: 5---
A message was lost!!!
total count change:1
total count: 6---
A message was lost!!!
total count change:1
total count: 7---
data: 184
---
A message was lost!!!
total count change:1
total count: 8---
A message was lost!!!
total count change:1
total count: 9---
A message was lost!!!
total count change:1
total count: 10---
A message was lost!!!
total count change:1
total count: 11---
A message was lost!!!
total count change:1
total count: 12---
A message was lost!!!
total count change:1
total count: 13---
A message was lost!!!
total count change:1
total count: 14---
A message was lost!!!
total count change:3
total count: 17---
A message was lost!!!
total count change:1
total count: 18---
Please check it out and let me know what you think.
Hello @AKampmann
I cloned and tested embeddedRTPS-STM32 again today. I get a segmentation fault. This reminded me that I actually did get a segmentation fault the first time I tested Oct 15 version of this repo last week. So, I was mistaken in my comment before. The segmentation fault happens apparently randomly. That is, the counter counts up to different values before it happens. I was able to capture the traffic once when it happened. This looks like a host-side issue to me as rerunning the host program resumes communication though the way it happens within a few minutes like in the Micro-ROS repo is intriguing. I haven’t yet spent time troubleshooting this yet so my insight is very crude at this point.
Received Hello World Data 244
Sending data
Received Hello World Data 245
Sending data
Received Hello World Data 246
Sending data
Received Hello World Data 247
Sending data
Received Hello World Data 248
Segmentation fault (core dumped)
thanks for investigating. The segfault occus in FastDDS, right? Can you maybe run gdb and backtrace after the segfault? I’m currently finalizing my thesis, so I don’t really have time to debug this myself for the next two weeks, but I’m happy to help troubleshooting.