HiIm new with Arduino and I dont remeber too much about programming.Im a scuba diver and a photographer and Id like to build my personal underwave photo huosing.Id found something interesting about the DIY housing but I need some help about programming the Arduino.Could someone tell me which are the basic command to open a session with a Canon Eos and change Mode (M,Av,Tv,P,A), speed, shutter, iso and exposure compensation?Regards

Well, Arduino alone is best suited to simple shutter control- the shutter release is a simple switch.

However, the "basic" command you are talking about doing.. control over all of the functions of the camera, remotely, via USB.. that requires a USB host, which is not a small project by any means.. in fact, many (including me) have worked on USB host code specific to camera control.. even specifically to Canon.

I'm soon going to embark upon another whack at it, I'm purchasing a daughterboard for my arduino which provides rudimentary USB host block transfers and interfaces with I2C, so we'll see if I can get a workable Canon kludge protocol (not implementing Live View or data transfer) running with that.

It depends a little on how you want to address the problem.An USB solution will indeed require an USB-host/ lots of programming.That may.... be possible with an 8-bit arduino and a load of work, but a 32-bit platform will probably be better.

You could also use Arduino to drive motors/servos, touching buttons and changing settings inside the housing though.Don't know much about diving, but have seen some nice wireless setup for Kite Aerial Photography (KAP) using the robotic approach. A google on KAP + Rig might give you some ideas.

I've been developing Arduino digital camera control via USB code for quite some time, see here -> http://www.circuitsathome.com/category/camera-control . Canon EOS and certain (expensive) Powershot cams are well-understood already, pretty much anything available via buttons/menus can be done by Arduino via USB. This is not a beginner-level project though.

been keeping an eye on your project for a while.. the USB implementation onchip seems to be coming along.

However, I picked up (and am waiting for delivery) a "CH375B" module off of ebay which may prove to be a much better solution. I'm usually a big fan of doing most things in software, but USB hosting and protocols are PAINFUL. By everything I've been able to read up on these chips (provided on a board, 5v supply, it's intended as a prototyping module), it covers all of the painful items, leaving us with a choice of whether to use parallel, UART, or SPI for interfacing. It apparently handles storage devices natively, but more important, it also handles full support of block and command-mode transfers.. which SHOULD be everything needed for a full PTP + Canon implementation. I'm very eager to play with the module, as if can do what it says, then we here should be able to write hardware-specific drivers for a list of items it would be very nice to be able to talk to... like USB network dongles, USB printers, USB bluetooth modules, and a host of other extremely useful devices. I'll admit it- I haven't gotten further into the project so far because of the grief of USB Host mode complexity.. if a cheap module like this will remove the PITA work, I'll be far more likely to pick up on the fun stuff..

I got this one on the cheap for $6 shipped, but they sell for like $15 otherwise... possibly well worth the lack of grief!

I'll be posting heavily about it once I get it; I haven't seen writeups on the forums about the module, and it could really be a game-changer for hobbyists.. think of the misuses of hardware that will be unleashed. USB webcams and microphones are a immediate thought, as well as keyboards and other HID devices. The device supposedly can handle multiple endpoints, so you could simultaneously handle (via hub) multiple devices.. including USB flash memory.. even EyeFi cards, I suppose (EyeFi are memory cards for photo use that are actually wifi, and typically linked to a directory on a desktop machine).

CHDSK implementation should even be possible in a limited form.. so here's to hoping that module lives up to it's hype...

What this thing does is provides interface to USB transfers, which, no matter how scary they look for a newbie, are a minor thing and cover about 5% of what is needed to get functional USB host system and about 0.1% of what is needed to get functional camera control system. It won't work with hubs either since PRE is not implemented. Overall, this device looks quite lame an I doubt any real developer would be willing to spend time developing free software for it.

Well, despite your concerns, This particular developer is willing to give it a chance before dismissing it totally out of hand.. even if PRE is not fully implemented, allowing only one device to be slaved, slaving one digital SLR is pretty much what most users want. In reality, most people looking for this type of thing are not looking to transfer or process the image data, merely trying to access the command and control systems on the camera, usually for some type of automation purposes like HDR. Controlling zoom (like CHDSK), AF points, and the like is overkill- if the tool can manage ISO, shutter and aperture then it covers 90% of what folks look for. Since the command and endpoint implementations are supposedly there, and the camera deosn't mind a bit of spoofing (see CHDSK) implementing both PTP and Canon extensions should be possible. Believe it or not, there are "real developers" out there who don't fear new technologies, especially if the payoff is as big as an effective, flexible USB host for MCU's. I think that your efforts are stunning, don't get me wrong- that's some top shelf coding- but it is pretty heavy stuff, far beyond most Arduino hobbyists. If these guys can successfully make a cheap module that does it, that's a lot of complex code that now becomes a "black box"- which for hobbyists is a lot more reasonable to use than hundreds of lines of complex code. As a former professional programmer, all I can tell you is that sometimes it doesn't make sense to re-invent the wheel, particularly in an easy-to-carry rectangular shape. Re-inventing the wheel is sometimes very useful in learning how wheels work, but it's quite unlikely your wheel is going to be any rounder than the rest...

I remember hearing a lot of "That's junk" quotes about ethernet shields with the ENC chip before they proved themselves, I'm willing to risk the six bucks and a little effort to see if the chip lives up. In consideration that they have had success with their USB Slave implementations, I'm cautiously hopeful that there may be usable (but maybe needing a bit of tweaking) interface chip here, at reasonable cost.

Hosting USB on a 328 is possible.. that's been proven (V-USB, and others).. but maybe offloading that mess onto an application specific protocol chip like they have supposedly done can make USB a lot more friendly to use for experimenters like us... here's to hoping it's half as good as they claim..