09/12/2016 at 21:32 •
Back from field work, and the issue with instruction steps not uploading seems to have been fixed. Just posted a new step now, and should have another three steps up by the end of the day. With luck, should have all the basic assembly instructions done by the end of the week.
09/05/2016 at 05:56 •
I have four more instruction steps written up, waiting for a fix for the "Error 413" problem I'm currently getting when I try to post a new instruction. If I hear from Hackaday by tomorrow that they've implemented a fix, I'll post all those up. Otherwise, they'll have to wait until next weekend or early next week - heading out for 5-8 days of fieldwork (depending on weather) in the boonies.
Once I'm back though, instructions will come fast and furious. Getting the project documentation finished will be my top priority for the rest of this month. With luck all the build instructions will be up by September 20th, and all calibration/operation instructions done in the following week. I also hope to meld all the instructions and relevant logs into a single downloadable PDF; that should be a more helpful construction guide than having everything online. Hackaday deadline for the 2016 competition is October 5th, so I have a little incentive :-).
09/05/2016 at 05:48 •
On my previous RTI systems, the only feedback I get from the controller during the operation is a "beep" when each LED is turned on. Not a lot of information, and also not really necessary, since I get a shutter sound from the camera indicating that it's firing, which indicates that things are working. I've been thinking about adding a more useful feedback tool, and finally broke down and bought one of those little 0.96" 128 x 64 I2C OLED displays that you can pick up for less than $10 if you look. Adafruit has a nice tutorial on their use, along with sample code. Connected the board to a spare Arduino Mega I had lying around, uploaded the test code (after a few modifications), and it worked fine. Then hooked it up to one of my older RTI systems, and modified the control code to add display support. Didn't work. Spent an hour debugging code, checking connections - nope. Connected it back up to the first Arduino, and it worked fine. Hmmm. Grabbed the Arduino that will be controlling the current build being documented, uploaded the code, and tested it. Yup, worked. Sometimes it really is the hardware's fault.
Anyway, here's a couple of pics of the display in action plugged into the MOSFET driver shield that's part of the new RTI system being built. Still have to figure out which parameters to display and how, but I'll get that working when the system is fully assembled. At a minimum, it will show how far along in the process you are, and how much time is left. Full instructions will be written up, including how to install it in the control box ... as soon as I figure out how to do that.
08/20/2016 at 20:58 •
All the issues in the previous log have been resolved, and the RTI control/power system has been tested, and is working!
What's going on here is that I have LEDs connected to matching high-side and low-side channels (i.e. high 1 and low 1, high 2 and low 2, high 3 and low 3, etc., all the way to 8). The Arduino is activating the matched channels simultaneously, which should turn on each of the 8 LEDs in sequence for 1/4 second, as well as setting off the beeper. The system can provide up to 1 A of current to these 3W Cree LEDs. When the lights are off, a +5 positive voltage is turned on to the USB and shutter servo control, which is checked with a multimeter. This setup also doubles as an LED tester, to make sure they're working, and are wired correctly.
Instructions for this step, as well as the Arduino software required, will be up in the near future. And construction of the system is now in the home stretch!
08/20/2016 at 07:16 •
You know that feeling you get when you put a whole bunch of system components together, and they work perfectly the first time? Yeah, me neither. At least, not tonight. First, I installed the MOSFET driver shield board on the Arduino Mega, and discovered that a clever enhancement I had thought up not only prevented the board from seating properly, but shorted out the power supply. Turns out I had forgotten that a section of the shield board sits flush against the ground shield of the Arduino's USB power, so you can't install any components there. I got fooled by the existence of component holes in a place where no components should go. So there were solder blobs and wires that shorted out on the USB shield, and prevented the shield from fully seating into the Arduino:
Removed the offending components and solder, and it fit with no shorts:
Fortunately, it was possible to re-route the offending connection so that it was well clear of the USB shield. I'll have to fix that in the instructions.
Then, the LED that was supposed to light up, didn't. Turned out that my Arduino IDE installation was corrupted on my main computer, and wasn't properly uploading the testing software on the Arduino. Switched over to a different computer, and the software worked, but the LED still didn't turn on. Finally found that one connector that should plug in snugly and securely was loose and floppy, and when I temporarily fixed that, the LED lit up. Yay. Haven't had that problem before, so I'll have to clip the wires off the connector, re-wire a new connector, and see if I can figure out what caused the problem. At least I know the system will do what it's supposed to do now.
And so to bed.
08/19/2016 at 05:29 •
Out on fieldwork for the past week or so, with no Internet connectivity. But did have my laptop, so was able to work on writing up more instructions, and have started posting those. Hope to get a lot more up in the next few days.
08/05/2016 at 03:48 •
Just received the servo and IR remote I talked about in the last log:
Good news is that I think that I can get the servo to work as an automatic shutter for those cameras that don't support a remote control. But that will have to wait until I get the full build instructions done.
Bad news is, I don't think it makes sense to work on connecting the IR remote to the RTI controller. I had hoped there would be a single shutter button, and some kind of easy switch/configuration setup to let you choose which brand of camera you're using. Instead, looks like there's a separate shutter button for every brand (Pentax, Nikon, Olympus, Canon and Sony). Oh, well - it was cheap, and I'm sure I'll find another use for it. Will still be able to implement IR remote capability with an IR LED that plugs into the controller (and which I know works fine); just have to specify the camera brand in software, and upload a new version every time you switch camera brands.
08/01/2016 at 04:34 •
I'm getting to the point in the assembly process where I'm hooking up the interface that automates the camera shutter, and just realized I'd forgotten about my plan to add the option for mechanical triggering of camera shutters. D'oh!
The system currently has four ways to trigger a camera shutter automatically, in sync with the LEDs at different lighting angles turning on and off:
- Through a standard USB cable connected to a Canon camera that supports CHDK, with the CHDK settings set to allow shutter triggering with a voltage pulse through the +5V and G connections.
- For cameras supporting a wired remote, through the same USB cable connection and +5V pulse, this time using an optoisolator circuit to close a circuit and trigger the shutter.
- For cameras supporting an IR remote, a USB-connected IR LED driven by Sebastian Setz's Arduino IR remote library.
- For cameras that can be triggered via a PC program, the Adafruit Bluefruit EZ-Key Bluetooth HID adapter.
For cameras that don't support any of these options, there is the option to run in manual mode, where you push a button to light the LED for a second or two, press the shutter manually, then press the button again to advance to the next LED. Certainly works, and doesn't actually take much longer than the automated approach, but requires you to babysit the system - not fun. So I've had in the back of my mind to add a method to depress the shutter button that could in principle be adapted to any camera.
I've found a few electrical approaches online, where you disassemble the camera, find the shutter switch connections, and wire an electrical switch (like the optoisolator circuit in no. 2 above) to let you trigger the shutter with an Arduino or other electrical control system. Don't like that approach, since you have to take apart the camera and find the right place to wire the shutter connection, and you're permanently modifying the camera. I break things. A lot. The other approach is electromechanical, using a servo connected to an Arduino that will physically depress the shutter button. Lots of people doing this online, with an amazing variety of Rube-Goldbergian attachments. That's a compliment - I'll be lucky if my setup looks half as good as any of these.
The RTI system control box has a USB connector on the back side that options 1-3 above plug into, and I'd like to use that same connector for the servo. Those three options only need two electrical connections, for +V and ground. The servo needs three connections, +4.8-6V for power, +5V to control it, and ground. Options 2-3 would work fine with a permanent +5V connection, since they won't be connected to that line. But I'm concerned about a constant +5V signal through the USB port to the Canon camera using CHDK. It might do nothing, it might freeze up the camera, it might break the camera; don't have any interest in doing the latter. I thought about supplying +5V power to the servo with an Arduino output pin, but that's limited to a max of 40 mA, and a recommended max of 30 mA. I did find one page that suggested that might be possible, but the datasheet for the servo indicated that the servo could draw 160 mA in normal operation, and up to 700 mA in a stall, easily enough to blow out the Arduino pin. Had me stumped for a few minutes, until I had my standard "I'm a dope" revelation - just hook up a couple of header pins for use with a mini-jumper. Put the jumper in, and it supplies +5V to one of the USB output pins; remove the jumper to disconnect the +5V, and you can use the USB output with the Canon CHDK option without problems. If you get tired of putting the jumper on and off, you could even wire it to a switch mounted externally on the controller enclosure.
So, the servo is on order, and figuring out how to make it work is on the agenda after I complete the instructions for the full system. Gotta come up with a simple way of mounting it so that it can trigger any camera, calibrating the servo parameters, and adding the code to the controller system. Stay tuned. I'm open to suggestions.
While I was thinking about shutter issues, came up with an alternative to option 3 above. While the Setz library and the IR LED rig have worked fine on every compatible camera I've used them with, one problem with it is that if you change the brand of camera you use (Canon, Nikon, Sony, etc.), you have to change the IR remote controller code to match the brand (i.e. the codes for Nikon won't work for Canon, Canon won't work for Sony, and so on), then upload it to the Arduino. Flipping around on eBay, found a cheap IR remote that works with multiple brands; cheap as in about $3 for the one I ordered from the US for quick delivery, about $1.50 for one direct from China . If I can figure out how to open it up without breaking it, and then wire an optoisolator circuit to the shutter switch, that would be an easy way to have an IR remote that could easily be switched from one camera brand to another.
07/30/2016 at 18:32 •
Thanks to the folks at Hackaday for their very complimentary blog post on my system - much appreciated. Reading it, two possible questions came to mind:
- Why are custom systems so outrageously expensive (tens of thousands of dollars)?
- Given that my system is so simple, why does it even cost $600 to build?
The answer to the first question is easy. These systems are typically built to the customer's specification, which often requires a design unique to that customer. The parts are often not off-the-shelf, but have to be custom fabricated. A high-quality DSLR and lens is often included, which can easily add > $5K to the cost. The design needs to be rugged, the software bullet-proof, and the whole system has to be warrantied by the builder. The builder will typically have to travel to the customer's location to install the system, and train people on its use. Plus there's the overhead associated with the organization that's building the system. It all adds up. Here's one example of a very nice custom system at the Yale Institute For The Preservation of Cultural Heritage, built by Cultural Heritage Imaging:
That's a really sweet system - if I win tonight's Powerball, I just might order one like it :).
Having said all that, one of my systems is capable of producing comparable results to the one above, even if it doesn't look quite as elegant. Which leads to the next question: given that this is just a bunch of LEDs turned on and off inside a dome, what makes it cost as much as $600? Well, here's a list of the most expensive components in the system:
- Acrylic dome - Cost of this depends on size. The dome for the 12" system whose build I'm documenting here cost about $86; an 18" dome for a previous system cost about $135; and so on for larger sizes.
- LEDs - This is the number one cost. I use 3W/1A Cree LEDs on a star heatsink; smaller/less powerful LEDs just won't cut it. As I mentioned in an earlier log, don't cheap out on these - buy them from a reputable source. Chinese websites advertise "Cree LEDs" for less than a buck each in quantity, but the quality of these is dubious, as I found out to my chagrin. Last time I bought these, I paid about $3.30 each in quantity; just checked the price at LEDSupply, and they're down to about $2.75 in quantity. For a 12" system, you'll need 48 (plus a few spares), so that's about $150; for an 18" system you'll need 64 plus spares for about $200.
- Enclosure - The only enclosure I found big enough to hold the Arduino and accessory parts is this one from Polycase for about $14; however shipping kills you at an extra $10. About $15 more for additional screws, nuts, washers, spacers, bringing the total up to about $39.
- CAT4101 LED drivers and breakout boards- You need 8 of these. $2.92 for the chips at Digikey, but since you get a price break at 10, makes sense to get two spares at $2.62, for a total of $26.20. $2.21 each for the breakout boards. Total of about $44.
- Arduino Mega R3 - About $10 for a clone, about $30 for the brand name board.
- Kynar AWG24 wire - $23
So for a 12" dome we're already up to about $370, for an 18" dome about $470. The remaining parts are pretty cheap, so the total should come in at about $100-125 or so, and that's where the "about less than $600" figure comes from. If you can find these parts cheaper, let me know - I'll add links to the components list.
You could design and build a system with lower-power LEDs at a significantly lower cost, but then you have to deal with substantially longer exposure times even for small domes, and impractically long exposure times for large domes. My first dome started out with 0.5w/0.1A LEDs, and was painfully slow; the next iteration at 1W/0.3A was still pretty damn slow. 3W/1A LEDs are the way to go, even they cost more upfront and complicates the design. Even higher power would be better, and I may look at that for future iterations. But not now.
07/30/2016 at 04:09 •
There's a new file in the file list, RTI-MAGE_components_list.xlsx. This is just the original components list copied over into Excel format, to make it easier to read and print. I will endeavor to keep both parts list in sync, but if there's a discrepancy, you should defer to the Excel sheet (but do let me know).