Comments (2)
This is really interesting! So generally speaking, RTPS is extremely flexible and you can use whatever serialization you want; there is a field in the message headers where you specify the payload serialization scheme.
That being said, the spec calls out CDR (either big- or little-endian) as the most common serialization scheme, and defines constants to indicate CDR with either byte ordering. CDR itself is very compact; with integer fields like in the low_bandwidth
spreadsheet referenced on that issue, it's just like having a (memory-aligned) struct. I hand-crafted a serializer for the ROS2 IMU message to make sure I was understanding that correctly:
https://github.com/ros2/freertps/blob/master/apps/imu/imu.c
once the variable-length string "frame ID" in the ROS2 header is serialized using CDR (by just prepending a length field and padding to the end for 32-bit alignment), the "serialization" is just a memcpy:
https://github.com/ros2/freertps/blob/master/apps/imu/imu.c#L83
So CDR itself seems like a reasonable candidate for low-bandwidth comms, since CDR isn't really adding anything to the size. However, the RTPS headers do add a decent amount of overhead. I think that those headers are necessary for the original design goals of RTPS: an extremely flexible publish-subscribe system that can be globally routed over the Internet (hence the framing with UDP/IP, the very long ID fields, etc.). To try to understand the amount of overhead better, a few weeks ago I made a spreadsheet showing the various protocol stackups when using RTPS over UDPv4, and as you can see, there are quite a few fields before and after the cyan data payload. Maybe some of that is unnecessary (e.g., perhaps you don't need the heartbeat submessage for best-effort senders?) but I'm not quite sure yet.
Anyway, I think for really low-bandwidth connections, we'd want to define a mapping of RTPS onto this domain that gets rid of a lot of the fields that aren't necessary for low-bandwidth local-link messaging such as point-to-point radios, short inter-board UART links, rs485, full-speed USB, and so on. I think with a bit of trial and error design hacking, we could get the header down to just a few bytes, and if the application required or wanted global routing (i.e., a microcontroller talking over UART to a nearby POSIX machine with an Ethernet interface), a generic "gateway" program could "inflate" these super-abbreviated headers into the full RTPS/UDPv4 headers, copy the CDR payload into the message, and re-transmit to the LAN/WAN. Going the other direction could be done similarly (i.e., the POSIX gateway would condense the RTPS/UDPv4 headers into the bare minimum needed for the small-microcontroller client and forward the payload over the low-bandwidth local link).
This is definitely on our roadmap, since many (most?) microcontroller applications don't have Ethernet, and we want a principled, generic way to communicate with all of them. I don't have a specific target date though, since we're still working on cleaning up the FreeRTPS core and its integration with ROS2 messaging, so that instead of hand-crafting serializers like in that hacky IMU demo, we'll auto-generate them in a way that is conscious of memory-constrained, all-static systems, etc.
Cheers
from freertps.
Thank you!
You are right, headers require too much space, but i hope that it might be reduced under to ~24 bytes.
But CDR is good, almost same as plain packed struct.
from freertps.
Related Issues (20)
- cross-compile, burn, and run minimalist listener example on stm32f7-discovery board
- support multiple stm32 boards
- minimalist std_interfaces::String best-effort RTPS publisher from userland HOT 1
- sensor_Interfaces::Imu publisher for stm32f4-discovery
- std_interfaces::UInt32 subscriber for LEDs on multiple embedded boards
- rmw_freertps HOT 4
- support SAMV71
- ros2 demo platform HOT 2
- data writes not working in talker HOT 3
- Automated test(s) HOT 5
- i2c support HOT 1
- freertps compile fail "Policy CMP0057 not set" HOT 9
- make doen't work HOT 1
- SEDP for subscribers
- make build system capable of targeting both x86 and STM32
- Get Connext talking to FreeRTPS
- SEDP for publishers
- figure out double-subscribe bug HOT 5
- parse DATA messages in userland
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from freertps.