How accurate should Altitude hold mode be

Hi all

How accurate should a Pixhawk be at holding altitude in Altitude hold mode.

Took my new quad out for a spin yesterday and found it did not hold altitude, but I might be expecting too much for a basic Pixhawk with no ad on sensors.

I entered Alt hold at about 20 foot but it quickly ended up at around 60 foot.

Is that to be expected or an indication my Pixhawk has issues.

Thanks

Paul

You have issues. Properly tuned and radio calibrated it should hold altitude very well.

Regards,
David R. Boulanger

Unless you have a rapidly changing barometer. Was the altitude change abrupt, or did it happen gradually?

Without a log there is no way to solve the problem.

Regards,
David R. Boulanger

I download the Flights Log files but Mission Planner refuses to Analyse them

Just pops up an error about FMT’s being missing from the log but gives no other help

Anyone know how to fix it so that the log contain the said FMT’s

Thanks

Paul

Here is one of the log files I am unable to read

What is the value in LOG_BITMASK?

LOG_BITMASK value is 1048575

Is that correct, if not what should it be.

The are a lot of options shown for the value but 1048575 is not on the list of available options

Thanks

Paul

well, that bitmask is every option enabled, which you will don’t need and can bog the CPU down. Currently there are twenty options in the log file

As you can see, each option is given a value. You add up the values selected to find out what the log_bitmask value is. In your case, EVERY option would be enabled to get that result. IMO that’s far too much logging going on.

I don’t have optflow, but my bitmask setting is 10230. That enables the following: ATTITUDE_MEDIUM, GPS, ControlTuning, NavigationTuning, RCIn, IMU, Commands, Current, RCOut and Compass.

My opinion, the most important things to log are RCIn and RCOut as well as IMU.

Note: The Wiki entry for the logs at http://ardupilot.org/copter/docs/parameters.html#log-bitmask-log-bitmask don’t list Bit 16 (Log When Disarmed) which is an important one for me since I do a lot of bench work with mine and don’t necessarily need logs while the copter isn’t armed. But it does work from what I can tell. At least it still works on 3.3.3.

Thanks for the info

I will make the appropriate changes.

Bizarrely I have been checking all the earlier log files on the SD card and found that they are all readable except the three from when I was actually flying, all the ones built whilst testing on the workbench are fine.

Just to test I have formatted the memory card and will start again this weekend. Tests done on the bench show new logs are readable so perhaps it was just a card corruption issue.

Thanks again

Paul

Mine is set at 176126 from when I loaded 3.3.3. I’ve never done the math to see exactly what I’m logging but everything I have ever needed to view has been logged. Not a very educated answer but all is working well.

Regards,
David R. Boulanger

You can actually see on those logs what your bitmask setting was. Usually the parameters are at the top of the log file (not the bin).

David, here is what you are logging.

ATTITUDE_FAST: OFF
ATTITUDE_MEDIUM: ON
GPS: ON
PerformanceMonitoring: ON
ControlTuning: ON
NavigationTuning: ON
RC In: ON
IMU: ON
Commands: ON
Current: ON
RC Out: ON
Optflow: ON
PID: OFF
Compass: ON
INAV: OFF
Camera: ON
LogWhenDisarmed: OFF
MOTBATT: ON
IMU_FAST: OFF
IMU_RAW: OFF

Thanks for that. Theres a few things I may turn off and a couple on.

Regards,
David R. Boulanger

From what I understand, some new logging parameters have been added since 3.2.1. They always get added to the end of the bit list is my understanding. I’m not sure that 3.2.1 has the last three (MOTBATT, IMU_FAST,IMU_RAW).