Separate interop from mission commander

[rijesha]

Mission Commander should be a standalone application for controlling missions. Interop should also be standalone potentially communicating with mission commander over the ivyBus. Doing so would also make shutdown of mission commander simpler.

[Lionfrog]

Started in a buggy state in https://github.com/uaarg/missioncommander/commit/a3125dd7ade8c2b69f19127ee079739dd8763e55

Working on pulling interop code out from the rest of mission commander , getting it running on its own, and then work on getting it to run from its own separate folder.

I'm working as if its critical that InterIvy can work regardless if MissionCommander is on (and vice-versa).

@rijesha @cxiao InterIvy is my working name, any other suggestions??

[rijesha]

How about we make the interop server another ivy client.
It is a standalone program that broadcasts/listens to the ivybus.

Mission commander only needs obstacle information from the ivy bus. The ivybus can send that information and mission commander could listen and process it if need be.

[Lionfrog]

That's what I'm thinking we do, as the Interop - Ivy bus connection should be its own separate program.

Through what I have so far there are 2 things we were communicating from MC to the InterIvy code.

1. Ground altitude used to send telemetry data. I'll make InterIvy pull this from the flight plan if MC isn't up yet.
2. Waypoint objects for moving waypoints to interop positions (eg. LKN, opArea, searchArea ect). We could also get InterIvy to run the same database code to pull this from, but this seems like a lot of copied code. I wonder if there was a cleaner way to get this stuff.

[cxiao]

For 1, we can broadcast the ground altitude over the Ivy bus using Mission Commander. I can see other pieces of software (e.g. Pigeon) needing this as well, and obtaining this information from a shared Ivy bus.

For 2, isn't it just the Waypoint ID that's needed for constructing an Ivy message that moves the correct waypoints? If so, we only need to have InterIvy be able to a) parse flight plan XML files, and b) have the logic to construct an Ivy message. We could break xmlparser.py and waypointobject.py out into a shared module between Mission Commander and InterIvy. I'm not sure if there's any additional state that Mission Commander keeps that InterIvy would need to know about, beyond what they both load initially from the flight plan. All other important state changes should be communicated over the Ivy bus.

[Lionfrog]

2. Correct, thats what I'll do. But is there a gain to having that code broken into ANOTHER module. Thats like a module in a module in a module in paparazzi. I can break it out so that if pigeon wants the same info it'll be easy to add the folder.