Autonomous automotive driving monitor...

st2000

3

« on: 09 / February / 2009, 14:43:09 »

Advertisements

Recalling a past magazine article about a CCD camera, SD flash chip and micro which automatically motored the view out the front of an auto mobile, I wondered if CHDK could be made to do the same.

As some of the CHDK supported cameras are lower priced, approaching this project w/a software only solution becomes more appealing than assembling the above hardware.

Some questions:
1) Taking so many pictures (10 to 20 a minute) , will I reach then EOL of the shutter?
2) Can CHDK take pictures w/o releasing the mechanical shutter?
3) Can CHDK scripting manage the SD storage card?
4) Can CHDK erase the oldest pictures autonomously?
5) Can CHDK detect when the card is full?

Logged

fudgey

1705
a570is

Re: Autonomous automotive driving monitor...

« Reply #1 on: 09 / February / 2009, 15:22:50 »

Quote from: st2000 on 09 / February / 2009, 14:43:09

1) Taking so many pictures (10 to 20 a minute) , will I reach then EOL of the shutter?

Yes you will. I don't know how long they last, but a million shots sounds like a lot. It should last long enough for a fun proof of concept slash cool toy... unless it takes you a lot of testing to build it.

Quote from: st2000 on 09 / February / 2009, 14:43:09

2) Can CHDK take pictures w/o releasing the mechanical shutter?

Yes, it can dump the live view image. It's not an everyday thing to do, but the motion detector debug commands have that included (without any compression). That image is of course quite crappy in quality and resolution compared to actual photos from the same camera, especially in the dark. Video mode also uses live view image, but you can't stream that outside the camera or process it in any way in camera.

Quote from: st2000 on 09 / February / 2009, 14:43:09

3) Can CHDK scripting manage the SD storage card?
4) Can CHDK erase the oldest pictures autonomously?

Yes, Lua can list and delete files, among other things. See the Lua scripting section, there's an ongoing effort to provide some libraries/examples to help users write scripts that do these things.

Quote from: st2000 on 09 / February / 2009, 14:43:09

5) Can CHDK detect when the card is full?

Yes.

But your real problem is either

1) how to process those images in the camera (the ARM CPU is a general purpose processor and it cannot do advanced image processing in real time and we don't have access to the DSP/whatever compresses JPEGs etc in the camera), or

2) how to move images from the camera for further processing, or any other data for that matter.

#2 is a problem, because we do not have full control over USB. Eye-Fi is the smoothest thing that's being used, and I hear it requires frequent reboots. I experimented with PTP in REC mode quite successfully, it mostly works (see the devel forums for further info, search for "webcam operation"). There's no support ready for that in current CHDK builds, though.

For signaling, you can encode messages in LED blinks. For real, that's the only way of communication out of the camera that actually works for all models (well, almost).

IMO, if you go with live view, you're really better of with a USB or composite video (web)cam as they are lighter and cheaper and the quality is not that different.

Logged

st2000

3

Re: Autonomous automotive driving monitor...

« Reply #2 on: 09 / February / 2009, 16:19:13 »

I don't think quality is that important. The point is to record events should something "regretful" happen. As for transferring images. If one can simply turn the camera off and extract the SD card that would be great. I assume the last several minutes to several days of photos (depending on the size of the images and card) will be preserved on the SD card for later inspection on a desk top. Motion detection with an upper frames-per-minute limit would be perfect.

If the MSR or used price of low end compatible cameras is around $100 I would think the cost and effort to put together a similar system using parts or subsystems would be higher.

Now I'm wondering if meta data or overlay text can be included into the images?
Can CHDK do that?

(This is an interesting project!)

Logged

fudgey

1705
a570is

Re: Autonomous automotive driving monitor...

« Reply #3 on: 10 / February / 2009, 14:18:42 »

Ah, in that case CHDK suits you fine, especially if you're up for writing scripts or tinkering with its source code to customize things to full potential. I somehow got the idea you wanted the camera to be the project's eyes in real time, and that's way tougher than just documenting stuff.

The quality of video from these cameras is surprisingly good if there's enough light. It can be triggered using motion detection too to avoid filling up the card too soon. S series cameras (bigger and more expensive) are even able to shoot stills while recording video, which I think might be perfect for your purpose. A script can of course do that too, but there will be a fairly long pause between the video clips.

Note that USB supply voltage ("cable detect") can be used as a remote trigger to CHDK. If you can think of something other than motion detector in your system that you want to (for instance) make the camera start shooting, you can use that.

Quote from: st2000 on 09 / February / 2009, 16:19:13

Now I'm wondering if meta data or overlay text can be included into the images?
Can CHDK do that?

Well, we do have a datestamp patch somewhere, but it's not in current CHDK and AFAIK it doesn't allow custom text to be burned to the image. But I believe arbitrary embedded text is possible by modifying that patch. We don't currently know how to touch JPEG metadata (EXIF) from the camera.

The easiest approach for metadata output (DNG aside, that's too slow for you and fills the card quickly), readily available in CHDK is to write whatever text you may wish to store to a text file. If need be, you can later take text from that log file and embed it to your images on a PC.

Logged

st2000

3

Re: Autonomous automotive driving monitor...

« Reply #4 on: 12 / February / 2009, 10:17:56 »

Quote from: fudgey on 10 / February / 2009, 14:18:42

Ah, in that case CHDK suits you fine,
,,,<cut>...
The quality of video from these cameras is surprisingly good if there's enough light. It can be triggered using motion detection too to avoid filling up the card too soon. S series cameras (bigger and more expensive) are even able to shoot stills while recording video, which I think might be perfect for your purpose. A script can of course do that too, but there will be a fairly long pause between the video clips.

Hum, documentation yes, video ... well, I was thinking stills. I would have thought it better for a number of reasons. Mostly because stills probably take up less space. But also because you can manage storage by erasing the oldest stills. And, I'm interested in autonomous operation in a car looking out the front. The camera, if in a video-recording-mode would most likely operate non-stop.

So, is it possible to accumulate stills w/o using the shutter (which has a finite life) based on motion detection?

Also, will these stills, if possible to create, be compressed or raw?

Quote from: fudgey on 10 / February / 2009, 14:18:42

...<cut>...
Quote from: st2000 on 09 / February / 2009, 16:19:13
Now I'm wondering if meta data or overlay text can be included into the images?
Can CHDK do that?

Well, we do have a datestamp patch somewhere, but it's not in current CHDK and AFAIK it doesn't allow custom text to be burned to the image. But I believe arbitrary embedded text is possible by modifying that patch. We don't currently know how to touch JPEG metadata (EXIF) from the camera.

The easiest approach for metadata output (DNG aside, that's too slow for you and fills the card quickly), readily available in CHDK is to write whatever text you may wish to store to a text file. If need be, you can later take text from that log file and embed it to your images on a PC.

I asked about the embedded text because what I really want is to log current data with the pictures (i.e. speed for instance). It sounds like that feature, if possible, is in need of a developer. But what I should really have been asking is how to get that data into the camera. I just assumed the USB port was available for this.

Along those lines, can the USB port power the camera? If the intent is to operate autonomously for years, until the most recent data is needed, battery operation is undesirable. My main goal here is to use stock hardware and re-purpose it with software.

Someone did find the article describing the hardware equivalent of this thread's subject:
http://www.circuitcellar.com/archives/viewable/Aparicio203/index.html
...if you read (parts of) this, I think you will understand what I'm trying to achieve.

...thanks for you help.

Logged

fudgey

1705
a570is

Re: Autonomous automotive driving monitor...

« Reply #5 on: 12 / February / 2009, 14:43:39 »

Quote from: st2000 on 12 / February / 2009, 10:17:56

Hum, documentation yes, video ... well, I was thinking stills. I would have thought it better for a number of reasons. Mostly because stills probably take up less space. But also because you can manage storage by erasing the oldest stills. And, I'm interested in autonomous operation in a car looking out the front. The camera, if in a video-recording-mode would most likely operate non-stop.

I'm not sure what you mean/want... motion detector works during video record and it can be written to stop video record when motion stops. Motion detector also works in still shoot modes when the camera is idle (or shutter half pressed), waiting seconds or hours for motion to come before shooting. But motion detector does NOT work during burst shooting. It only works between shots or between bursts. Not between each shot of a burst. So if you want motion detector and a steady 1 fps burst, without 10 second delays every now and then, you must use video mode.

Quote from: st2000 on 12 / February / 2009, 10:17:56

So, is it possible to accumulate stills w/o using the shutter (which has a finite life) based on motion detection?

Also, will these stills, if possible to create, be compressed or raw?

Motion detector has a debug function (not enabled by default in current builds, requires custom build but it's easily configured) which dumps the viewport to a file. It's completely "RAW", the format is not documented (well it is, but you'll have to search the forums to find it) and definitely not anything any image processing software will open. It's completely uncompressed, but you could probably port zlib to the camera if you wish to compress it a bit.

I think that image always writes to the same file, so your script would always have to rename it after each "shot".

I'm not sure but you'll probably get better image quality and definitely better compression (mjpeg) in video mode.

Quote from: st2000 on 12 / February / 2009, 10:17:56

I asked about the embedded text because what I really want is to log current data with the pictures (i.e. speed for instance). It sounds like that feature, if possible, is in need of a developer. But what I should really have been asking is how to get that data into the camera. I just assumed the USB port was available for this.

No, we don't have any communication to the camera. USB is a big black hole to us. The remote trigger uses USB supply voltage detection. ewavr experimented with another type of (non-standard) USB messaging a few months ago, but it turned out to work only on some cameras and wasn't finished.

Quote from: st2000 on 12 / February / 2009, 10:17:56

Along those lines, can the USB port power the camera?

No, you can't get enough power from USB. Most cameras have a DC power jack, Canon sells adapters shaped like batteries for those that don't.

Oh, and I believe nobody's tried what happens when the camera stays powered on for too long. It has a 32-bit (probably signed) ticker in it, counting time in 1 ms resolution (in 10 ms increments). When it wraps, the camera or CHDK probably crashes.

Also, shooting lots of jpegs (whether or not you delete them, because the way we know how to delete images in Lua doesn't go thru to Canon firmware properly) eats up a lot or RAM, mine crashed after only about 7500 timelapse images to lack of RAM or some bug.

Logged