Various thoughts

I would be willing to help you with coding or testing; but I am booked up for 2 weeks.  On second thought better make that a month (or so).  I would need a lot of guidance. While I know how to compile and write programs I am not familiar with Linux innards.  I have used Linux for over a decade though; and poked around a little (enough to know not to brag).  I downloaded the camera compiling setup; and realized I had a long way to go to understand how to fix (or understand) things like the camera jpeg settings.

The ability to download and execute scripts independent of the overarching software architecture would be nice.   Or maybe exposing ssh to a terminal user.
Of course to be usefull that would require some handles being exposed to the scripting; Bash or whatever.  If this is not doable natively than I guess some host process using M4 (which as far as I can see only works for linux  ) or some such would be required.  i.e. a macro language to hide the gory details.


Actually I think it would be better to run Lua in the embedded system; but it's probably much to late for that.  I have seen it used; although the implementers were novices the result worked very well.  It is a full fledged language requiring a minimum of supporting infrastructure.  http://www.lua.org .


Things that I have suspicions about and, if not at maximum, I would like to see them setable.
I have doubts about the jpeg resolution during the get process.
I think the motion detection downloads are not at the maximum camera rate.

Thank you for your time.

Ray

I should release a few of the binaries and kernel's I've been working on, but some of the older stuff is under NDA.
I have been doing newer bits and pieces, so probably will add a firmware Monday or Tuesday with nfs, ssh, and ftp so people can play.

I'm probably going to use mathopd for a replacement webserver, I posted a few lines on that in a recent post.
Video stuff is anything thats v4l compatible.

There is a nice writeup on using v4l in the files section here http://www.openipcam.com/files/uCLinux/video4linux%20programming-Alan%20Cox.pdf  if you want to look.


There is a premade arm version of lua available here -  http://www.tortek.co.nz/downloads.html
I can compile it and see how it runs on our device (file size is an concern for us though, as we only have 2M flash on the smaller devices.)

Suggest bug me later on in the week to see progress.

For motion detection;  this might be an issue. The sonix chipset does support motion detection, but I don't have any datasheets on how to talk to the camera SoC. I don't feel like paging through the asm source for the camera app either to reverse engineer it.  We can do this in software, but it might be a little much for the arm7 to cope with.  I could be wrong though

Lawrence.

http://motion.sourceforge.net/ does motion detection and servers the data via its own built in microwebserver. I tried the ubuntu package on my desktop and worked quite nicely. Maybe slightly overkill for our needs, but it does work.

They have also developed a v4l relay device, kinda like linux's tee command I suppose: http://www.lavrsen.dk/foswiki/bin/view/Motion/VideoFourLinuxLoopbackDevice which can be a powerful combination with motion or whatever.

Think ipcam does motion detection, sends of an e-mail/ftp-dump/http-request/tcp-request on motion. Whilst monitoring, using the relay pipe, a user and for example zone-minder, can capture whatever the camera detected, whilst still detecting.

Just a thought. I do also realize this is all a lot to add to a 2M flash device. Just thinking out loud.

We actually only have 700kb really, as the kernel is 1.3M odd.
Motion is v4l2, not v4l so forget that as an option.

I'd suggest offsite motion detection if you really need.
We can stream using servfox / spcaview which will fit too.
We can also mount nfs, so can put files on netshare.

I'm trying to troubleshoot some socket issues at the moment, once i have that sorted i'll release some files.
Its either socket issues or genromfs isn't working right for my build.  Should have it sorted soonish though.
Build sizes for random things i'm using currently looks like this:

Code: [Select]

-rwxr-xr-x  1 root root 146K Feb  8 01:15 busybox
-rwxr-xr-x  1 root root 118K Feb  7 23:36 camera
-rwxr--r--  1 root root  14K Feb  7 23:52 chgrp
-rwxr--r--  1 root root  13K Feb  8 00:38 chmod
-rwxr-xr-x  1 root root  40K Feb  7 23:32 dhcpc
-rwxr-xr-x  1 root root  43K Feb  8 01:28 dhcpcd
-rwxr-xr-x  1 root root  58K Feb  7 22:54 ftpd
lrwxrwxrwx  1 root root    7 Feb  8 01:33 hostname -> busybox
-rwxr-xr-x  1 root root  22K Feb  7 23:32 ifconfig
-rwxr-xr-x  1 root root  18K Feb  7 22:42 inetd
-rwxr-xr-x  1 root root  548 Feb  8 08:46 init
-rwxr-xr-x  1 root root  20K Feb  8 08:48 init.bin
-rwxr-xr-x  1 root root  38K Feb  7 23:32 iwconfig
-rwxr-xr-x  1 root root  33K Feb  7 23:32 iwpriv
-rwxr--r--  1 root root 8.5K Feb  7 23:52 mkdir
-rwxr-xr-x  1 root root  29K Feb  7 23:32 route
-rwxr-xr-x  1 root root  31K Feb  8 00:03 sh
-rwxr--r--  1 root root  89K Feb  8 02:33 strace
-rwxr-xr-x  1 root root  24K Feb  7 23:52 telnetd
-rwxr-xr-x  1 root root  14K Feb  7 22:42 v4l_dump
-rwxr-xr-x  1 root root  14K Feb  7 22:42 v4l_probe_palettes
-rwxr-xr-x  1 root root  22K Feb  7 23:36 wetctl
-rwxr-xr-x  1 root root  95K Feb  7 23:32 wpa_supplicant


Hi there,
thanks for what you are doing first of all!

any news about that ssh-nfs-ftp firmware?

what do you think about adding sms-support (using something like skype) on motion detection ?

Cheers.
He

I can see v4l2 being bad, but remember that v4l1 is being discontinued and removed from the 2.6 series. So apps, and more importantly development of v4l1 apps might be marginal etc.

But for now, I see how 2.4 is important due to camera driver and the like compatibility.

Btw, my kernel that I use on my access-point is 'only' 840kb or so, so 2.6 isn't necessarily huge.



In regard to motion compensation, I remember you mentioning the camera might actually do hardware motion detection, but since it's a USB webcam, it would be encapsulated in USB, and thus in the specs of the similar camera's? My gut feeling says that the camera doesn't do hardware motion detection and the 'camera' app did that all in software.
Having motion detection in the camera can be quite usefull, especially for bigger setups with more camera's. A friend of mine is using zoneminder and (though in hd) the PC is having real trouble doing all the motion detection on the 4 camera's they use, so having the motion detection in hardware/camera is a good thing(tm)

Hi Oliver,

While I would also like to migrate to 2.6, that means I also need to migrate the BSP also.
My efforts to date haven't been successful at that.
I'm getting better at figuring out where I'm going wrong, but until I get it running, or someone else does it,we're on 2.4.20

The Camera SoC allegedly does motion detection, although I don't have a data sheet.
Maybe someone can dig one up?

Motion detection isn't that hard to do in software. 
What I would do is something like this:
Take the image, apply some fast processing to reduce color depth, divide the capture into small squares (like a chessboard) 128x128 or 64x64  or 32x32 depending on size of original, then do an average color algorithm for each square.
Store the result, then compare to previous result.  If the differences are > trigger amount, then capture some images.
The CPU doesn't have an FPU so we'd have to make sure that we use integer based math, and ensure it will run fine in 40mips or so.

Hi Oliver,

While I would also like to migrate to 2.6, that means I also need to migrate the BSP also.
My efforts to date haven't been successful at that.
I'm getting better at figuring out where I'm going wrong, but until I get it running, or someone else does it,we're on 2.4.20

The Camera SoC allegedly does motion detection, although I don't have a data sheet.
Maybe someone can dig one up?

Motion detection isn't that hard to do in software. 
What I would do is something like this:
Take the image, apply some fast processing to reduce color depth, divide the capture into small squares (like a chessboard) 128x128 or 64x64  or 32x32 depending on size of original, then do an average color algorithm for each square.
Store the result, then compare to previous result.  If the differences are > trigger amount, then capture some images.
The CPU doesn't have an FPU so we'd have to make sure that we use integer based math, and ensure it will run fine in 40mips or so.

Hey admin! (why not use a nick on the board :p)

I was thinking of examining the differences between the BSP ucLinux 2.4.* sources and the ucLinux sources and see what the differences are. I know they have added some drivers, copied and renamed some etc (and in which they seem to be violating the GPL as well, not sure on that yet though).

So i'll work up some diffs to start with and post them on the forums.

The reason I mentioned motion was, it does the hard motion detecting bits. The ubuntu package has many options enabled, so disabeling those would reduce the binary a lot. Didn't think of the FPU though I admit, though possible, ideally the algorithm would have to be integer math only.
I wonder whether a) motion does this already and b) they'd be willing to adapt their code to be integer only (or at least make it switchable).

Btw the whole point of me nagging about motion, is more about reusing as much existing code as possible, and not invent yet another app to solve the same problem

I'm probably going to use mathopd for a replacement webserver...

Is lighttpd do-able? - http://www.lighttpd.net/