alti hold:
Sensitive throttle (like “on and off”)
when pulling it close to 50 % nothing happens then suddently it starts flying straight up at a crazy speed. Lowering the throttle and it stabilize. But. If lowering it a little bit more an Iris fall from the sky.
it drifting forward and to the left (any way it facing).
Loiter:
behaves like alti-hold but without drifting.
Stabilize:
It behaves “normal”.
So,
I wonder how to set all parameters to the way it was when i recieved it. Also with the transmitter.
I have been having trouble reliably retrieving logs with APM. Started using Win8 in a Parallels session to run Mission Planner. You do it from the terminal in APM. I don’t connect very reliably with APM either. I just don’t think its there yet.
A few other people and myself are experiencing corrupted logs when downloading from the Pixhawk. I have been removing the SD card from the Pixhawk and retrieving them straight off the card.
Stabilize.
The iris respond do stick input. If throttle set half way up then the motors spinning att approx 50 %. It responds to pitch, yaw and roll too.
Alti Hold.
Motors are spinning when throttle stick is all the way down. when raising it towards 50 % then nothing happens. I keep pushing the stick uppwards and then. the motors spinning att its maximum. Trying to lower and the motors slow down instantly. If I find the “sweet spot” and the motors spinning at approx. 50 % ant i tilt the iris by hand nothing happens directly. After 3-4 sec then the iris try to compensate. And when it does the motors is like “on and off” not the smooth adjusting that was before.
Loiter
The same result as in Alti hold mode.
My assessment is this.
The ESC are working fine. Hence it behaves normal in stabilize.
Same goes for the motors.
All problems have been when in alti hold, loiter och auto. Could it be something wrong with the pixhawk? Or the gps?
It sounds like everything works as it should, but you misunderstand alt_hold. (and maybe other control loops)
When stick is above 50% - you command desired_altitude to be current_altitude + some more.
the Arducopter code try to get altitude to increase, but is going nowhere, so it quickly end up at max thr_out.
then you lower the stick, so current_alt>desired_altitude - and it reduces the thrust, not going anywhere, again, it ends up at minimum …
Well. I have flown it several days and it worked just fine. Now it behaves in a different way. If I start in AH it just takes of and it nearly impossible to get it to hoover. This was not the case at all before.
I have simulated liftoff but nothing changes. and if I fly it in AH it takes away but never slows down…
I have tested it and its almost impossible to land it in AH (without crashing -that is). In the manual 3dr recommends first flight in AH because its the most easy way of flying (I guess). But now its almost the hardest way of getting control over the Iris.
check your parameters (PID’s, RC*) and compare to an old backup, or .log file.
you did not mention what rfame/motors you fly, if it’s a standard 3DR machine, you can just load defaults and start over.
you could also try a setup, reset in CLI , then reflash firmware.
is it a 3DR quad or hexa, and few fine before - then it should fly fine with defaults. you still need to calibrate everything like first time.
otherwise, ESC calibration and mechanical failure (loose props og motor hubs) is the only possibility.