dongfang notes added

dongfang_qgroundcontrol_notes.txt

+From where is the 3D mouse used?
+
+
+Comm folder:
+============
+
+LinkInterface is a QThread. Appears to describe an interface on the host system (TCP port, serial port, ....).
+  Does it suppport multiple connections?
+SerialLinkInterface: Extension of above
+SerialLink: Implementation
+
+XBeeLinkInterface: Extension of LinkInterface (but without other serial stuff than baudrate, is the rest assumed?)
+XBeeLink: Implementation (with address resetting probably it's Series 1)
+
+UDPLink: UDP implementation. Port is defaulted.
+
+MAVLinkSimulationLink: Simulation/dummy implementation of LinkInterface. Does some file IO.
+MAVLinkSimulationUAV:  Simulation/dummy basic (remote) UAV state (minus mission state) for MAVLinkSimulationLink.
+MAVLinkSimulationWaypointPlanner: imulation/dummy basic (remote) UAV mission state for MAVLinkSimulationLink.
+
+
+ProtocolInterface describes a protocol. Major method:
+    virtual void receiveBytes(LinkInterface *link, QByteArray b) = 0;
+
+MavlinkProtocol: MAVLink implementation of ProtocolInterface
+
+
+Parameter: Identity of a parameter (the value types are not handled here. Oddly there is no type metainfo either)
+ParameterList: Is pretty much what the name impiles.
+QGCParamID: Wrapper if parameter text IDs, conversion to byte* and back
+
+QGCHilLink: Link to a HIL external system
+    QCGFlightGearLink, QGCJSBSimLink, QGCXPlaneLink : Implementations of QGCHilLink
+
+
+QGCMAVLink: Nothing more than in include to raw mavlink.h
+
+
+input folder:
+=============
+Some exotic input devices
+
+
+
+uas folder:
+===========
+UAS.h: Local UAV model. Claims to support some sort of RPC. Uses some properties with notifications. Assumes MAVLink.
+Some methods:
+    int getUASID() const; // the systemId
+    QList<LinkInterface*>* getLinks(); // it knows its links
+
+    virtual void receiveMessage(LinkInterface* link, mavlink_message_t message);
+
+    float receiveDropRate;      ///< Percentage of packets that were dropped on the MAV's receiving link (from GCS and other MAVs)
+    float sendDropRate;         ///< Percentage of packets that were not received from the MAV by the GCS
+
+Some fields:
+    bool positionLock;          ///< Status if position information is available or not
+    double localX;  // (what is this?)
+    double localY;
+    double localZ;
+    double latitude;            ///< Global latitude as estimated by position estimator
+    double longitude;           ///< Global longitude as estimated by position estimator
+    double altitude;            ///< Global altitude as estimated by position estimator
+    double satelliteCount;      ///< Number of satellites visible to raw GPS
+    bool globalEstimatorActive; ///< Global position estimator present, do not fall back to GPS raw for position
+    double latitude_gps;        ///< Global latitude as estimated by raw GPS
+    double longitude_gps;       ///< Global longitude as estimated by raw GPS
+    double altitude_gps;        ///< Global altitude as estimated by raw GPS
+
+    and lots ans lots more...
+
+
+*MAV.h: Implementations of UAS
+
+
+QGCUASParamManager.h: A mixture of a widget and a parameter up/download state machine. Has a reference to its associated UAV.
+
+UASWaypointManager: API to waypoint / mission control. Not a widget. Has a reference to its associated UAV.
+
+UASManager.h: Singleton interface to all UASs on all interfaces. Maintains a single selected/active UAS.
+
+Ideas to do
+TCPLink
+XBee Series2 implementation
+Less stress on uplink
+Get rid of hardcoded SystemId of 255
+Quick View should print all altitudes (GPS, mix, ground and/or home), letting user see errors.
+Console debugging is hopefully removed?
+

dongfang_qgroundcontrol_wishlist.txt

+Major
+1) Absolute altitude should absolutely work. Also in face of bad GPS init.
+   How does the mission planning part work with that, how is alt. stored in waypoints?
+   When is home altitude stored in the UAV?
+
+2) Some people have worse datalinks than average - eg. slow or noisy telemetry. GPRS data also easily gets
+   flooded. All data rates should be configurable and uplinks eased off a little.
+
+3) Some streams should be sent always even if not in use. For example using RC override and then stopping
+   using it: If the UAV does not received the final RC override message with zero values for all channels,
+   it will not get out of RC override. A solution is to make the message non final, repeating it every
+   now and then.
+
+Minor
+1) I would like to see initial dummy values for eg. battery voltage go away and be replaced by "unknown".
+   Dummy values confuse, you won't know if your sensors and link are working or not.
+
+2) Suggestion if the DO_JUMP behavior of APM today (where DO_JUMP requires a waypoint command after it):
+   Modify APM code so DO_JUMP is regarded a navigation command. Make non navigation commands appear in
+   planning as sub commands of navigation commands (indent them). Easier to understand.
+
+3) Old style audio with signals/bells/beeps / Morse may be prefered by some. Maybe add slots'n'signals for
+   all audio and different implementation types (speech, beep, ...). Or a generic operator messaging thing.