Real-Time ROS for Embedded Systems

[Yigit Gunay]

Hello everyone,

We are developing a lightweight implementation of the ROS middleware on STM32F4Discovery for interfacing embedded and general-purpose software. Currently, we can run multiple ROS nodes concurrently on STM32, and we can send ROS messages between a PC and STM32 over Ethernet (only UDPROS).

Please take a look at our repository on Github if you are interested in our real-time ROS development: https://github.com/bosch-ros-pkg/stm32.

I would appreciate your comments. Thanks for your attention!

Best regards,
Yigit Gunay

[Elijah Motorny]

I think it's better to switch to stm32f3-discovery. You will have more sensors on board in smaller size and comparable CPU performance.

[Martino Migliavacca]

There is no Ethernet MAC on the F3, so it is not suitable to work with UDPROS.

Moreover, the F4 used on the discovery board has more that twice the DMIPS with respect to F3 discovery board, 5 times the RAM, and 4 times the Flash memory, they are not really "comparable".

By the way, Yigit, back in 2012 we developed uROSnode, a ROS client supporting TCPROS (at that time UDPROS was not recommended), if you want to take a look sources are here:

https://github.com/tinito/uROSnode

We still use it to interface hardware platform (i.e., real-time control) with ROS applications, it works quite well, supporting topics, services, and parameters. The major limit is that using TCPROS you can't have too many publishers/subscribers (-> TCP connections), you can get about 10 pubs+subs before finishing the RAM.

Best Regards,

Martino

--
You received this message because you are subscribed to the Google Groups "ros-sig-embedded" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-embedd...@googlegroups.com.
To post to this group, send email to ros-sig-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ros-sig-embedded.
For more options, visit https://groups.google.com/d/optout.

[Yigit Gunay]

Hi all,

Ethernet stack and about 100K RAM is required for our system to communicate with ROS on a PC using UDP. However, it would be nice to have on-board MEMS. Is there another board with those sensors that supports use of Ethernet stack?

@Martino:
Can your system run multiple ROS nodes concurrently? As far as I understood, there is only one node in the system. Also, how would a simple node for sending ultrasonic sensor output look like? I couldn't see much in the documentation. It would be nice to test your project as well for comparison. Also, how do you realize message generation? Do you support e.g. messages used in rosserial?

-Yigit

[Elijah Motorny]

Have a look at STM32F429-Discovery and upcoming STM32F7- Discovery.

[Erwin José Lopez Pulgarin]

I would also try to use this very interesting project in the upcoming F7 series MCU, an increase in performance and peripherals.

--

Gracias

Erwin José López Pulgarín
Ingeniero Mecatrónico
Universidad Nacional de Colombia

[Martino Migliavacca]

Yigit, you are rightç actually each uROSnode instance is one node, so ROS sees one node for each board.

Anyway, publishers and subscribers can live in different threads (we always do that), so there is one "ROS node" but concurrent threads sending and receiving messages.

Message handlers are generated by a python script (urosgen), which reads standard ROS message definitions and produces stubs to handle incoming and outgoing messages. The user is only required to fill a configuration file (here a complete example - usually we have about 10 configuration lines for normal applications). The generate code looks like this, you can find the placeholders where you are required to fill the message to be published / read the received message.

Best regards,

Martino

[Yigit Gunay]

Hi all,

Thanks for the information.

Martino, how do you specify loop periods for publishing unless it is the same for all publishers? Also, do you have an inter-thread communication mechanism to pass ROS messages between a publisher and subscriber on the same STM32? Would it be possible to e.g. control a motor depending on the output of a sensor using your software (a publisher reads sensor value and publishes it to a topic, then a subscriber reads this value and controls the motor), or is it only used for passing messages to/from a ROS system on a PC?

Can your software handle DDS as well to support ROS 2.0 in the future without rewriting the entire logic, assuming there is a free RTPS implementation in C for STM32? I would also like to know if you have done any real-time analysis of the system. Thank you!

-Yigit

[Martino Migliavacca]

Hi,

you can publish messages at any rate, there are no constraints. We usually have publishers running in different threads, and the thread loop determines the publish rate.

uROSnode is a ROS communication library, inter-thread communication is handled by the underlaying OS. We currently support ChibiOS/RT (the RTOS we use on our boards) and Posix.

Moreover, we developed a middleware targeted at microcontrollers which handles all the inter-thread and board-to-board communication (over CAN bus, with real-time capabilities), so all of that is not handled by uROSnode, which is used to interface the real-time CAN bus network to ROS systems.

We have a set of hardware modules (motor controllers, sensor interfaces, IMU, communication interfaces, etc etc) which we use to control our robots (low-level control), while high-level control is implemented in ROS by using uROSnode.

I've briefly looked into DDS and I believe it will be really hard to port to microcontrollers, but I did not investigate deeply. The only "embedded" implementations I found had requirements not compatibile with RAM and Flash of STM32-like microcontrollers.

You can read about the system (it is called R2P - Rapid Robot Prototyping) in these two publications:

- http://www.sciencedirect.com/science/article/pii/S092188901300153X

- http://link.springer.com/chapter/10.1007/978-3-662-44468-9_52

Best regards,

Martino

[Dejan Pangercic]

Hi Martino, 

can you comment on how do you normally design your systems? Do you have real-time stuff running on uC like STM32 and high-level stuff (e.g. decision making, CV, etc.) on a separate e.g. Linux computer or do you pack everything on an STM32 like uC?

We've done some testing over the spring with the former setup where we'd do visual servoing with the control part on a uC with RTOS and target tracking on a Linux computer with stock kernel. The problems were mainly due to the dynamics of these 2 different system. Processes on Linux system for instance can not guarantee deterministic execution times and the delays then got introduced on the communication channel which then in turn affected the real time control loop on the uC. And it was really difficult to debug both systems at the same time.

How is community's feel on this topics?

D.

[Martino Migliavacca]

Hi Dejan,

On 11 July 2015 at 17:33, Dejan Pangercic <dejan.p...@gmail.com> wrote:

Hi Martino, 

can you comment on how do you normally design your systems? Do you have real-time stuff running on uC like STM32 and high-level stuff (e.g. decision making, CV, etc.) on a separate e.g. Linux computer or do you pack everything on an STM32 like uC?

Exactly. We run all low-level motion control on hardware boards (they are based on STM32): motor control, forward/inverse kinematics, balance control (for balancing robots), and some times basic collision avoidance (just inhibit motion setpoints that would cause a collision).

 

We've done some testing over the spring with the former setup where we'd do visual servoing with the control part on a uC with RTOS and target tracking on a Linux computer with stock kernel. The problems were mainly due to the dynamics of these 2 different system. Processes on Linux system for instance can not guarantee deterministic execution times and the delays then got introduced on the communication channel which then in turn affected the real time control loop on the uC.

This for sure is a problem, and moving *some* of the control loops to the real-time hardware mitigates it, but I understand that with visual servoing the control loop also runs on the external computer introducing jitter. I've never worked with visual servoing, our robots are mainly mobile platforms so we usually deal with speed setpoints, and given the slow dynamics of the systems we usually do not observe problems. The platform subscribes a /cmd_vel like topic (via uROSnode or via rosserial) and executes the commands, giving back odometry.

But for sure real-time is a concern, and ROS, as far as i know, did not deal with this up to now (I remember that at ROSCON 2013 that there was some discussion about real-time ROS but apparently not so many people saw this as a major concern).

And it was really difficult to debug both systems at the same time.

One of the purpose of R2P was exactly to give ready-to-use hardware modules which should not need additional debugging, so you can focus on high level stuff and debug only that :)

How is community's feel on this topics?

From my point of view (but I am much closer to the hardware than to the high-level software) real-time is a critical aspect, and it should be seriously addressed by ROS. I don't know if just relying on some real-time variant of linux would help, or if a real-time communication middleware is needed.

Martino

D.

On Friday, July 10, 2015 at 12:10:33 PM UTC+2, Martino Migliavacca wrote:

Hi,

you can publish messages at any rate, there are no constraints. We usually have publishers running in different threads, and the thread loop determines the publish rate.

uROSnode is a ROS communication library, inter-thread communication is handled by the underlaying OS. We currently support ChibiOS/RT (the RTOS we use on our boards) and Posix.

Moreover, we developed a middleware targeted at microcontrollers which handles all the inter-thread and board-to-board communication (over CAN bus, with real-time capabilities), so all of that is not handled by uROSnode, which is used to interface the real-time CAN bus network to ROS systems.

We have a set of hardware modules (motor controllers, sensor interfaces, IMU, communication interfaces, etc etc) which we use to control our robots (low-level control), while high-level control is implemented in ROS by using uROSnode.

I've briefly looked into DDS and I believe it will be really hard to port to microcontrollers, but I did not investigate deeply. The only "embedded" implementations I found had requirements not compatibile with RAM and Flash of STM32-like microcontrollers.

You can read about the system (it is called R2P - Rapid Robot Prototyping) in these two publications:

- http://www.sciencedirect.com/science/article/pii/S092188901300153X

- http://link.springer.com/chapter/10.1007/978-3-662-44468-9_52

Best regards,

Martino

[Víctor MV]

I've briefly looked into DDS and I believe it will be really hard to port to microcontrollers, but I did not investigate deeply. The only "embedded" implementations I found had requirements not compatibile with RAM and Flash of STM32-like microcontrollers.

Hi Martino,

The OSRF made a prototype of ROS 2 on an STM32-like microcontroller and ported a whole DDS implementation on top of NuttX RTOS (which already provides a pseudo-POSIX interface). The work is available at https://github.com/ros2/ros2_embedded_nuttx.

Note that the board used additional 2 MB SRAM but there's a lot of room for improvement. Stripping down Tinq (the actual DDS implementation ported) to a bare minimum (e.g. rtps) can definitely make it fit into most of the STM32 lines of microcontrollers. 

Bests,

[Martino Migliavacca]

Thanks Victor, this sounds really interesting, in particular if it will run on STM32 without external RAM after improvements.

I'll take a look for sure!

Best regards,
Martino

--

[smori...@gmail.com]

Hello Gunay,

Could you kindly tell me which license (BSD, MIT or so on) is applied for your repository above?
I’m interested in your ROS middleware and want to reuse it for our project.

Best regards,
Shoji Morita