I do not understand why, but after being powered for two days straight and doing around 20 consecutive thetered flights ArduCopter decided that 3m height was enough, although it got commanded to 10m height.
Any clues? could it be that being powered for too long caused it? It climbed extremely slow.
Is it normal to have 80% processor load on a cube black?
Any chance it is the same mine is doing? If i try a fly there it goes only at 2 m/s even if wpnav is set to 6 m/s and there is no way of telling it to go any faster. I also have a pretty loaded black cube.
Don’t want to hijack your thread i was just thinking that maybe is the same think showing into different ways.
Thanks for testing 4.0.4-rc2 beta release. The log does have some weirdness in it but I’m unsure of the exact cause of the problem.
One odd thing is that the estimated climb rate and altitude do not seem to match. Below is a graph of the altitude (in red, scale is in 2nd column on left) and climb rate (in green, scale is in first column on left). The climb rate is largely negative but the vehicle is climbing.
Normally this kind of problem is caused by high vibration but the VIBE message doesn’t report that vibrations are particularly high.
I guess another cause could be accelerometer bias perhaps caused by temperature.
Still, I would have expected Guided mode to try and climb to 10m above home. In the logs the ORGN message appears 0.3 seconds after arming. Are you using a custom GCS by any chance and does it set the home position?
The takeoff to 10m command is received 3 times in total. The firs two times it succeeds and the last time it does not. Because these arrive after the ORGN message I would expect the vehicle to climb to 10m above home but it doesn’t which is odd.
I also see in the logs that the origin and home altitudes are very different but this shouldn’t be a problem. It’s also slightly odd that the barometer altitude does not match the EKF’s altitude. Normally they are the same.
I see EK2_RNG_USE_HGT = 70 instead of the default -1 and the RangeFinder is acting strangely in that it’s jumping from 0m to 3m. Still, I didn’t think that the EKF would try to use the rangefinder unless EK2_ALT_SOURCE = 1 (RangeFinder).
Sorry, I don’t immediately have an answer as to what is going wrong. Just clues…
No, I did not manually set GND_ABS_PRESS.
Both GPS are “Hex here” units and have the same configuration, but yes their altittude varies a lot. I use GPS_AUTO_SWITCH = BLEND so it should not jump. @peterbarker I do not understand why the DF log does not contain any GPSB messages. Is it a bug?
System was not rebooted, we use LOG_FILE_DSRMROT = 1, hence the small log file. The system was powered for two days straight.
We do use a custom GCS but we do not set home location, so something else is causing the altitude to get initialized wrong.
EK2_RNG_USE_HGT = 70 is because we use a vision based lidar that only publishes messages when landing. The camera was turned off and no messages are sent during takeoff. EK2_ALT_SOURCE = 0 so the baro should have been used.
I have the exact same problem after leaving the pixhawk turned on all night the altitude goes down aprox 50m, when i command the copter to takeoff in guided mode to 40m it uses very little throttle and most times it doesnt go past 4m.
The altitude-above-home is reset to zero when the vehicle is armed as long as the home position hasn’t been set externally. The home can be set externally by the user right-mouse-button clicking on the map and selecting, “Set Home Here”. A companion computer may also set home using a mavlink message (I can’t immediately remember the name of the message but it is something like “SET_HOME”).
Once the home position has been set externally it is not reset on arming so this could cause problems for the takeoff command if the vehicle’s barometer has drifted a lot.
Oh ok ok I didnt know that! Thank you for that info…
So if I understand correctly, if the home has not been set externally, when the vehicle arms it resets the altitude to zero… If this is the case we can set the home after arming so it gets that last position right?
Yes, you should be able to externally set home after arming. the change may not be reflected in commands that have already started. So for example if a takeoff command is sent to the vehicle and then the home is changed, the takeoff that has already begun won’t use the modified home position. this is because internally the navigation controller uses offset from ekf origin. The converstion from whatever altitude (e.g. relative-to-home, relative-to-sea-level, etc) is all done at the moment the command is accepted.