Remember start orientation when platform is moved or rotated. Possibly record this somewhere so it could be stored in exif for the pano.

The MPU needs to be installed on camera platform, not base - need vertical flex wiring
Adds more complexity but has significant benefits:

Most important is "Shutter zero-motion wait mode": wait until platform is stable relative to the shutter and focal length selected, before activating shutter.

Vertical carrier orientation is relative to platform but as there is no end marker, calibration is not possible. Do not want to keep motors on all the time, but it may be what needs to be done.

Starting the motor at full power causes it to miss step sometimes, depending on which intermediate position it was on. We should start slow and build up to max rpm, then slow back down to reduce shake.

This is a StepperDriver issue mostly likely.

Suggested by Nick Fan: repeat shot if motion is detected during shot.

This is different than waiting for no motion. We probably have to set upper and lower bounds and listen for the entire photo taking wait interval. This interval might be different than actual shutter though (think bracketing).

Right now I put a static list. If there is room in flash, we can pregenerate and store more values and with more precision.

Add a simple progress bar

Integrate Jeff Rowberg's i2clib and MPU6050 library (or something else?) for DMP access.
http://www.i2cdevlib.com/devices/mpu6050#source

This offloads DMP and calibration to the MPU and also gives access to MPU settings and position vectors.

Move slower or faster depending on camera weight.

It could be more like a camera settings page showing all important settings at a glance.
Switch to using graphics instead of text where needed.

Support new Cortex M0 boards:

• Adafruit Feather M0 basic proto https://learn.adafruit.com/adafruit-feather-m0-basic-proto/
• Adafruit Feather M0 Bluefruit (with Bluetooth 4 LE add-on) https://learn.adafruit.com/adafruit-feather-m0-bluefruit-le/overview
• Arduino Zero https://www.adafruit.com/products/2843
• ATSAMD21G18 ARM Cortex M0
• 48 MHz
• 256K FLASH
• 32K of RAM
• no EEPROM
• 3.3V

pin allocation needs revisiting
This focuses on handling the M0 only. BLE integration in #10

Find documentation or decode flash protocols for Sony / Canon etc. If we can fake a flash unit, then we can automatically sync focal length, shutter from the camera.

Need help to find out if these protocols are documented anywhere.

Sony/Minolta: http://mhohner.de/sony-minolta/flashcomp_techref.php
Canon: https://billgrundmann.wordpress.com/2009/03/18/sniffing-canons-ettl-protocol-2/
Nikon: http://cms.diodenring.de/de/electronic/microcontroller/110-ittlanalysis
http://off-the-clock.timothy-nicole-marks.com/computers-and-electronics/nikon-flash-analysis

Canceling pano setup via IR remote ("0" button) goes back all the way to main menu then hangs.
The battery is not displayed.
No controls are responding.
Reset via battery disconnect is the only recovery option.

This may not be related to the remote per se, since canceling is not available on joystick.

When holding camera in place, use a lower current than when moving.

Add an IR transmitter to trigger the shutter.

• simpler: no more shutter cable to plug and unplug and expose opening to dust
• on A6000, IR remote can trigger a full bracketing sequence in one quick press, whereas the wired shutter needs to be held down the entire time otherwise

possible problems:

• strong sunlight issues ?

Shutter speed is not the real value when bracketing or using HDR. In these cases, the "shutter" covers all the shots in the bracket, so it will be a lot slower than reality. But zero motion is based on shutter among other things, so it will require the platform to be more steady than needed.

The effort and code complexity for continuing to support AtMega328 and friends are not worth it and could be better invested elsewhere.

I see no good reason not to move to 32bit platforms. Teensy LC is an Arduino-compatible 32bit ARM board close to the official Arduino Pro Mini price point.

Advantages

• get rid of PROGMEM hacks for split data/code memory, use const as intended
• more freedom to choose add-on boards (displays, etc)
• no more bumping into 2K memory limit (can revisit menu definition)
• get rid of 16-bit integer problems

Disadvantages

• some Pro Mini clones are cheap but I'm not trying to save pennies.

Listen to camera shutter noise (or vibration via accel). This could be useful to adapt to camera settings, but the following would need to be taken into account:

• both front and end shutters make noise
• electronic front shutter (only end shutter makes noise)
• camera profiles
• long exposure

Add a simple divider to display input voltage.

It does not repeat the 360 pano, it repeats the last normal pano.

• next/prev works well
• need a clean way to continue/end pano
  (right now OK ends and there is no way to continue)
• should have a clearer display indicating which button does what

Menu system definition and operation is confusing.

If we remove the dependency on AVR (#57) and therefore the restricted RAM usage, the menu can be refactored to be easier to define and use. Maybe move HID handling inside menu instead of in the main .ino

In normal mode, the pano covers exactly as much FOV as requested. But for 360 pano, we need an extra overlap to wrap around, or the pano cannot be made seamless.

On-Screen level indicator.

Record information for each panoramas taken in EEPROM.
Dump the EEPROM over serial when connected to PC, for identifying the photo sets and settings easier.

The gigapan unit's vertical backlash is significant at high zoom.
Add backlash compensation with predefined values in pano.h.

A nicer option is backlash autoadjust using the gyro.

Record platform movement with motors off, instead of using motors.

Allow freestyle moving of camera/platform, record max top / bottom / left / right reached.

• All of the display and input work could be offloaded to handheld radio remote device but the system is no longer self-contained.

Clean up pano options

• new pano currently needs horiz/vert FOV but configures at start (does not use preset)
• 360 pano needs vert FOV (it currently uses Vert FOV preset)
• repeat pano needs nothing (it reuses saved presets)
• maybe Horiz/Vert FOV are no longer needed in menu ?

The display and controls are not usable while platform is rotating or is out of reach on a tall pole, which I think are common use cases.

Split the code and hardware into

• platform module (sensors, motor control, simple status display)
• remote control module (buttons, joystick, menus display)

The communication between the two can be serial (wired) or radio. The remote can be replaced by phone eventually. May need two boards otherwise.

Investigate if it's possible to use the flash hotshoe for shutter feedback.

This allows figuring everything out from a test shot.

Pins 10,11,12,13 on UNO are hardware SPI CS0, MOSI0, MISO0, SCK0.

See if we can move the microstep control (DRV_M0, DRV_M1) and motor enable (MOTORS_ON) elsewhere. 12 is defined as OLED_RESET but not actually connected.

Having builtin motor enabled feedback via LED is nice but should figure out another way.

Reference: https://www.arduino.cc/en/Reference/SPI

Each next row starts further to the left compared to previous one, resulting in progressively more space lost at the other end.

This doesn't seem to affect 360 panos (probably because there's no row return there)

Investigate ways to control Aref (and motor current) dynamically. It is currently controlled via a pot on the DRV board. Possibilities include

• break pot and use DAC + voltage divider
• use 1-2 digital pins with resistors to drain from divider and create a couple preset intermediary steps by adding resistors in parallel to GND branch of the pot.
• ?

Switch from row-first to column-first might be useful sometimes (360 panos with people)

• with high reduction and gyro feedback, BDC motors can potentially be used
• needs different motor driver hardware and logic
• value is weight/size reduction

Add an RTC.
Options are:

• a standalone DS3231 (works with any Arduino), or
• add a CR16 battery + crystal to the teensy board

Possible uses:

• display timestamp on pano info screen, so a screenshot can be used to match against photo sets.
• record panos taken in eeprom, and dump them via serial later.

(from field testing)

Shutter speeds faster than 1/100 were initially assumed to be unnecessary, since camera responds to shutter command slower than that and the impact of faster times on total shooting time is negligible.

But shutter is also used in the zero-motion calculation (for acceptable angular velocity), and 1/100 is slow for long focal lengths (300-400-500 etc) so it causes unnecessarily long delays waiting for the platform to stabilize.

(from field testing)

With 300mm + 1.4x, the head is moving fast over 4-5 cells so it's very hard to position accurately.

• This should work in parallel with joystick
• how to make use of more keys (cancel would be nice) and still work with joystick ?
• how to interrupt on receive
• smooth motor move might not be possible with IR because of the time to read codes

Same as (or depending on #8) but would need iOS app to control.

Major advantage would be that we can manage many pano profiles and pre-generate stitch files with photos already in position. The pano execution can be GPS-tagged and timestamped and used to identify the photo set once downloaded to the PC. Then we need a tool to preorder the images.

• pano moves to next position and waits for input to go next.
  this can be either OK or > as in the interrupted mode (maybe the layout can be shared)

Setting up a pano over 180 degrees tall with a wide lens causes the system to hang.

It probably happens with tele lenses too but it's less likely to accidentally get there.

Since the split to Executor / Navigator, the single-unit PanoController no longer works.

Not sure if I want to keep it and fix, or just discontinue it. While the self-contained unit does have the set-it-and-forget-it advantage, I think remote control is the way to go.

Normal (motors off) power consumption is about 15mA.

Standby Mode should

• turn off motors (drive nSLEEP LOW)
• turn off display (this is impossible with current wiring) - maybe power display from a high current pin or ?
• put uC to sleep, wake up via button interrupt

Another way to achieve all this is to use one of these for a little extra cost:
https://www.pololu.com/product/2810 or https://www.pololu.com/product/2808 (Mini Pushbutton Power Switch)

This can be simply an issue of calculating and adding the right FOV, or we could custom-define FOV via camera in the way that gigapan does (but is not great because it needs changing with zoom)

• design a smaller pano platform using the 0.5A steppers or servos, and integrated MPU into carrier.

Goals:

• more portable: lighter, smaller)
• thin profile: less nadir problems)
• more battery life

The gyro can be used to determine the gear ratio. This is probably not very useful unless somehow we can change gears easily.

1. Currently platform movement precision is limited by reduction ratio. We need more precision.
2. The FOV angles are stored as integers, which for longer lenses is imprecise (3 instead of 3.48, etc)

Switch the movement calculation code to floats entirely. Should be ok even with Arduino, it only adds <1K to the code.

Need a start delay so the platform doesn't try to move while we're still pushing the OK button. This of course would not be needed with the remote.