SteadyClip, An Economical Camera Gimbal – Part 03: System Overview

Now that we’ve picked out the important parts, it’s time to get a general overview of the project from a systems perspective.  The trick here is to put in the hooks that we need at this stage of the design so that we have access to the critical portions of the system during debug.  As of right now, the system diagram is shown below.

Since the system is rather simple, I will only add a single UART port for debugging.  This port is critical during the tuning of the PID constants.  I will want to be able to change the constants on the fly during runtime, without having to restart the program.  In addition, any errors or log messages can be read through this port. I’ve opted against creating a USB interface due to the time constraint and complexity of the device.  A UART port should give me sufficient information during debug and there are no immediate advantages in using an USB port. It could be argued that the USB port can provide power in addition to debug, but since the device is designed to run independently on battery, the USB bus powered feature is not a necessity. The device could very well require more than the 500 mA at 5V that the USB 2.0 specification allows.  I’ve opted not to include a level shifter for RS232 to reduce cost.  This means that our UART cable must be 3.3V compatible.

I will take a look at the power requirements for the PSU.  I would love to design a switching power supply to provide better efficiencies for all battery output voltages.  The first versions and proof of concept boards might just be a simple LDO.

The EEPROM is added to give the device some non-volatile memory to store calibration data and user settings if needed.  I’m anticipating this need because we might have more complex control schemes in the future and some non-volatile memory is always handy.  The size and electrical interface has not been picked yet.

The connections to the motor drivers are PWM signals.  I will be using PWM blocks in the PSoc 4 for these signals.  Using the PWM blocks should simplify the software aspect of controlling the motors.  Since each motor driver requires 3 PWM signals with specific timing requirements, we might need to customize the PWM blocks for our needs.  Perhaps we can even include some PID control elements in the custom blocks as well.  I’ll dust off the old Verilog book when I find it, as it might be time for a refresher.

Lastly we have the IMU connection through an I2C port.  This should be a simple affair to connect, but the software portion will be the challenge. The InvenSense parts are pretty complex to program and their register maps are gigantic.  I’ll see if I can leverage some work that other people have done to get my program started.

So it looks like we have some work to do.  I need to build the electronics fast, and get a decent mechanical test rig so I can start fine tuning the software.  I think the software will be the most complex part of this device.  As a hardware designer, getting this deep into software is quite a daunting task and I hope I am up for the challenge.