Added article about ROS 2.0 in realtime #35
Conversation
| In general, an operating system can guarantee that the tasks it handles for the developer, such as | ||
| thread scheduling, are deterministic, but the OS may not guarantee that the developer's code will | ||
| run in real-time. Therefore, it is up to the developer to know what the determinstic guarantees | ||
| of an existing system are, and what she must do to write hard real-time code on top of the OS. |
|
In general please start each sentence on a new line. It simply prevents changes to one location to propagate through a whole paragraph and result in huge diffs. |
| as the variable deviation between a task's deadline and its actual time of completion. A more jittery | ||
| system is less deterministic, less predictable, and less real-time. Though in practice it is impossible | ||
| to completely eliminate jitter from a real-time system, it is a worthy goal to determine a hard upper bound | ||
| for jitter. |
There was a problem hiding this comment.
Can we just reference existing definition(s) of real-time rather than describing it on our own?
There was a problem hiding this comment.
I tried to summarize the existing definition in this document. Do you prefer a verbatim quote from an existing document?
There was a problem hiding this comment.
I would just reference external resources. Less text = less to maintain.
There was a problem hiding this comment.
Dissenting opinion: The reference text shouldn't be changing and it is annoying to have to open and read another (potentially large) document to get the meaning. I think it is totally appropriate to quote a snippet of the referenced text or summarize it in this document to make it more self contained. Part of the job of the document is to distill the subject matter into an easy to digest form.
There was a problem hiding this comment.
dissent +1: I think it is a nice summary
jacquelinekay
added
in review
| </div> | ||
|
|
||
| Original Author: {{ page.author }} | ||
|
|
There was a problem hiding this comment.
It would be good to start a summary of the document, stating its scope, goal and structure.
|
General comment. How do you feel about citing references in the running text?. It can quickly become hard to identify where the reference is used in the text. |
| memset(dummy, 0, MAX_SAFE_STACK); | ||
| ``` | ||
|
|
||
| `mlockall` is a Linux system call for locking the process's virtual address space into RAM, preventing the memory that will be accessed by the process from getting paged into swap space. |
There was a problem hiding this comment.
mlockall hyperlink or [ref], for convenient jumping to the source?.
| Create threads at the start of the program. | ||
| This confines the nondeterministic overhead of thread allocation to a defined point in the process. | ||
|
|
||
| Create high priority (but not 99) threads with a FIFO or Round Robin scheduler. |
There was a problem hiding this comment.
or SCHED_DEADLINE, since version 3.14. Source.
|
+1 on all comments by @adolfo-rt, especially those about what appear to be opinions. The RT-field has some very clear definitions this article could re-use, so why not do that. Also +1 on mentioning Xenomai and all its tools and infrastructure. This may be personal, but I like the co-kernel approach - and the strict separation between primary and secondary modes that it allows - as well. |
|
Thanks for all the comments, @adolfo-rt! I am addressing them in the text now. The Markdown/Jekyll system we have set up for these documents doesn't support "proper" inline citations, but I'll probably figure out a numbered footnote system for citations, or just add links to sources in the text. We could consider adding more citations to the other ROS 2 design documents, too, but this article in particular synthesizes a lot of established information that is not common knowledge for the average software engineer. Thanks too for your feedback, @gavanderhoorn. I'll look into setting up a Xenomai machine for the purposes of ROS 2 performance testing. |
@jacquelinekay: perhaps the OSADL can help with that? At the 3rd ROS-Industrial conference one of the presentations included an overview of the kind of software testing they do. Testing real-time systems / applications across a wide variety of HW and SW was part of that. I can't link to the slides, but the OSADL Realtime QA Farm page seems to give a good overview of what he presented. If you really (or also) want to do it yourself: the MachineKit community has pre-built Xenomai debian kernel pkgs that could save you some work. |
|
@adolfo-rt I've incorporated your suggestions in 0990fa3 and 2a13eea. |
| * Quality of Service: The overall performance of a network. Includes factors such as bandwith, throughput, availability, jitter, latency, and error rates. | ||
|
|
||
| Real-time software guarantees correct computation at the correct time. | ||
| Hard real-time software systems have a set of strict deadlines, and missing a deadline is considered a system failure. |
There was a problem hiding this comment.
Add a line break to separate hard real-time definition to a new paragraph. Also, consider emphasizing the hard, soft, and firm real-time initalics.
|
I added an additional round of minor comments. The document is looking good 👍 |
| TODO: How can ROS 2 be real-time friendly and cross-platform? | ||
| Much of the research in this document focuses on achieving real-time on POSIX-compliant Linux systems. | ||
|
|
||
| ## Implementation strategy |
There was a problem hiding this comment.
Maybe worth mentioning explicitly. Using ROS interfaces should be real-time safe (at least within a limited context, like intra-process), setting them up needs not be. In particular, for pub-sub with dynamic-sized data, it should be possible to pre-allocate resources (e.g., resize payload arrays) at setup time.
There was a problem hiding this comment.
eb93b9a (and other comments)
|
+1 |
1 similar comment
|
+1 |
Added article about ROS 2.0 in realtime
This article summarizes my research into real-time software development techniques, with a focus on C/C++ running on RTLinux or a Linux-based RTOS. It lays out a tentative plan for how to benchmark real-time performance in ROS 2.0 and how existing and future code in the core communication stack can be made real-time-safe.