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.
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.
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.
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
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.
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.
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).
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)
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.
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.
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.
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.
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
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)
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.
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.
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.
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.
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.