mavlink / MAVSDK-Python

MAVSDK client for Python.
https://mavsdk.mavlink.io
BSD 3-Clause "New" or "Revised" License
315 stars 219 forks source link

Imu & Calibration Error #347

Closed S4iR0X closed 3 years ago

S4iR0X commented 3 years ago

Hey Guys,

I want to get the velocity of my flight controller running Arduplane 4.0.8. So I tried to get the imu() and position_velocity_ned() data, in both cases I am not receving any kind of data or error.

But the raw_imu() topic is working. Is this because of the flight controller firmware?

Moreover the data I get seems to be not good so I want to run the calibration example after I checked the health topic with following result: Health: [is_gyrometer_calibration_ok: False, is_accelerometer_calibration_ok: False, is_magnetometer_calibration_ok: False, is_level_calibration_ok: True, is_local_position_ok: False, is_global_position_ok: False, is_home_position_ok: True]

I also added this code in front of the calibration because it gave me a calibration error in the first try:

    async for state in drone.core.connection_state():
        if state.is_connected:
            print(f"Drone discovered with UUID: {state.uuid}")
            break

     **Calibration_example**

The result of the calibration example:

Connected to mavsdk_server!
Waiting for drone to connect...
Drone discovered with UUID: 0
-- Starting gyroscope calibration
Traceback (most recent call last):
  File ".\calibration.py", line 39, in <module>
    loop.run_until_complete(run())
  File "C:\Python38\lib\asyncio\base_events.py", line 616, in run_until_complete
    return future.result()
  File ".\calibration.py", line 17, in run
    async for CalibrationError in drone.calibration.calibrate_gyro():
  File "C:\Python38\lib\site-packages\mavsdk\calibration.py", line 360, in calibrate_gyro
    raise CalibrationError(result, "calibrate_gyro()")
mavsdk.calibration.CalibrationError: CONNECTION_ERROR: 'Connection Error'; origin: calibrate_gyro(); params: ()
Exception ignored in: <function System.__del__ at 0x000001D1ABBD2AF0>
Traceback (most recent call last):
  File "C:\Python38\lib\site-packages\mavsdk\system.py", line 55, in __del__
  File "C:\Python38\lib\site-packages\mavsdk\system.py", line 91, in _stop_mavsdk_server
ImportError: sys.meta_path is None, Python is likely shutting down

What am I doing wrong? Thanks in advance :)

JonasVautherin commented 3 years ago

Running Ardupilot, I would guess that there is something that MAVSDK does not expect. We support PX4 at the moment, but we are open to PRs for Ardupilot of course. @bazfp may have an idea?

bazfp commented 3 years ago

Yes the telemetry will not report a good health with ArduPilot at current. I have a fork of MAVSDK in development, looking at implementing Ardupilot support.

Gyro, mag and accelerometer calibration in MAVSDK relies on parameters that do not exist on Ardupilot. The Ardupilot health check process differs.

Ardupilot does not report local position regularly too, so you must setup Ardupilot to transmit local position at minimum 1hz.

This is all part of the Ardupilot implementation, I would look at using the MAVLINK passthrough API for now until Ardupilot support is added (or use px4)

LorenzMeier commented 3 years ago

Just to clarify our general policy in this: We've witnessed how much maintenance overhead it induces to have 5 different ways of doing things. Therefore the line for MAVSDK is that it long-term will only target the MAVLink standard message set.

This has right now one important limitation: Because there are missing "standard" elements like flight modes or calibration behavior, we couldn't implement this properly in all areas yet. We have put forward as early as 2019 a number of proposals that would allow to replace things that are specific to PX4 with a standardized approach.

For example common flight modes - this was sparked in 2019 by the observation that this would be needed to allow MAVSDK to target the standard: https://docs.google.com/document/d/1LIcfOL3JrX-EznvXArna1h-sZ7va7LRTteIUzISuD8c/edit

This did not get traction so far, but we're happy to get back on this any time.

So in summary: We're more than happy to remove anything that is specific to PX4 with a standard method that becomes part of the MAVLink standard - but what we are not planning to do is to add corner case handling for different flight stacks. So the way to get APM support is to collaborate on extending the MAVLink standard to include anything that you're missing right now and then to send pull requests that target the standard.

Looking forward to collaborate on this!