Selecting terrain data on surverys was generating an empty survey if the polygon
was on an area where QGC doesn't have terrain height info about.
This is because QGC was waiting on terrain info to build the path on such surveys,
which is not needed at all, because terrain frame just specifies an altitude above
terrain, and relies on the vehicle for being able to calculate that height, by terrain
database or by altitude sensors, having terrain height information is not needed at all
to generate this kind of surveys
This fixes the warning that I get with GCC 11.3:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:95:34:
warning: ‘__builtin_strncpy’ writing 50 bytes into a region of size 24 overflows the destination [-Wstringop-overflow=]
95 | return __builtin___strncpy_chk (__dest, __src, __len,
| ^
/usr/include/x86_64-linux-gnu/bits/string_fortified.h: In member function ‘_handleStatusText’:
../Qt/5.15.2/gcc_64/include/QtCore/qarraydata.h:129:8: note: destination object ‘<anonymous>’ of size 24
129 | struct QTypedArrayData
| ^
Signed-off-by: Julian Oes <julian@oes.ch>
* Popup smaller
* Text indicates these are Vehicle Messages
* If there are additional messages which come in after display closing the popup will dropdown the Message Indicator in the toolbar
Status text messages were being sent too early in the creation of the MockLink. This would cause the ui to not see them. Making the whole thing useless for testing.
It was pointing to an Auterion repo before. This
Auterion repo didn't have any modification over
the original, it has been like that for 3 years,
so it makes sense to just point to the original one
The current implementation displays two different distances by the same
name. One of the distances is actually the distance to the previous
waypoint. For the user its "hard" to tell which one is which. I try to
resolve this with a more descriptive label for the distance to the
previous waypoint.
An alternative is maybe to rename the other distance to total distance
or total mission distance.
This enables two UI features when connected to an ArduPilot vehicle:
1. click the map in the Fly View and send an "ROI at Location" command; and
2. add an ROI as part of a Mission Plan.
Note that there is no way to determine if an ArduPilot build will accept
these commands. The commands will be accepted if the current connected
ArduPilot vehicle has both:
1. the Mount driver included (i.e. compiled with HAL_MOUNT_ENABLED); and
2. a Mount driver enabled (via the MNTn_TYPE parameter)
If ROIs are not supported, the ArduPilot vehicle will respond with a
MAV_RESULT_UNSUPPORTED command ack message.
Addresses #10640.
When there are multiple vehicles, and you select a vehicle, the joystick should switch over to the newly active vehicle, and only the active vehicle (so that joystick inputs are not sent to a vehicle you do not intend to control).
To resolve this, we connect Vehicle to the activeVehicleAvailableChanged and activeVehicleChanged signals produced by the MultiVehicleManager. ALL vehicles disable joystick when activeVehicleAvailableChanged(false), because this signals when there is no longer an active vehicle available. When activeVehicleChanged is signalled, ONLY the currently active vehicle enables joystick.
See issue #10544.
we were using the geopositioninfo.isValid() in order to discard
GPS and send lat/long/alt 0, but this function returns true
even if latest GPS refresh was long time ago, so now instead
we are using _gcsGPSGood, which takes into account the 5 seconds
timeout as well
In runtime, QGC needs:
- `vcruntime140.dll`
- `vcruntime140_1.dll`
- `msvcp140.dll`
- `msvcp140_1.dll`
The update is necessary because `vcruntime140_1.dll` is only
shipped after MSVC Redistributables version 17
We use github actions now and I remove the travis configuration file and
change the Vagrantfile that uses the travis file for configuration. I
remove build_ios script as well as it is nowhere in use and seems to be
part of the travis CI setup.