PX4BuildBot
commented
6 years ago Hey, this issue has been closed because the label status/STALE is set and there were no updates for 30 days. Feel free to reopen this issue if you deem it appropriate.
(This is an automated comment from GitMate.io.)
These days I am doing outdoor experiments with a quadrotor using Pixhawk interfacing with an onboard Ordoid. The Odorid communicates setpoints that the drone has to reach.
To understand the setup: 1) I am using the 1.6.1dev version of the firmware with LPE estimator. 2) I am using a DJI Flame Wheel F330 frame 3) I was on a grass field without any shadow around midday (temperature 30 degrees), I do not know about the temperature of the Pixhawk, but it was high 4) I recalibrated the sensors several times, more or less always before each test.
One of the experiments is a waypoints navigation. The Odorid runs ROS and calculates waypoints in the local frame. It communicates the position to the Pixhawk using the rostopic /mavros/setpoint_position/local. I did several tests, and after a while, the drone started to have a strange behavior.
As you can see from the graph the Odroid communicates: 1) takeoff waypoint (more or less from second -48 to -46): current position in xy (red and light blue lines), 2meters more in z (blue curve) 2) first waypoint (more or less from second -46 to -34): z remains initial z + 2 meters, x and y change (the waypoint is at 10 meters distance from the initial position)
Initially, tracking is good, the drone reaches the takeoff waypoint. Then the Odroid communicates the first waypoint, x and y try to converge to the desired position, while z starts to rise. At second -34 I kill the publisher of /mavros/setpoint_position/local and ask for automatic landing, but as you can see the Drone is still going up. At second -20 I take over with the remote control and land the drone.
The second image is another experiment in which I experienced the same behavior:
1) takeoff waypoint: ok 2) first waypoint: ok 3) second waypoint: ok 4) third waypoint (come back at initial position): x and y are good, while z rises at 7 meters, and when I switch off the publisher of setpoint (second -140) it goes up until I take over with the remote controller at second -110
The state estimate seems correct, I am not sure how precise it was, but I was able to see that the actual behavior is like the one showed in these graphs.
Have you experienced something like that? Do you have any idea about the causes of this problem? Do you think it can be related to overheating of the board? What I will do now is reflash the firmware, and retry to do the same experiments.
Thank you very much.