Gimbal Requirements: Discussion and Planning

Movement Requirements

high priority

low difficulty

As a ground crew member, I want to be able to track a target manually and view different areas. Therefore, I require to be able to move the camera to see the area below the drone either via pitch only or pitch and yaw controls.

Decision: Camera will have both pitch and yaw. 180deg of pitch and 360deg of yaw.

• Camera Type confirmed → Task for CV (likely Arducam).

• Select servo motors or brushless gimbal motors.

  • Firmware is biased towards servo motors due to ease and power consumption

• Decision: Gimbal positioning

  • Grabber positioning must be considered alongside gimbal positioning.

  • Prefer to have the gimbal on one axes of flight.

• Decision: Weight must be considered for motors and design.

• Process: Camera selection → Gimbal Design → Print + Validation.

1. CV: Confirm Camera type for mechanical. Blocking 3.

2. EE: Select specific servo motor for dimenions. Blocking 3.

3. Mechanical: First draft of CAD model.

Movement Tracking

high priority

low difficulty

As a ground crew member or CV developer, I want to know where the camera is currently pointing relative to a fixed point on the drone.

• Board for the gimbal will contain an IMU on it to track the position of the camera.

• MPU6050 IMU (Arduino) currently being tested, this model may be confirmed based on our tests.

1. CV: Confirm that the current IMU is sufficient or not.

2. EE: Start designing board (see below)

3. EE: Select IMU (if insufficient) and integrate on board.

Self-Stabilization

med priority

med difficulty

As a ground crew member or CV developer, I want to ensure that the camera will always point at the area on the ground at which I set it to.

• Because the gimbal has it’s own IMU, we know the position of the gimbal therefore applying the appropriate motor controls is just a matter of using the right PID.

• High level architecture: control input → set target position → IMU output → gimbal controller provides control to bring camera to target position.

1. Everything for the IMU above.

2. FW: Finalize and purchase gimbal controller (arduino nano likely)

3. FW: Gimbal input control is done, just PID tunings are required.

4. SW: How to set the target cooordinates (will it just use wherever the camera stops moving after control? etc.)

Gimbal Control: Human Control

high priority

unknown difficulty

As a ground crew member, I want to be able to control the position of the gimbal.

• FW doesn’t want to have a seperate control system just to minimize complexity, CV wants a seperate complexity to minimize CV comms complexity.

• Decision: Seperate gimbal from cv communication?

1. SW: FW will consider their research for having a seperate control channel. CV will provide a diagram showing how gimbal control from the ground would work.

2. EE: Design gimbal control board.

   1. We need to confirm the requirements that EE needs. Consider how power needs to be distributed and taken in, how communications will work.

   2. EE will perform electrical architecture design based on requirements.

   3. Select components and create footprints.

   4. Fabricate board.

Gimbal Control: API + Interface

high priority

low difficulty

As a CV developer, I want to be able to programatically control the position of the gimbal.

• Sahil has said that he’ll be able to write an API for the Arduino that we can use to communicate with it.

1. FW: Design API, blocked by designing comms b/w controller and jetson, PID tunings and code for control.

2. CV: Detail control requirements and schema.

3. EE: Communication protocol between the jetson and the gimbal controller + power for the gimbal controller.

Gimbal Control: Autonomy

unknown priority

unknown difficulty

As a ground crew member, I want to be able to constantly view the targets on the ground without manual control input.