Tag Archive: camera


So just got done with the end sems, and I decided to get a positional fix from the BTC 3 axis Gimbal using the spare Ardupilot Mega lying in the lab. The final objective, is of course, to track any tagged object autonomously while the drone is in the air. To accomplish this, first I’ll establish a roll, pitch and yaw compensation system, wherein the camera points at the same location irrespective of the angular position of the plane, while it remains in the same position. The next step would be to track a moving object thus, while keeping the position constant, and the final (and most complicated) phase would be to track a moving object while the plane itself is in motion.

From what I’ve read, I’m thinking of using dense optical flow for the tracking-while-moving scenario. This would make the system purely reactionary, thus avoiding the need of ¬†differential GPS and error prone altitude and distance measurements (for geo fixing). How well suited optical flow is to something like this is something I will be looking into.

So, went about programming the ArdupilotMega, and realized that I didn’t know what the pin number for the servo class object was. A bit of searching led me nowhere. I was able to correctly identify the pin to be PL5, but couldn’t see what pin number it corresponded to. A little browsing through the APM code led me to the lil’ devil in the APM_RC.h file. 45 it was then. Suddenly the excel sheet on the website made sense. The sequential numbers on the left hand side were the mapped pin numbers. :/

Things were fun after that, and then we set about trying to figure out how to move the servos on our PTZ camera. And then we got stuck on the math. After much ensuing debate, we shortlisted three very contrasting results. Not such a good thing.

Update: (New Year, yay!) So, figured it out while studying on my Senior project on robotic arms (Have I mentioned it yet? I intend to visually servo a 5+1 DoF arm). It is as simple as equating Euler rotations and Fixed rotations. Now, assuming the camera to be fixed to the plane, the plane will either pitch or roll (It hardly yaws, and we’ll be ignoring that for now). Now to compensate for the motion of this plane, I have to rotate my camera about two *other* orthonormal axes. So, after fixing my frames, I can, say, compensate for pitch easily, as the axis for pitching rotation is the same for the camera. However, for roll, the remaining camera axis is perpendicular to the axis of the plane’s roll. Hence, to get to the final position, one needs to perform two additional rotations about the two camera axes.
To summarize, We need to equate an XZX Euler rotation and a XYZ rotation, where rotation about Z is 0. Attached is my (very coarse) paper derivation.

Note, however, that this result is only mathematical. The actual camera assembly has motion constraints. So that needs to be worked out as well. Anyway, shouldn’t be too tough now.

Cam-era Part II

First of all, a very happy New Year!

Right, now that we’re done with the niceties, moving on to the update, I have now managed to capture pictures from the camera through the USB cable on the beagleboard and transfer the images to my computer using a script running on the beagleboard. I use the gphoto2 command line interface and a simple hook script which rsync’s with a folder on my computer over the network. To avoid the password hassles I created a public key on the beagle and added it to the authorized_keys file in ~/.ssh/ (Of course there aren’t any security issues – Only I use the beagleboard)

However, the delay between consecutive pictures is quite significant (I timed it to ~3.6 seconds between snaps) and it is to be seen whether it would be adequate or not. (I feel that it won’t) I tried setting the mode to fixed aperture, landscape modes, etc. so that it doesn’t waste precious seconds on autofocussing, but no dice. Changing image resolution also didn’t help. So the only alternative seems to take pictures in burst mode and then transferring them. The trigger will have to be done via video(?), and there will be a massive delay between consecutive burst pics. The low resolution for such pictures isn’t too good a thing either. Another mode that the camera supports is a 5 second continuous shot buffer, but it is still to be seen if I can access the buffer on the fly (It seems unlikely though)

So, as matters ¬†stand, unless a DSLR is used, it’s going to be tough trying to get high resolution snaps at short time intervals. Sad, but anyway, let’s save the verdict for the flight test.


Long time since the last post. Fell ill after the previous recce for the camera at the camere-wali-gali in Chandni Chowk. Work had stopped for the last week, and the flight test has been postponed for the first week of Jan, tentatively. As mentioned in the last post, had to look for compact cameras that supported remote capture, which turned out to be surprisingly challenging, as apparently no more compacts are sold with that feature. Perhaps the manufacturers deemed it a frivolous expense.

Anyway, our first choice was the G10, which really blurred the boundary between a DSLR and a compact, but to our dismay, it was nowhere to be found (It’s been long discontinued) After a lot of haggling we finally managed to net the Nikon P1 at a pretty decent bargain, and are now fiddling around with it. As an added bonus, the camera supports WiFi, but well, that’s unnecessary.

Using gPhoto on the command line is pretty straightforward, and the hook-script param is really helpful. All I need to do is add the path of my shell script that transfers the captured image to the ground station via scp, and voila! All the capture business is done. Alternately, I could execute any image processing code on the image before transferring it. But that will require some conversion first, perhaps (unless some settings can be tinkered with) as the images are being captured in .nef format, and I doubt if OpenCV accepts that format (I have to check that, though). Another thing to note is the massive delay between consecutive pictures ~2-3 seconds. I think it autofocuses each time, so if I can omit the autofocus bit, hopefully the camera will be able to shoot faster. Hm. Or possibly try the burst mode. Have to work on all this retrieval stuff for the moment.