design
design copied to clipboard
Lifecycle design
@SteveMacenski Since Nav2 is a heavy user of lifecycle, would you mind giving this a look? We'd be very interested in your feedback.
It'll be next week at this point for me, but yes I will! The only thing I see immediately that I would ask a question about is the throwing of exceptions. Who, if anyone, is able to catch that error in the state transition? It would be unacceptable if that was uncatchable by the user / rclcpp such that the server crashed.
@clalancette @SteveMacenski This wasn't supposed to be a public-facing PR, but rather to first go through a last round of internal reviews (I should have targeted our fork rather than the official repo)
I won't take it down but I converted it to draft.
More general thoughts
- I'm not sure why ROS 2 is in code-styling, its quite distracting.
- I don't know if Persistent Entities is already part of this technology's lexicon. If its not, I might suggest changing it. I'm not sure it describes well what you want to differentiate. May I suggest Unmanaged Entities.
- The T:Shutdown in the error processing marked half of the diagram is out of place and should be on the right hand side
- Also, the diagram should be inverted, the left (first) half should be the main state machine. Its confusing to inspect it in reverse
- I think some more of the concepts needs to be introduced up top before going into describing all the states. I don't think we should wait until introducing all the transition states to even tell someone what that means. Same with primary states, although its less an issue since its the first up. I think there needs to be a concepts section after Background to talk about the types of states like you do types of entities. Then you can lump all the states + expected behaviors in one section.
There are lots of things in here that are overly technocratic that even someone that uses lifecycle nodes every day it takes me 2-3 sometimes 4 times reading through to actually understand what you mean. I'd recommend looking over the original document where the same points were addressed previously that were sufficiently technical (might benefit from more detail) but written in language that I can grokk.