I would like to propose the following enhancements for your consideration
Consider the following use case:
A photographer wishes to capture a high resolution 360 degree panorama from a multicopter. In order to do this the photographer needs to position the multicopter, place it in Loiter mode, and then run a mission command sequence that will take 32 to 40 photos in a grid of 8 columns by 4 or 5 rows. Each row is established using a specific PWM sent to the pitch control of the camera gimbal. Each column is established by the yaw angle of the multirotor. The only way to do this currently is by using 5 or 6 waypoints/events for each photo (total of up to 240) which exceeds the number of allowable waypoints. For panorama examples, visit 360cities.net.
Proposed enhancements:
Add the ability to store and read eight double byte signed integer user variables, USER-VAR-1 through USER-VAR-8. There might be an argument for a larger number of user variables in commercial or emergency services use cases, but for hobbyists with limited flight times, eight will probably be enough.
Add the ability to set and modify the value of the user variables by adding a double byte signed integer value to the user variables. For example, commands such as “SET-USER-VAR” and “ADD-TO-USER-VAR”. The first variable in the command (an integer 1 through 8) points to the corresponding User-Var variable number and the second variable in the command would be the double byte signed integer value to set or add.
Add the ability to utilize the user variables as values in the DO-SET-SERVO and CONDITION-YAW events. Perhaps define two new events such as DO-SET-SERVO-USER-VAR and CONDITION-YAW-USER-VAR where the variable in the command (an integer 1 through 8) points to the corresponding User-Var. Value checking to insure appropriate values and exception posting in the log would be helpful.
Leverage the work done on the DO-JUMP command and create a DO-JUMP-WHILE-LT, DO-JUMP-WHILE-EQ and DO-JUMP-WHILE-GT commands that will jump to a specified mission command while a specified USER-VAR is either less than, equal to or greater than a specified double byte signed integer. The first variable in the command (an integer 1 through 8) points to the corresponding USER-VAR and the second is the integer to use in the comparison.
There’s probably an argument for DO-JUMP-IF-LT-THEN-ELSE, DO-JUMP-IF-EQ-THEN-ELSE, DO-JUMP-IF-GT-THEN-ELSE constructs but I don’t have a personal use case for them. Although I can see how it might be useful on longer commercial and emergency services missions, especially if they could test status variables such as RSSI, battery voltage, fuel level, RC channel PWM values, distance to next waypoint, distance to home, altitude, and telemetry health.
Example
Using the new commands, the 5x8 mosaic of 40 photos for a spherical panorama could be captured using 25 waypoints/commands:
LOITER_UNLIMITED, LAT=0, LON=0, ALT=0
SET-USER-VAR, VAR=1, VALUE=0
WAYPOINT WAIT=0, LAT=0, LON=0, ALT=0
SET-USER-VAR, VAR=2, VALUE=2000
WAYPOINT WAIT=0, LAT=0, LON=0, ALT=0
CONDITION-YAW-USER-VAR, USER-VAR =1, REL/ABS=0
WAYPOINT WAIT=4, LAT=0, LON=0, ALT=0
DO_SET_SERVO-USER-VAR, Chan=9, USER-VAR=2
WAYPOINT WAIT=2, LAT=0, LON=0, ALT=0
DO_DIGICAM_CONTROL
WAYPOINT WAIT=2, LAT=0, LON=0, ALT=0
ADD-TO-USER-VAR, VAR=2, VALUE=-200
WAYPOINT WAIT=0, LAT=0, LON=0, ALT=0
DO-JUMP-WHILE-GT, COMMAND #=12, VAR=2, VALUE=999
WAYPOINT WAIT=0, LAT=0, LON=0, ALT=0
SET-USER-VAR, VAR=2, VALUE=2000
WAYPOINT WAIT=0, LAT=0, LON=0, ALT=0
ADD-TO-USER-VAR, VAR=1, VALUE=45
WAYPOINT WAIT=0, LAT=0, LON=0, ALT=0
DO-JUMP-WHILE-LT, COMMAND #=10, VAR=1, VALUE=361
RETURN-TO-LAUNCH
While I spent many years doing software project management, I don’t think my programming skills are current or good enough to help with the programming (and the engineers I worked with would agree!). However, I would be happy to help with requirements, testing and user documentation.
I would like to propose the following enhancements for your consideration
Consider the following use case:
A photographer wishes to capture a high resolution 360 degree panorama from a multicopter. In order to do this the photographer needs to position the multicopter, place it in Loiter mode, and then run a mission command sequence that will take 32 to 40 photos in a grid of 8 columns by 4 or 5 rows. Each row is established using a specific PWM sent to the pitch control of the camera gimbal. Each column is established by the yaw angle of the multirotor. The only way to do this currently is by using 5 or 6 waypoints/events for each photo (total of up to 240) which exceeds the number of allowable waypoints. For panorama examples, visit 360cities.net.
Proposed enhancements:
Example
Using the new commands, the 5x8 mosaic of 40 photos for a spherical panorama could be captured using 25 waypoints/commands:
While I spent many years doing software project management, I don’t think my programming skills are current or good enough to help with the programming (and the engineers I worked with would agree!). However, I would be happy to help with requirements, testing and user documentation.
Phill