Skip to content

Pr base station menu #12686

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 8 commits into
base: master
Choose a base branch
from
Draft

Conversation

Louis-max-H
Copy link

@Louis-max-H Louis-max-H commented Apr 18, 2025

This PR aim to develop base station menu and depend on this PR for GPS Driver

Description

UBlox menu  Septentrio menu Manufacturer list
 Ps: Protocols displayed in Septentrio menu will be part of another PR
  1. Proposing different settings according to receiver manufacturer
  2. Base Station mode change from bool to int. That will allow a future PR that have base station (for example, moving base station on boat)
  3. Implement base station menu for Septentrio (base infos, base config)

### Explanation.

  1. Manufacturer allow the hide and show of some settings to keep only theses that are implemented.
    We use bit mask defined like this :
    readonly property var    _standard:           0b00001
    readonly property var    _trimble:            0b00010
    readonly property var    _septentrio:         0b00100
    readonly property var    _femtomes:           0b01000
    readonly property var    _ublox:              0b10000

To restrict a parameters' visibility to U-Blox + Septentrio : (You can use either | or +)

visible:    manufacturer & (_ublox | _septentrio)

If implemented by all manufacturer :

visible:    manufacturer & _standard

This parameter is always visible because it is implemented by everyone, but I think that specifying it each time avoids uncertainties such as, how compatible is this parameter with the receiver? Has the developer thought this through?
Don't hesitate to tell me what you think :)

To show parameters available for U-blox, set manufacturer to _standard + _ublox
Manufacturer is set automatically when plugin a receiver.

  1. Base station mode is now :
    0 : Survey-in
    1 : Fixed
    This change is compatible with the 4 different drivers that use BaseSettingsType (base_station.h).

a) Base stations info is display by using PosGeodetic information.
b) Some parameters like Ublox min precision don't have an equivalent in Septentrio, here is a quick recap of with parameters is available or not :

Parameters​ Ublox​ Septentrio​ Femtomes​ Trimble​
Survey-in (auto)​ Min duration​ ✅​ ✅​
Min precision​ ✅​
Specify location​ Long, Lat, Alt​ ✅​ ✅​ ✅​ ✅​
Base precision​ ✅​
Set from position​ ✅​ ✅​ ✅​ ✅​

Survey-in options don't have equivalents for Septentrio receivers.

Test Steps

I have followed this procedure and another intern (@duck) have done the same on another computer.

git clone https://github.com/Louis-max-H/qgroundcontrol
cd qgroundcontrol
git checkout pr-base-qgc
git submodule update --init --force --recursive
chmod +x tools/setup/*.sh
docker build --file ./deploy/docker/Dockerfile-build-ubuntu -t qgc-linux-docker .

Edit the file src/GPS/CMakeLists.txt
To have

CPMAddPackage(
    NAME px4-gpsdrivers
    GITHUB_REPOSITORY Louis-max-H/PX4-GPSDrivers
    GIT_TAG pr-base-station-px4
    SOURCE_SUBDIR src
)

Instead of :

CPMAddPackage(
    NAME px4-gpsdrivers
    GITHUB_REPOSITORY PX4/PX4-GPSDrivers
    GIT_TAG main
    SOURCE_SUBDIR src
)

You can now build QGC using :

docker run --privileged --rm -v ${PWD}:/project/source -v ${PWD}/build:/project/build qgc-linux-docker
./build/AppDir/AppRun
  • Unplug all
  • Plug CubeOrangePlus
  • Select a different manufacturer than the board tested
  • Select the config you want to test
  • Plug base station
  • See if :
    • Precision is improved, position is RTK
    • Information are displayed
    • Manufacturer is autautomaticallyt

Do these steps for Survey-In, Set location
Test have been made on Ublox and Septentrio, I don't have the equipment to test other GPS systems but they should work has Ublox does.

Checklist:

Please let me know if I need to make any changes to this RP so that it can be accepted by the community, this would be my first PR 🥳

Ps: The automatic tests could fail because of the need to modify the Makefile, so I'm putting the PR in draft form and I'll come back to you once the PR for the GPS driver has been accepted.

@DonLakeFlyer
Copy link
Contributor

@bkueng Beat can you look through this. I'm not super familiar with RTK,

@bkueng bkueng self-requested a review April 22, 2025 14:36
Copy link
Member

@bkueng bkueng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, having type-dependent options makes sense.
But ideally the manufacturer is determined automatically, as we already know it when connecting the device.

@Louis-max-H
Copy link
Author

I've updated the PR with a rebase including the latest QGC changes.

@DronecodeBot
Copy link

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-sync-q-a-april-30-2025/45350/2

@DronecodeBot
Copy link

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-sync-q-a-april-30-2025/45350/1

@DonLakeFlyer
Copy link
Contributor

FYI: I'm going to branch for QGC 5.0 RC next week. So if this wants to go into 5.0 it needs to hurry.

Copy link
Author

@Louis-max-H Louis-max-H left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the info!
I think everything's already good, I've added a version with enumeration for the baseMode and I tested this morning that the menu works well.

Here's a quick recap of the latest changes:

  • baseMode use enum as suggested by bkueng
  • Bitmask calculation moved in c++ file to avoid magic constant

@Louis-max-H Louis-max-H requested a review from DonLakeFlyer May 8, 2025 08:10
@DonLakeFlyer
Copy link
Contributor

But ideally the manufacturer is determined automatically, as we already know it when connecting the device.

Is this supposed to be working? I have a Ublox RTK which I plugged in. When I went to the page the manufacturer was set to all.

@Louis-max-H
Copy link
Author

That's very strange ...

I have test again with an Ublox ZED F9P an the menu was detected.
Detection is made in src/GPS/GPSRtk.cc, but the if/else tests should only set manufacturer to Ublox/Septentrio/Fentom/Trimble or Standard, but not All.

I've also checked that there's no inconsistency with regard to enumerations (0 = Standart, 1 = All).

I have made a little improvement to the print pattern, with the latest changes can you :

  • Check the message send by qCDebug(GPSRtkLog)

    1. Connecting U-blox device -> Manufacturer to Ublox
    2. Connecting device has U-blox by default" -> Manufacturer to default
  • Close menu and open again

    1. Settings are correctly updated even with the menu open, only the manufacturer is not changed when menu open. Cf gif.
      demo
  • We are actully checking for "blox" in the name of the receiver, maybe we can change it to something else ?

    1. Can you check for the name of your receiver has detected by QGC ?
    2. qCDebug(GPSRtkLog) << gps_type; to add in GPSrtk.cc

I hope it will help to understand what is happening !

@Louis-max-H
Copy link
Author

After discussion with another QGC user, the "manufacturer" reference may be misleading.

He thought that this choice had an impact on the protocol used, whereas it's just a graphics option to hide some settings, so I changed it to "Settings displayed".

I have tested this change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants