Robot Action Lessons: Canceling and Canceled States

Robot Action Lessons should distinguish an accepted cancellation request from a goal reported as canceled. ROS 2 uses separate interface descriptions for these stages. A successful CancelGoal response can identify goals that have entered CANCELING; that response is not itself the terminal CANCELED status. This article reads Jazzy definitions through a fictional course transcript. It sends no cancellation request, connects to no robot and makes no statement about physical stopping.

Read what a successful cancellation response says

The official CancelGoal service definition describes ERROR_NONE as a request accepted without errors. Its accompanying comments state that one or more goals have transitioned to CANCELING and that the goals_canceling list is not empty. A learning summary should preserve that precise state name rather than replace it with a broader completed label.

For a fictional transcript, suppose a response excerpt contains the successful return code and a listed goal. A student can describe what the definition attributes to that response: acceptance and a transition into cancellation handling. The student should not silently add a later state that the excerpt does not show. The exercise is about reading retained text, rather than asking an action server to do anything.

Compare the two state descriptions directly

The official GoalStatus definition distinguishes STATUS_CANCELING from STATUS_CANCELED. CANCELING describes a client cancellation request accepted by the action server. CANCELED describes the goal as canceled after an external request from an action client. Their separate names and descriptions should remain visible in the course glossary.

A caption saying cancellation accepted can therefore be accurate for one excerpt without establishing that another excerpt reports the goal canceled. This is a relationship between documented software states. It does not specify how long cancellation takes, what a particular application does during that interval or what an attached machine physically does.

Flow distinguishes cancellation response acceptance, canceling state and separately supplied final evidence. — Read the cancellation evidence. Document-reading path; no hardware operation is illustrated. Source: Zhilianhai editorial desk, original AI-assisted illustration; no real product, event or measured data depicted.

Keep goal identity beside the state evidence

The service response includes goals_canceling entries, and GoalStatus carries goal information together with its state. When a fictional teaching pack contains several goals, the learner needs the association between each excerpt and its goal. A cancellation response about one goal cannot fill a missing final-status record for another simply because both were discussed in the same session.

A useful transcript annotation can identify which supplied excerpt is a service response and which is a goal-status record. It can then preserve the goal association already provided. This article supplies no actual goal identifier, request selector or service call. If the course pack omits that association, the annotation should say what is missing instead of manufacturing a complete sequence.

The return-code field and the goal's state field also belong to different definitions. A number in one field should be interpreted using that field's constants, not a numeric constant copied from the other. Retaining the names avoids turning two different enumerations into one unlabelled status code column.

Comparison separates canceling and canceled states with a physical-evidence boundary. — Two cancellation stages. A cancellation response alone is not a physical stop observation. Source: Zhilianhai editorial desk, original AI-assisted illustration; no real product, event or measured data depicted.

The service definition also distinguishes a goal already in a terminal state from a request accepted for cancellation. An excerpt reporting the former needs its own return-code description. It should not be renamed successful cancellation simply because further cancellation is unavailable. The student can identify which defined response was supplied while leaving the goal's particular terminal outcome to its separately retained status evidence.

Handle incomplete transcripts without inventing completion

If the fictional pack ends after the accepted cancellation response, a bounded conclusion says that no later goal-status evidence was supplied. It should not pronounce a cancellation failure merely because the transcript is incomplete. The absent material could reflect the pack's selection rather than the action server's actual later behavior.

Conversely, a later excerpt described as CANCELED needs to be associated with the relevant goal and context before it is joined to the earlier response. The definition explains the state vocabulary, but a document reader still needs the retained relationship between records. No actual trace has been inspected or sequence reconstructed here.

Keep the lesson separate from physical stop claims

The cited interfaces define action communication and goal states. They do not serve as an emergency-stop interface or an observation that all physical movement ceased. A course note should not replace machine-specific evidence with a software status label. This article does not provide a stopping procedure, controller behavior guarantee or permission to approach equipment.

A revision that changes the wording from canceled to cancellation accepted should be recorded as a correction of the lesson's explanation. It does not mean that the real application was rerun or that a robot changed state. Any actual test would need its own record, conditions and appropriate account of what was observed.