Ideal Hobbyist Webcam


#1

As we’ve been developing OpenROV, we've meticulously tried to find the off-the-shelf parts that work best for our application. This has involved a lot of long discussions with companies and suppliers. One of the pleasant surprises of those conversations have been that many of them have expressed interest in developing products that specifically cater to our needs and the needs of similar hobbyists and DIYers. (A wise move if you ask us.)

Recently, a prominent developer of OEM webcam parts said they’d be interested in hearing our thoughts on the ideal webcam for hobbyists. I started creating a list of all the futures that I thought might be nice. I emphasize “might” because I just want to brainstorm all the wild ideas first, then later go through and filter things that aren't practical or wouldn't be worth their cost.

I thought it would be fun to see what you would add to the list. Remember, this is a list of features that would be useful not just for OpenROV, but for hobby and robotics projects in general. Please leave your thoughts in the comment section below!

Here’s what I have so far:

Small/ low profile

  • Wide angle (or changeable lenses)
  • Many features controllable through software (zoom, focus, frame rate, etc)
  • Female USB plug (instead of permanently attached wire)
  • Open Source/ Open Hardware (or at lest extremely low level specs available to users)
  • Forum for the camera hosted by the manufacturer
  • Other (non USB) low level digital interface options (I2C, SPI, etc)
  • Option for built-in compression or raw data
  • Multiple output formats
  • Low power consumption
  • Light level detector that outputs data to USB
  • Onboard compass (data through USB)
  • No IR filter/ easily removable IR filter
  • Low Cost

What USB camera might we want in the next OpenROV Kit or AddOn
#2
  • Flexible mounting options. A set of tapped or thru holes would be nice. Being able to mount it in a couple of orientations using the same hardware would be ideal

#3

Continous adjustment of white balance through software (typically adjust white balance by depth).

Programmable options for logic outputs or actions on events from video feed or logic inputs.

Options for adding shape or color identification, built in OCR.

Virtual pan tilt, Pelco-input.


#4

It would be nice to have a complete software control of the video features. Contrast, luminosity, and so on. The old Philips Toucam Pro has this kind of contol.

...wifi control?


#5

What about the GoPro?

Lots of DIY drone projects RC-groups and hardware mods, are working to include this camera on their systems.

It already has a lot of extras to adapt it for use in various environments. It's rugged, its light, its small, and have interface that could be connected with the controller.


#6

Hardware compression


#7

Ah - I see you already had compression on your list.

I think some applications will want to try stereo (3d) recording. I don't know if the camera itself needs to support this or if this is a higher level function.


#8

The GoPro is the most versatile cam, but fails on the "low cost" point (its half the cost of the ROV).

I think these options are already a lot if we want to keep the cost low (already the onboard compass is actually a bit over the top for a low cost maker/DIY oriented cam).


#9

Agreed about the point of cost. I think that after we capture a good list of ideas, we can look at which ones would be worth their cost. It seems to me that most hobbyists would not want to pay more then about $60 for this sort of thing. Would you guys agree?


#10

I agree that GoPro a bit costly. On the other hand, the camera is probably the single most important sensor of the whole system, and should be of high quality. Perhaps it would be an idea where you have options for several cameras, depending on your needs?


#11

Yeah, I think that's a valid idea. In fact, you'll notice that the cavity in the front of the Electronics Chassis is sized to fit a GoPro perfectly. That's no coincidence- I had that in mind when designing the chassis, but after realizing that I couldn't afford the volume of a GoPro with all the other electronics, that the GoPro can't currently be configured to work like a live USB webcam, and that it has a waterproof housing that allows it to be mounted outside anyway, I stopped really considering that contingent in the design. What we've done instead is attach the GoPro to the top of the ROV or to its forward cross bar to record HD video while driving via the onboard camera that is lower resolution. I do agree about the video quality being very critical. The most equivalent USB webcam I could find is the Genius F100 Ultra Wideangle Webcam. It can shoot 1080P video at a 120degree wide angle.


#12

Linux driver is a must. Many cameras that have compression do not support an open source driver. Further most Linux cameras are driven via USB. As much as standardizing the a camera interface on I2C or SPI may seem like a lowest common denominator, it will also mean interfacing the higher level camera driver to the lower level I2C/SPI interface - a manual process. With USB, once the USB driver is running on Linux, and there is an available driver for it on linux, the enumeration with the camera driver is fairly automatic. With USB you can also test on a normal Linux PC host.


#13

Support both isochronous and bulk transfers at the USB level.

Most cameras do isochronous transfers which reserve enough bandwidth for the streaming images and guarantees time on the bus for the data to flow. Sounds good, but it reserves enough bus time for worst case transfer, and even if you are using MJPEG or similar formats you will find that you can only have a couple cameras on at a time. (The amount reserved varies by camera, some don't seem to even care if you set their resolution down, they just seize a vast chunk of bandwidth.)

The other problem with isochronous transfer is that there is no error checking. USB errors tend to manifest as missing runs of bytes. For a YUYV or similar frame you can detect missing data by the frame length, but for MJPEG or other compressed formats you need to defensively parse the encoded frame to verify that there are no missing bytes. This becomes especially important as you go to longer cables and USB extender systems (which are generally awful for dropping bytes).

Bulk transfers don't reserve bus bandwidth, but when you transfer a frame, you know you got the whole frame. You may miss a frame if you are trying to watch more cameras than can be crammed down the USB at a time, but you are in control of that. It becomes very easy to watch many cameras at reduced frame rate or resolution and go to full speed on interesting ones.


#14

Not necessary in the same camera, but hardware pan, tild and zoom would be nice as well as a stereo camera to measure distances.

Also the camera should work well in low light situations.


#15

Most USB cameras support Isochronous transfer types, and some support the USB video class. This means we have drivers available with little or no porting effort.

USB Bulk transfers do have the ability to detect and retransmit blocks if there is an error detected. With isochronous transfers, the host will also detect errors, but it has no facility to retransmit the bad packet. In my experience, I rarely see errors on the USB at both Full speed and Hi-speed so this is likely a non-issue.

My main concern is if there is a driver for the camera for the particular mode we want to use. If there is a driver available that will drive the camera in Bulk mode great. If there is a driver available for Isochronous but not bulk, then Isochronous is great as well and an acceptable solution.

While bulk transfers offer some advantage on a quiet bus, data can be delayed if we load up the bus with other peripherals. This is because bulk transfers have no guarantee as to when the data will be transmitted. Just that when you receive the data, it will be received in the order transmitted and error free. If you are driving the ROV by the camera and the USB gets really busy talking to other peripherals that could be a problem. With the current design being a single USB camera on the bus this is a non-issue.

Since the USB is fully contained on the ROV and not used as a tether to the surface, the cable can be limited to a length of less than 1 meter so I do not expect to detect any errors at all.

If we go with a USB camera that uses Isochronous endpoints in the interface, it would be good to verify that the error rate is less than 1 dropped frame in 10 minutes of runtime while running right next to all those motors turning on and off. With this error rate, the video can be recorded for posterity without any appreciable loss of quality.


#16

I see that Microsofts lifecam 5000hd is used as a “standard” for Openrov. Is 720p at 30fps the maximum we can transfere on our 10MBit tether system?


#17

Sparkfun released a new product today that might satisfy a number of the situations.... its called the HackHD camera, and is basically a decased GoPro camera. HD recording to SD card, live composite video out, and can be told to stop or start recording via a microcontroller.

https://www.sparkfun.com/products/11418

It's cheaper to buy from the manufacturer, at least until the price increase.
http://hackhd.com

The downside is it isn't compatible with the way OpenROV currently handles video, without either changing the tether design or adding a USB capture card to the ROV (assuming the beagle bone, can even support that)


#18

I found this thread because I am interested in using consumer webcams to build some scientific lab equipment: a plate / gel imager, a digital microscope, and possibly a spectrophotometer.

The Logitech c910 HD webcam is an interesting option. Its zoom, exposure, and white-balance can all be controlled via windows drivers. Sadly, Logitech's installation package for OS X doesn't provide such advanced drivers (I think the camera just presents itself as a UVC device).

However, a lone coder - Sluggo at dm9.se - is working on his own OS X libraries for the c910 (and possibly the MS LifeCam). He just updated a post about it, indicating he is getting closer to a release. The screenshots are tantalizing. So, if you're interested, go show some support on his forum.

Additionally, let me just say that I'm super interested in a low-cost hobby-friendly camera WITH great driver support on Windows, OS X, and Linux. I would buy a ton of those. And so would the amateur astronomy community, and the Multitouch community, and the scientific community... etc etc etc.

Mac


#19

Sluggo released version 1.02a of his uvc-ctrl app for Mac OS X. This app allows users to manually control advanced webcam features, such as exposure, focus, whitebalance, etc.

I have tested it on OS.X 10.7.4 with a Logitech c910 (1080p) webcam, and it works pretty well. I could change the focus, exposure, white balance, contrast, and other settings.


#20

Big pixels, or analog-binning. This helps in low-light situations.

Digital rescale/zoom over a larger input frame ( sensor bigger than viewfinder output).

The compass doesn't seem that helpful. You could easily toss your own on the board, plus cameras tend to generate a lot of electrical noise.

Changeable lenses is a great idea. Maybe a standard small-sized mount(c-mount)?

A year or so ago I'd've said built-in-compression, like a streaming JPEG mode, would be good, but nowadays a BeagleBone can compress h.264 just fine.