Poor GPS Fix
-
Re: GPS and VL53L1 not working
I'm having a similar issue with my PX4 Autonomy Developer Kit drone. A couple weeks ago, I took my drone out for a flight test and it never acquired any GPS satellites. Today I took it out to a parking lot with minimal sky obstructions and played around with the settings in QGC to see if I could get anything to track. The best I observed through the MavLink telemetry was the track of two satellites with valid PRN and SN values. I let the drone stay powered on for 15-30 minutes after various changes to allow time for the drone to self-download almanac (if it actually does it). Time does not seem to help at all.
Any help or insight would be appreciated!
When the drone boots up, here's the INFO that prints out from it:
[uORB] Advertising remote topic event
INFO [uORB] Advertising remote topic health_report
INFO [uORB] Advertising remote topic failsafe_flags
INFO [uORB] Advertising remote topic actuator_armed
INFO [uORB] Advertising remote topic vehicle_control_mode
INFO [uORB] Advertising remote topic vehicle_thrust_setpoint
INFO [uORB] Advertising remote topic vehicle_torque_setpoint
INFO [uORB] Advertising remote topic vehicle_status
INFO [uORB] Advertising remote topic failure_detector_status
INFO [uORB] Advertising remote topic vehicle_attitude_setpoint
INFO [uORB] Advertising remote topic vehicle_rates_setpoint
INFO [muorb] [uORB] Marking DeviceNode(qshell_req) as advertised in process_remote_topic
INFO [muorb] [qshell] qshell gotten: flight_mode_manager start
INFO [muorb] [qshell] arg0 = 'flight_mode_manager'
INFO [muorb] [qshell] arg1 = 'start'
INFO [uORB] Advertising remote topic vehicle_command
INFO [muorb] [qshell] Ok executing command: flight_mode_manager start
INFO [dataman] data manager file '/data/px4/dataman' size is 7866640 bytes
INFO [muorb] [uORB] Advertising remote topic transponder_report
INFO [muorb] [uORB] Advertising remote topic rtl_time_estimate
INFO [muorb] [uORB] Advertising remote topic position_setpoint_triplet
INFO [mavlink] mode: Onboard, data rate: 100000 B/s on udp port 14556 remote port 14557
INFO [muorb] [uORB] Advertising remote topic telemetry_status
INFO [mavlink] partner IP: 127.0.0.1
INFO [muorb] [uORB] Advertising remote topic obstacle_distance
INFO [muorb] [uORB] Advertising remote topic vehicle_visual_odometry
INFO [muorb] [uORB] Advertising remote topic distance_sensor
INFO [muorb] [uORB] Advertising remote topic offboard_control_mode
INFO [muorb] [uORB] Advertising remote topic timesync_status
INFO [uORB] Advertising remote topic estimator_aid_src_rng_hgt
INFO [muorb] [uORB] Marking DeviceNode(vehicle_command_ack) as advertised in process_remote_topic
INFO [mavlink] mode: Normal, data rate: 100000 B/s on udp port 14558 remote port 14559
INFO [muorb] [uORB] Marking DeviceNode(telemetry_status) as advertised in process_remote_topic
INFO [uORB] Advertising remote topic actuator_controls_status_0
INFO [px4] Startup script returned successfully
INFO [logger] logger started (mode=all)
ERROR [muorb] [ekf2] ====> GLOBAL R to Earth: -152.495228 (42)
INFO [uORB] Advertising remote topic estimator_aid_src_ev_hgt
INFO [uORB] Advertising remote topic estimator_aid_src_ev_pos
INFO [uORB] Advertising remote topic estimator_aid_src_ev_vel
INFO [uORB] Advertising remote topic estimator_aid_src_ev_yaw
ERROR [muorb] [gps] GPS: failed to set baud rate 19200 on serial port
INFO [mavlink] partner IP: 127.0.0.1
INFO [muorb] [uORB] Marking DeviceNode(vehicle_command_ack) as advertised in process_remote_topic
INFO [muorb] [gps] No COM port detected
INFO [muorb] [gps] GPS UART baudrate set to 115200
INFO [muorb] [uORB] Advertising remote topic ping
INFO [muorb] [gps] GPS UART baudrate set to 9600
INFO [muorb] [gps] GPS UART baudrate set to 38400
INFO [muorb] [gps] Got ack to initial CFG_VALSET!
INFO [muorb] [gps] u-blox firmware version: SPG 5.10
INFO [muorb] [gps] u-blox protocol version: 34.10
INFO [muorb] [gps] u-blox module: MAX-M10S
INFO [uORB] Advertising remote topic sensor_gps
INFO [uORB] Advertising remote topic satellite_info
INFO [uORB] Advertising remote topic mavlink_logAnd here is the voxl-px4 config file. The "EXTRA_STEPS" were added in after the fact while troubleshooting.
AIRFRAME=MULTICOPTER
GPS=AUTODETECT
RC=CRSF_RAW
ESC=VOXL_ESC
POWER_MANAGER=VOXLPM
AIRSPEED_SENSOR=NONE
DISTANCE_SENSOR=NONE
OSD=DISABLE
DAEMON_MODE=ENABLE
SENSOR_CAL=ACTUAL
ARTIFACT_MODE=DISABLE
EXTRA_STEPS=(
qshell gps start -d 7 -b 115200
)The drone is fairly new and the only "changes" made to it, outside of the GPS QGC settings I played around with, were by the direction of the bootcamp.
QGC GPS Settings Modified:
GPS_1_GNSS: 0* and 1
GPS_1_PROTOCOL: Auto Detect* and U-BLOX
GPS_SAT_INFO: ENABLED* and DISABLED
GPS_UBX_BAUD2: 230400, 115200*, 38400The configuration that got me two valid PRNs tracking have the * next to them.
And finally, here's a parse of the .ulg from the original test.
https://review.px4.io/plot_app?log=37983558-9d8c-4b27-b33e-84373301fca4The drone was started in Position mode, it appears that VIO was working fine and holding the drone in place until the altitude was increase beyond what the tracking camera could handle, fell back to altitude hold mode and started flying out of control. We did have a teather on it (just incase) so were able to reel it in and not lose it. Significant wind did pick up halfway through the flight, so I will attribute some of the chaos to that factor.
-
https://forum.modalai.com/topic/4226/starling-2-max-no-gps-data
Just found this discussion and is likely the cause for my problems considering the two satellites I did track were right above me and still had very low SNR levels (20's). This seems like a pretty bad design flaw that should have been caught in testing. I'm going to try some testing and experimentation on my end to try and mitigate the EMI and will report back with any results that appear promising.
-
Building upon what @ROBERT-JUDD did in his testing, we made a shield out of a tinfoil solder cup to isolate the GPS antenna from the rest of the drone. This resulted in an almost immediate track of 10+ satellites. The EMI problem is real. We are now working on designing a 3D printable cone similar to what the cup is doing that we plan to paint with an EMI coating that will be our more rugged long term solution.
ModalAi should be providing clear disclaimers about this problem before people go and spend thousands on this drone!
-
@somalley @Alex-Kushleyev Thanks for referring to my March 1, 2025 post regarding the GPS problem:
https://forum.modalai.com/topic/4226/starling-2-max-no-gps-data
Overall I'm a big fan of ModalAI, but in my opinion this product contains a fundamental design flaw (complete loss of GPS position data due to EMI) that should have been detected and corrected early in the design testing phase. Moreover, that fatal design flaw has remained uncorrected for many months now, and I have received no information about if/when a permanent fix will be available. Our company spent over $5,000 on a Starling 2 Max, and it remains largely unusable due to this problem.
Alex Kushleyev at ModalAI has in general been very responsive, and has developed a temporary fix that customers can implement on their own, which I genuinely appreciate. But the fact remains that ModalAI inexcusably sold a product with a fundamental design flaw, and has not offered a permanent fix for many months now. In my opinion, at this point a permanent fix should be one of ModalAI's highest priority if they want to avoid a significant loss of customer confidence.
I would suggest that, as a first step, ModalAI should create a new post dedicated to providing ongoing fix updates and timelines, and to systematically update that post on the same day and time each week until a permanent fix is made available.
Thank you for your consideration.
Robert Judd
-
Hello @ROBERT-JUDD and @somalley ,
Thank you for following up and I appreciate your feedback. I have relayed your comments (again) to the team and will push to get the workaround out.
For Starling 2 Max, the workaround is to install a mast, so we are working on making those details available. Shielding the GPS receiver in the default location is not as effective. Please refer to the testing done with a mast in the center of the drone in this thread : https://forum.modalai.com/topic/4226/starling-2-max-no-gps-data/38 . However, the workaround is probably going to have the mast in the back of the Starling 2 Max.
For Starling 2, @somalley , a similar solution should be possible (with a mast). We are targeting the fix for the Starling 2 Max first, however you may be able to use the same approach (elevate the GPS receiver as well as getting it farther from the usb wifi dongle, which is right under the gps receiver, and seems to cause interference sometimes on Starling 2). We have seen improvement on Starling 2 when the wifi dongle is mounted elsewhere, but also elevating the GPS receiver should help as well as putting a small shield at the bottom.
voxl-portal now supports displaying the GPS SNR, so it should be easier to validate the signal improvements based on SNR directly (as opposed to time to lock, etc).
Again, sorry for the inconvenience and I will check in a few days regarding the status of the workaround.
Alex
