diff --git a/dongfang_qgroundcontrol_notes.txt b/dongfang_qgroundcontrol_notes.txt new file mode 100644 index 0000000..40fcc46 --- /dev/null +++ b/dongfang_qgroundcontrol_notes.txt @@ -0,0 +1,90 @@ +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* 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? + diff --git a/dongfang_qgroundcontrol_wishlist.txt b/dongfang_qgroundcontrol_wishlist.txt new file mode 100644 index 0000000..f55ba1d --- /dev/null +++ b/dongfang_qgroundcontrol_wishlist.txt @@ -0,0 +1,23 @@ +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.