Abstract
One of the main challenges in verifying robotic systems is its asynchronous interaction with an unstructured environment, observed by imperfect sensors. Autonomous robot systems usually require some language to support task-level control. This paper presents an effective approach to apply formal verification methods for that kind of language. A main contribution of this method is to avoid modeling the robotic system with a specific formalism. The approach translates the task-level control models into a Petri net (PN) based representation. This is used to define new methods to analyze some task properties such as liveness, deadlock-freeness and terminability. The approach has been applied to the Task Description Language (TDL) and it is illustrated by experiments. The final goal is to create new tools within the application development environment to include formal verification as part of the normal software development cycle. The TDL to PN translator uses the Petri Net Markup Language (PNML) as its file format. This format permits interoperability with other Petri net tools that can also be used to analyze the PNs.
Highlights
Autonomous robotic systems tend to be complex because they need to interact asynchronously and in real time with uncertain and dynamic environments
The research presented in this paper focuses on the executive part of the control architecture that deals with the higher-level tasks [14]
We use a hierarchical representation of Petri nets by obtaining a Petri net for the main program and all the Petri nets for the goals spawned in the main and subsequent goals. This decomposition into simpler Petri nets can simplify the analysis if we prove that these properties are preserved by the decomposition
Summary
Autonomous robotic systems tend to be complex because they need to interact asynchronously and in real time with uncertain and dynamic environments. Task-level control programs in autonomous robot applications are usually complex, difficult to develop and debug [1]. Some actions need to be scheduled to execute at an absolute or relative time point. One action should be started after another action finishes. Another difficulty is that some actions might need to be monitored and some exceptions require to be handled. Some of these exceptions might need to be managed at different levels
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
