Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove localisation logic from Flotilla #1850

Open
andchiind opened this issue Dec 6, 2024 · 0 comments · May be fixed by #1868
Open

Remove localisation logic from Flotilla #1850

andchiind opened this issue Dec 6, 2024 · 0 comments · May be fixed by #1868
Assignees
Labels
backend Backend related functionality epic improvement Improvement to existing functionality Northern Lights

Comments

@andchiind
Copy link
Contributor

andchiind commented Dec 6, 2024

Describe the improvement you would like to see
Localisation status for robots should be treated like any other robot status from ISAR. If a robot is not Offline or Delocalised, it should be assumed to be localised.

How will this change existing functionality?
Localisation (the state if the robot is localized or not) will still be stored in Flotilla, but it will be regarded as telemetry from ISAR, for information not to control the mission flow. As a result, we should no longer set it as a value in Flotilla besides in MQTT event handler, and we should not base mission start logic on it. It a robot is Available, we should assume that it's ready to run missions. Of course, if the mission failure reason for a robot is stated as being caused by delocalisation, we do not need to try to schedule the following missions, but if we do they will fail anyways.

In short, Localisation will be handled by ISAR. We should still send "dock" flags on missions when the queue is empty, as this is not something ISAR is aware of, but ISAR will be aware of when to undock the robot. We also no longer need to send a localisation pose in missions, as this should be handled in ISAR, but this can be relegated to another issue/PR.

ISAR can know its own "dock" position, set in configuration per instance. We can assume only one dock/home/localization position per robot for now.

How will this improvement affect the current Threat Model?
N/A

@andchiind andchiind added improvement Improvement to existing functionality backend Backend related functionality Northern Lights labels Dec 6, 2024
@tsundvoll tsundvoll added the epic label Dec 9, 2024
@andchiind andchiind linked a pull request Dec 12, 2024 that will close this issue
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend Backend related functionality epic improvement Improvement to existing functionality Northern Lights
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants