Hi,
Yeah OK that would be a solution to have different UAS subclasses
reconstruct the distinction between eg. air and ground speed from the
MAVLink data.
A UAS subclass ArduPlane cound emit an airspeedChanged when receiving eg,
the airspeed of the VFR_HUD message. ArduCopter actually sends its ground
speed in the airspeed field. Its representation in ArduCopter : UAS on the
groundstation should emit no airspeedChanged (because it IS not airspeed)


On Mon, Jun 3, 2013 at 11:14 PM, Lorenz Meier <notifications@github.com>wrote:

> In src/uas/UAS.cc:
>
> >              emit globalPositionChanged(this, getLatitude(), getLongitude(), getAltitude(), time);
> > -            emit speedChanged(this, speedX, speedY, speedZ, time);
> > +            // dongfang: The altitude is GPS altitude. Bugger. It needs to be changed to primary.
> > +            emit altitudeChanged(this, GPS_ALTITUDE, getAltitude(), time);
> > +            // We had some frame mess here, global and local axes were mixed.
> > +            emit velocityChanged(this, MAV_FRAME_GLOBAL, speedX, speedY, speedZ, time);
> > +
> > +            double groundspeed = qSqrt(speedX*speedX+speedY*speedY);
> > +            emit speedChanged(this, GROUNDSPEED_BY_GPS, groundspeed, time);
>
> I think its ok if you make a primary speed signal for that case then and
> let the UAS object (or a subclass of it) decide what it should emit. E.g.
> it could even read a parameter from the UAS to decide which one should be
> used and emitted. The rationale is to separate UI from UAS code, as its
> easier to maintain.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/mavlink/qgroundcontrol/pull/265/files#r4510285>
> .
>