Commit 0eaf806f authored by Lorenz Meier's avatar Lorenz Meier

Removed files that should not have been comitted in the first place

parent 123707a9
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
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?
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.
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.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment