This is the roadmap page for starmac-ros-pkg. Everyone is encouraged to edit this page. However, the mailing list is a better place for back-and-forth discussions. Consider this page like a whiteboard for brainstorming.

Suggestion: Subscribe yourself to this page (set up your notification preferences to receive emails).

Releases

Need a plan for releases.

• What kind of model to follow?
• Track ROS releases?
• How to handle non-ROS dependency versioning?
• Version numbering?
• Binary releases -- probably low priority given expected user community.

Future Work

Here in no particular order are some things that could be done:

• Multiple vehicles
  • multiple masters? which scheme to use?

  • tf conventions?

• REP conformity

  • REP 103 (units of measure)

  • REP 105 (coordinate frames)

• Outdoor flight

• Logging: log by default a minimal set of topics such as /diagnostics to a bagfile (see REP 107)

• Visualization improvements
  • quadrotor mesh model (generic and for specific vehicles)
  • display ground track
  • display commanded
• "Ground station" GUI
  • Opinion (Pat):
    • GUIs (especially big ones) are a huge time sink in general, are hard to get right, and almost always end up needing to be supplemented by other tools anyway.

    • However there are likely some existing projects that could be used. http://www.qgroundcontrol.org/QGroundControl for one.. but perhaps it is tied too closely to MAVLink?

    • Part of the difficulty is that everyone's needs can be very different. This is true even among members of the same research lab.

    • My sense is that if any GUIs are to be developed for starmac-ros-pkg specifically, they should be discrete, modular components. Probably using QT, especially given the impending move to QT for the ROS GUI tools. In an ideal world, one would have the choice of a bunch of custom widgets to put together with stock ones in QT Designer to make a GUI that's right for one's specific project.

    • Near term, though, it might be worth writing a very minimal dashboard-type GUI that provides only the most important information, like "is the vehicle flying"?, "what is the battery level"?, "what is the current control mode"? And most importantly, a big red E-stop button in case the user doesn't otherwise know how to issue an e-stop...

• 'Safety Pilot'
  • Safety behaviors that kick in automatically under certain conditions, so that you don't have to add such features to each individual control mode. Could include:
    • When flying with Vicon, a defined volume within which the vehicle must remain--if it leaves this region (or is about to), then transition to hover mode.
    • add other ideas here..

  • Implemented as a node running independently of the rest of the system (though perhaps in as a nodelet in the same process as asctec_autopilot and asctec_proc since it needs them to do anything meaningful)