Basically I thought of implementing a solution to move the camera between shots to increase the coverage area and efficiency in mapping missions. More details on the pull request
I’d like to know your thoughts on this solution:
PX4:master ← igorsgcampos:CAMPOS
opened 02:33PM - 05 Oct 20 UTC
**Problem**
A solution commonly used to increase the coverage and efficiency in… mapping surveys is to have multiple cameras at oblique angles to capture a wider areas per flight line, this also has potential benefits of capturing more data from facades and tall objects. However, adding cameras increase cost and complexity of the equipment, on the other hand, mapping cameras are generally capable of shooting multiple frames per second and are usually triggered about once every two seconds or less frequently in mapping missions, we could better use the hardware capabilities if we moved the camera mount between shots while decreasing the shooting distance to keep the overlap settings.
**Solution**
I decided to implement a solution that uses the already existing VEHICLE_CMD_DO_SET_CAM_TRIGG_DIST, plus some unused parameters, 4~6, to issue VEHICLE_CMD_DO_MOUNT_CONTROL between camera shots to move the camera from left to right in stages, right after it passes half the shooting distance, allowing time for mount actuation and camera exposure. To keep the frontlap the solution expects the GCS to adjust the trigger distance accordingly. The parameters usage are as follows:
- 4: number of oblique positions (this will generally be 2 or 3, but could be more, depending on desired frontlap, flying speed and hardware capabilities (how fast are the camera and mount))
- 5: the maximum angle to roll the camera left and right from the center, the solution calculates the interval angle between positions from this information and the previous parameter
- 6: the pitch angle for mounts that support pitching
https://github.com/PX4/Firmware/pull/15882
**Implementation**
I proposed the change to mavlink standard here: https://github.com/mavlink/mavlink/pull/1508
I added it to QGC here: https://github.com/mavlink/qgroundcontrol/pull/9103
**Alternatives**
Other way would be to add a new command, but since it has many aspects that are essentially the same as the CAM_TRIGG_DIST, I thought it would be better to add a few parameters to the existing command, as it would also allow it to work under Mavlink 1 with the limited number of 255 commands.
**Test data / coverage**
I tested it with the gazebo_typhoon_h480 model and checked the outcome from the video stream in QGC.
**Additional context**
Later I plan to write a paper comparing the gains in area coverage and any accuracy change from using this solution with relation to the traditional survey mode. I am feeling confident about a positive outcome.
2 Likes
