Hi @SIYI,
I have an A8 Mini that I’ve been experimenting with the last few days. Here is a summary of my experiences, and a few bug reports.
For reference, I am running:
- ArduPilot Copter 4.4-Beta5
- Airframe is well tuned, minimal vibration, and gimbal is isolated.
- I am not using external RC inputs to drive the gimbal, everything I am attempting is using MAVLink Messages (gimbal manager, mount control, etc)
- SIYI A8 Mini:
- Gimbal Firmware: 0.3.0
- Camera Firmware: 0.2.1
Setup: Control SIYI Gimbal Camera by the Ardupilot Driver through UART:
Configuring the Flight Controller to drive the A8 Mini using the SIYI SDK Protocol seems to work fine for control, however there are a few rather major issues.
- In this mode, I have been able to use the MAVLink command MAV_CMD_DO_GIMBAL_MANAGER_PITCHYAW to point the gimbal forwards and down.
- As described above, the gimbal drifts a lot. This is especially true during continuous rotation where we have seen the gimbal take time to recover from this action.
- When using the SDK Protocol, the flight controller is never sending GPS Position, so images taken with the A8 Mini are not correctly Geotagged.
- The SDK Protocol has no mechanism similar to the mavlink TIME_SYNC or SYSTEM_TIME messages, and so the timestamps for video recordings and images are missing entirely.
In an attempt to improve gimbal performance during these continuous rotations, I’ve attempted the next section from the manual.
Setup: Control SIYI Gimbal Camera by Mavlink Gimbal Protocol through UART:
Configuring the Flight Controller to use MNT1_TYPE 4 (SToRM32 MAVLink) and SERIAL1_PROTOCOL 2 (MAVLink 2.0) changed behaviours slightly. In this test, I increased the attitude rates as well, to help improve the performance.
- In this mode, it appears I have lost all ability to control the gimbal through MAVLink messages.
- Inspection of the code indicates the AP_Mount_STORM32 driver is expecting to see a message from either COMP_ID 154 or COMP_ID 171+instance_id. On inspection of the gimbals UART TX Pin, there is no MAVLink messages being sent to the flight controller. As a result, the gimbal is never “found”, and the drivers’ update function never reaches the send_do_mount_control function at the end.
- However, in this mode, the flight controller is sending attitude rates and a number of GPS Position MAVLink Messages. Generating a GPS_RAW_INT message from the flight controller to the gimbal, and taking a snapshot has been able to Geotag the image in some way, however the EXIF data doesn’t appear to be correct.
- It appears there may be some time synchronization going on, however it’s out by ~5.5 years (see File Modification Date Time below).
The following EXIF data is taken from an image taken today, demonstrating Date/Time being incorrect, and the GPS Latitude being completely incorrect.
This is a location of CMAC:
- -35.3632610, 149.1652300
- otherwise, 35.3632610 S, 149.1652300 E
In my opinion, this “improved performance” mode is a half-baked implementation of MAVLink, only handling a subset of the messages (eg. Attitude, GPS, Time). It makes no attempt to publish information about itself, which is required for the STORM32 driver to function. Lastly, there is an implicit expectation that the gimbal is being operated with RC Controls, and not MAVLink messages.
@rmackay9 Do you have a configuration you recommend where you’re able to drive the gimbal with mavlink, while maintaining the improvements from attitude information and geotagging, etc?