Skip to content

Latest commit

 

History

History
9 lines (7 loc) · 2.14 KB

File metadata and controls

9 lines (7 loc) · 2.14 KB

Limitations

  • Current example applications (e.g. the ROSIMU demo) publish at about 3 Hz. The reason behind this matter is the 4 threads (one for each locator blocked in a recvfrom call) simulating UDP polling (refer to threading). Without these 4 threads (which are needed for DDS communication), the code has proved to be able to publish at up to 50 Hz. This limitation should be address by implementing real UDP poll() or select() support. Refer to nuttx official repository/TODO, particularly the UDP READ-AHEAD? and NO POLL/SELECT ON UDP SOCKETS tickets.
  • Reception of packages: As mentioned before, this prototype implements UDP poll() using 4 threads (one for each locator) blocked "reading" all the time. If a package arrives and there's nobody reading (the corresponding thread should be scheduled at that time) then the kernel dumps the package. This causes that only "some packages" coming from the publising side will be received and processed properly. This log presents the rosimu_subscriber application running in the embedded board and receiving packages from the Desktop (running OpenSplice). The header.seq should increment by one every time however we are getting 4, 11, 19, 28, ...
  • Tinq QoS parameters hasn't been tested. There's no guarantee that it'll work.
  • In NuttX we can't simultaneously read and write from a socket (refer to brunodebus/tinq-core#7 (comment)). Tinq has been implemented with this assumption in mind thereby a set of fixes were applied to make it work.
  • The implementation does not support different message types with the same topic name (issue). Refer to the discussion.
  • Tinq implementation does not interoperate with RTI's Connext. Refer to the issue.