I get the prearm warning “need position estimate” despite having 20 satellites and a small Hdop. Home position is shown in Mission Llanner, and the only error I can find is in the EKF-window in Mission Planner showing an error in pos_horiz_abs
Logs are found here (ignore the motor failure at the end of the flight):
File deleted, no log to check.
Sorry, new download link added
I dont see the issues in that log, unless the warnings were occurring before logging started.
You can capture that by setting LOG_DISARMED if required.
I would say there is probably no issue, and it is entirely possible to have prearm warning “need position estimate” with a high number of sats. It can take some time for the position to settle.
You could try these in turn to see which gives you the most reliable position:
GPS_GNSS_MODE,5 or GPS_GNSS_MODE,65
Unrelated to GNSS, but you should definitely set your voltage failsafe levels and actions, such as these for 6S Lipo:
BATT_ARM_VOLT,22.10
BATT_CRT_VOLT,21.00
BATT_LOW_VOLT,21.60
BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2
MOT_BAT_VOLT_MAX,25.20
MOT_BAT_VOLT_MIN,19.80
For improved tuning you can also set these:
INS_ACCEL_FILTER,10
INS_HNTCH_ENABLE,1 // write then refresh params to see the rest
INS_HNTCH_BW,10 // INS_HNTCH_FREQ / 4 when INS_HNTCH_OPTS,2
INS_HNTCH_FM_RAT,1
INS_HNTCH_FREQ,30
INS_HNTCH_HMNCS,3
INS_HNTCH_MODE,3
INS_HNTCH_OPTS,0 // 2 for per-motor notches
INS_HNTCH_REF,1
INS_LOG_BAT_MASK,1
INS_LOG_BAT_OPT,4
The odd thing is you seem to have all the ESC data, as if from BLHELI ESCs but you are only using PWM when maybe you could be using DSHOT if you moved the motor/ESC connectors to AUX outputs instead of MAIN outputs. Is it all CAN-connected? I’d be intierested to hear how you have this set up.
Thanks for the reply! There is indeed a problem, and it is not possible to arm in loiter mode.
After testing the drone in alt-hold, I got an EKF3 core unhealthy error. The error goes away after a reboot and it is possible to perform a flight, but most of the time the error comes back after landing.
Is this a hardware issue? I have updated to copter 4.4.0 since the last time I tried.
Attached log of EKF-error:
There’s nothing wrong in that log except for the tuning and all the parameters I mentioned before.
Set LOG_DISARMED = 1 to capture the issue and provide that log
At first, I was unable to start the compass calibration through Mission Planner over UDP, and I had to do it with a USB connection. I also tried injecting the raw mavlink command through ROS2, but without luck. It did, however, work in QGC. After I connected the drone over UDP to QGC, it was also possible to start the calibration in Mission Planner. I did no other change than to connect to QGC.
After a new compass calibration through Mission Planner, the prearm warning disappeared and it was possible to arm the drone in Loiter. I have no idea why, but it looks like that did solve the problem.
Did you set all the other parameters I listed? They will help and improve safety.
Everything else is setup like you suggested
Could you solve this problem?
I have a SpeedyBee F405 Wing for driving a buoy with two motors similar to this project: BuoyBots - self position holding buoys for RC sail boat racing
Installed ardurover 4.4.0 for SpeedyBee 405 wing, a M100 GPS (no compass) and two bidirectional ESCs.
Configured: Compass-less Operation — Rover documentation
After all components where installed in a waterproof box and connected to the motors, I noticed the same problem as you have:
3D dgps fix, HDOP around 1.4 and if I activate the loiter mode, the message Prearm: Need position estimate in Mission Planner.
For a check I disconnected the RC receiver and ESCs and used the 433MHZ SiK radio for MAVLINK connection - if the 2,4MHZ RC may produce interference - but no change.
I have quad and hexacopters running with pixhawk for years and they were all running perfect from the first day. Therefore I cannot understand this behavior.
Regret, can’t assist. We abandoned Ardupilot in favour of our own code for this project.
@jlang did you read all information above your posting.
Yes, Olav solved the problem by compass calibration.
As your setup has no compass it is probably not the same problem.
It might be more helpful for you if you post your question including .param and .nin file in the correct part of the forum.
I think your buoy is more a rover than a copter
Your are right, it is more a rover than a copter - I suppose initialization processes are quite the same for both systems. At least it is not clear to me if the Need position estimate correspondents to the compass calibration - it would be a misleading info message. I will dismount a compass from a copter and will check it again.
Found a compass module, connected it to the flight control, activated the compass in the settings and deactivated compass-less operation.
After calibration and restart of the flight control the loiter mode could be activated.
As stated before the messages are very misleading. A missing compass produces a need position estimate message ?!
The message means that the EKF cannot calculate a good position estimate using the sensors it has (normally IMU, baro and GPS). It’s fusion of available sensors.
@jlang, without a compass or comparable sensor you don’t have a heading information. GPS delivers heading information only if it is moving with some minimum speed. But in your special case you don’t want the buoy to move. But if it is a little bit drifting how should the system control yaw for the correct heading?
Thank you, added a compass and it works.
At least some further tuning is necessary. The buoy is equipped with two thrusters. The buoy prototype is controlled by RC to the target position and loiter mode is activated. When the buoy is on its position the motors are started to correct the rotation, but the short pulse on the thrusters is too strong, that the buoy has a continuous rotated swinging around its axes.
Is there a way to ignore heading as long as the device holds its GPS position - as you described before, there is no way.
I will try to add a daggerboard to damp the rotation.
@jlang, i am relative sure that in principle it must be possible that the thrusters switched of as long the GPS-position is within a small radius around the setpoint.
If it is not directly posssible by a parameter I am sure it can be solved by a script.
But on these points I have no experience.
Better PID tuning may reduce oscillation. The Quick-Tune script would help to get initial tuning: Rover/Boat QuikTune alpha testers wanted! but unfortunately the SpeedBee 405 wing board has a SD-Card but insufficient FLASH that does not allow to activate SCR_ENABLE = 1. 