we are developing a drone for a time critical application. Currently it takes around 45s till our autonomous drone takes off. This is OK, but I think it could be shorter.
Our setup consists of a Pixracer running Copter 3.6 (ChibiOS) with an ublox NEO-M8N. Additionally there is a raspberry Pi companion computer controlling the system.
The “boot” time for the drone is around 7-8s, then I can fly manually in Stabelize mode. The Raspberry currently takes around 17s to boot. I thought this would be the bottle neck, but I can tell that after the boot the raspberry waits for the drone to become ready.
Now, I know that for Guided mode I need a good GPS fix. But according to the ublox datasheet a warm start should take only 1s and a cold start should take 26s… so the question is, why does the drone take so “long” to take off? The GPS module actually has blue status LED indicating if it has a fix or not, and this more or less matches the data sheet description (depending on how good the view of the sky is).
What could be preventing the drone from immediately taking off, once there is a good GPS fix?
The GPS is telling you the GPS has a 3D position fix. But that isn’t actually relevant and often misleads people. ArduPilot waits for that position fix to actually be stable and usable, which is far more strict than the GPS’s onboard LED is indicating. The GPS position/velocity needs to stabilize to a certain threshold, at which point GPS position is used by the EKF (referred to as GPS fusion). The time you are experiencing for that to happen is perfectly normal, and unlikely to be improved upon with an M8N.
Thank you for your reply and the explanation, I 'll read up on GPS fusion. From the top of your head, do you know of any chips other then the M8N which can increase the GPS fusion speed? Is the GPS module the only bottleneck or can be something done on the FC side as well?
For example, could EK3 in theory be faster than EK2 for some reason? There do seem to be some tuning parameters for GPS, but I unfortunately haven’t found much detailed documentation.
Currently I have GPS_TYPE set to 0, which correctly detects the ublox chip. My thinking was maybe the auto detection eats up a few precious seconds, but I wasn’t able to get it working manually. But from what I understand from you that’s a waste of time in any case?
it seems you’re really hunting for seconds … maybe you just could remove/avoid/redo the bootloader on the pix, it waits for 5 secs or so at startup, which could be gained, a gain of more than 10% in reference to your 45s
EKF3 will not get it done any faster. It simply takes time for the GPS position accuracy to improve and stabilize enough to be usable for flight. This will be true for any GPS. A far more expensive professional GPS may shave a few seconds off of this (@WickedShell?). But if you’re looking for a GPS that will go from powered off to fully stable, usable, fused position information in a few seconds, I don’t think it exists.
shouldn’t he be able to store the last coordinates and other data and then be able to get the 1s warm-boot time even from a cold boot? assuming he has storage available…
What Matt is saying is that the delay isn’t caused (primarily) by the gps, but by the internal ArduPilot logic. Basically the autopilot watches the small changes in gps position and velocity, compared these changes to what the inertial sensors think is happening, and won’t let you arm until those two things are within a certain margin of each other.
Probably worth sorting out - just so you know what’s going on.
The Pi is presumably waiting for the EKF to indicate it’s likely to allow
you to arm. That’s the most reliable way I’ve ever come across to
determine if a vehicle is armable (apart from trying to arm it!).
It might be useful to take a telemetry log while trying to arm it every
second or so, and see what the arming error messages coming back are.
This just increases the frequency of these messages on Copter - we spit
the vast majority of such messages out while you’re disarmed anyway.
Why not keep the GPS running . Power it from a rechargeable battery which keeps charging when UAV is powered on. When you power down the UAV, the battery keeps the GPS on. A 3500Mah 186550 cell can keep an M8N GPS on for 80-90 hours
@moobsen I guess this is for your avalanche rescue drone ?
What would be the average time from takeoff to ‘‘search area’’ , if its around 30 seconds, you could experiment with taking off in althold/ terrain following with the PI guiding to a compas vector (point the drone to search area) hence flying in non-gps mode (basically the dead-reckon ) , then automatically switch to auto or guided once the PI detects GPS through telemetry, so you can start the predefine searching mission
Edit: That would probably require to have the vehicle standing flat at level and setting the level before flight… that adds complexity to an emergency situation where it would be preferable to have a ‘‘throw’’ mode.
If your GPS has a lock and your home position is known, but you still can’t arm, you can disable or make the GPS tests less restrictive. Then it will pass the checks faster, if the issue is HDOP or one of the errors related to the IMU’s and GPS not agreeing. (speed error, etc). For me, taking off in woods or between buildings, I have to decrease the tests, or I wait 10-20 minutes for a lock. (Yes minutes!) I can have 10 satellites but my HDOP or speed is too high, and I just wait and wait. The issues quickly resolve once I’m in the air.
You could do what Patrick suggests, but also use the Pi to set home once the ekf sets an origin (ie use DroneKit to listen for the ekf origin, then update home and switch to a gps mode)
Currently we assume the mission starts where the drone is turned on, and the drone is facing in searching direction. So the drone actually is flat at level before flight at the moment. I do like the concept of throwing the drone into the direction of search though.
If we do fly in a non-GPS mode, I fear wind could severely bring the drone away from the area to be searched, even if it still faces in the right direction thanks to the compass.
I think we will eventually have to switch to/add an optical flow module.
Yup, turning off GPS checks decreased the time until the drone took off. Unfortunately it also flew a little “drunk” with too few satellites in sight… I guess we’ll just have to experiment with which HDOP/VDOP the GPS accuracy is acceptable for us and design our own pre-arm check.
I also will check out SBAS, we have not used this so far, but it sounds quite promising.
The M8N uses SBAS by default unless you’ve changed the configuration to disable it. It’s not the kind of thing you can do something with or use in a different way. It’s augmentation that improves the accuracy of the position fix. If SBAS is available in the area you’re flying, the M8N will use it.
Why don’t you keep the GPS “hot” ? A typical M8N without an additional LNA consumption is only 15 mA. A high-quality 18650 cell can keep it hot for a week. And a pair of Shottky diodes will keep the drone and GPS power circuits unaware of each other, so you can plug the flight LiPo first and unplug the hot-GPS cell after.
If the GPS is already on with good quality position fix, fusing the GPS into the EKF will happen very quickly. To test how quickly that will happen, just power up on the ground and let it sit there until it’s happy as usual. Then use the mavlink reboot command (available in mission planner actions tab). That will reboot the autopilot and you’ll see how fast it can be ready for takeoff if the GPS was already on.