and i tested simpleTakeoff
What you've got is the same as in one of the examples, so I don't think it's wrong.
Could you raise an issue against ArduPilot, please?
Please include dataflash logs from both SITL and the real vehicle.
i want to try it in real life and i had this issue
there is no problem on sitl
no
there is no problem on sitl
Did you make sure that the desired was leading the actual?
Sorry, bedtime here.
I will write the result
good night
What happens if you are polling a vehicle attribute (let's say vehicle.attitude.pitch) at a rate that is occasionally faster than it is being transmitted populated by the flight controller? If my Pixhawk is busy and doesn't provide the mavlink messages at the rate I requested when connecting, will the Python thread polling that attribute wait at that line of code until that attribute is populated? I am getting some weird errors that only happen when flying. I can't reproduce them on the bench, and I am wondering if it is related to the Pixhawk being too busy to transmit to my companion at the expected rate. I don't understand what happens if I poll vehicle.attitude.pitch, then poll it again before it is updated.
@mwshafer while technically you can poll for messages, that's almost certainly not what's going on. Local data is being populated from "streamed" (scheduled data) from the autopilot, you're just getting copies of that data. Check how lossy your mavlink connection is to see if you're dropped messages.
*data. I am wondering what happens if I request data before the autopilot sends down updates to the attribute I am requesting.
If you want to be notified of all updates you can subscribe to the data yourself using (e.g.) the decorator syntax e.g. https://github.com/dronekit/dronekit-python/blob/master/dronekit/__init__.py#L1080
armable is actually tough, and there's no mechanism in dronekit-python (and, indeed, mavlink in general that I know of) to test armability. You could take inspiration from ArduPilot's test suite where we check what's coming back in the EKF's status packet.
@thatsnailguy thing is, it's a property of the mode not checking RC input. Unless you have fiddled your arming check parameter, the RC input channel should be checked if appropriate just by setting that arming flag in the vehicle. If you want to make sure the stick is low you could add the check yourself in dronekit-python.
@peterbarker That's strange. Because I am arming in Stabilize mode. If i click arm/disarm in MP, pre-arm checks fail and it doesn't arm. If arducopter is running pre-arm checks, why does dronekit need to run its own? What if dronekit loses the Rx side of the telemetry for whatever reason, and the RC Tx gets lost in the meantime.
It should simply be rejecting the arm and emitting a statustext, roughly equivalent flow to this:
STABILIZE> rc 3 2000
STABILIZE> arm throttle
STABILIZE> APM: PreArm: Throttle too high