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.
Computing power-wise, a Black Cube and an original Pixhawk are identical.
It’s only the Yellow and Orange that have more powerful microcontrollers.
It uses too little throttle it does a very slow takeoff … the problem is not top speed the problem is almost not climbing
Baro altitude is not being zeroed at the start, it’s at about -58 or -59. Did you manually set GND_ABS_PRESS ?
Also the 2 GPS’s are giving different altitude readings:
I’m guessing the system was rebooted since the log is not big, but was the system actually powered down for a couple of minutes, and if so how did it behave after that?
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…
1 Like
@xfacta Thanks for looking into this.
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.
@rmackay9 thanks for looking into this.
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.
This has worked over 100 times…
1 Like
Any news on this behaviour? We have the same problem
We updated to 4.0.7 and command a baro calibration via MavLink command before every takeoff, and it works a lot better.
We’ll try that as well thank you!
How do you perform the calibration? We are doing it via dronekit with this function but it doesnt seem to work…
def send_calibrate_barometer(self):
“”“Request barometer calibration.”""
calibration_command = self.message_factory.command_long_encode(
self._handler.target_system, 0, # target_system, target_component
mavutil.mavlink.MAV_CMD_PREFLIGHT_CALIBRATION, # command
0, # confirmation
0, # param 1, 1: gyro calibration, 3: gyro temperature calibration
0, # param 2, 1: magnetometer calibration
1, # param 3, 1: ground pressure calibration
0, # param 4, 1: radio RC calibration, 2: RC trim calibration
0, # param 5, 1: accelerometer calibration, 2: board level calibration, 3: accelerometer temperature calibration, 4: simple accelerometer calibration
0, # param 6, 2: airspeed calibration
0, # param 7, 1: ESC calibration, 3: barometer temperature calibration
)
self.send_mavlink(calibration_command)Yes, we do it like that as well.
It seems sometimes it works but sometimes it doesnt
Is there any response from dronekit or mavlink confirming that it has calibrated succesfully or unsuccesfully??
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.
Shouldn’t it reset altitude to 0 before takeoff?
Is this a bug in 4.0? @Leonardthall @rmackay9
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.
As per usual, it’s all guesswork without a log.
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?
I will try that tomorrow.
Thanks a lot!
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.
@karthikdesai can you check that we reset the altitude (via barometer calibaration) after seting the home location (for the rally point) ?
Hi,
I was checking the ardupilot code (as far as I could read), it doesn’t reset the barometer. can I reset the barometer between arming and takeoff by the mavlink message too? should it work?
Jesus