Author Topic: Here we go - Pluto started but quite some of features dead  (Read 15804 times)

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Here we go - Pluto started but quite some of features dead
« Reply #15 on: March 25, 2005, 06:45:55 pm »
That looks like a great project.  I just forwarded the link to the Dan H., who is our in-house guy for video surveillance, and who wrote the interface to Motion.

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Here we go - Pluto started but quite some of features dead
« Reply #16 on: March 25, 2005, 09:12:38 pm »
Quote from: "aaron.b"
That looks like a great project.  I just forwarded the link to the Dan H., who is our in-house guy for video surveillance, and who wrote the interface to Motion.


Hi,

I'l add my 2 cents. I'm using motion for quite some time. It just sits there doing its job - no complains, no huge cpu resources, no crashes. Detection engine is improving all the time. But it lacks decent web interface to look at recordings, settings, etc....

Then I saw Zoneminder and it attracted my attention. I've tried to use it for few months, but more and more basic drawbacks came at me. Ok, web interface is great, but detection engine was at that time IMHO much worse. Try to point camera outside and you'll see... Also motion works with video loopback devices (that means that you can connect another app to output of motion - you can get PIP with TV and video from motion camera on mythtv)...

It surely looks like more mature system, but GUI interface is not what is needed in Pluto. I guess we need realiable, good detection engine, everything else is handled by Pluto.

Of course I could be waaaaay wrong. But the current motion support is missing only few minor changes (that I proposed in other threads) and Pluto will have decent security support. Of course I wouldn't mind using Zoneminder, but I guess that will mean a new start... Could be great alternative, though.

I think that maybe there are some more hot areas to put efforts in them (telephony-asterisk (maybe integrating AMP), mythtv, daily news, RSS, family calendar with some light family-groupware (www.egroupware.com), motion videos, multizone audio, using media director as computing environment - KDE desktop, as document writting machine,  etc...).

I think that the best for Pluto will be to integrate best OSS partial solutions into one great product.

Regarding web camera support: for USB cameras zoneminder and motion support same cameras, maybe at the time, zoneminder is ahead on IP cameras, but intense development is going on in motion (snapshots are out every few days). But the main measure of quality is IMHO number of false triggers, reliability, robustness to wind, object reflections, light turning on/off, etc.....

I'd like to try to contribute proposed changes to motion interface, but I'm still stuck on problem, that despite definition of 4 child cameras I don't get threads properly activated and started with motion - so I could do further steps... I've submitted bug report 2 days ago...

Just my opinions,

regards,

Rob.

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Here we go - Pluto started but quite some of features dead
« Reply #17 on: March 25, 2005, 10:06:43 pm »
Sorry about the lack of response to your bug report.  Do you have a link to it?  Or the bug id?  I did a search but didn't see it.  I'll be sure it gets assigned to the right person.

You said "despite definition of 4 child cameras I don't get threads properly activated and started with motion".  I assume that means the problem is something particular to motion (which I know nothing about).  So it should go to Dan H.  You can also email him directly at "dan.h" to remind him.  He'll be in the office on Monday.

If the problem you're having is related to the framework or DCE (ie DCEGen, the internal creation of the classes, DCE messages, etc.) then I can help you.  I'll be at my computer this weekend too, and we can troubleshoot with instant messenger or a phone call.  Just let me know. (my email is aaron.b)

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Here we go - Pluto started but quite some of features dead
« Reply #18 on: March 25, 2005, 11:37:52 pm »
Quote from: "aaron.b"

Sorry about the lack of response to your bug report.  Do you have a link to it?  Or the bug id?  I did a search but didn't see it.  I'll be sure it gets assigned to the right person.

No worries, :-) .

ID 745:

http://plutohome.com/support/mantis/view.php?id=745

Quote from: "aaron.b"

You said "despite definition of 4 child cameras I don't get threads properly activated and started with motion".  I assume that means the problem is something particular to motion (which I know nothing about).  So it should go to Dan H.  You can also email him directly at "dan.h" to remind him.  He'll be in the office on Monday.

Well, motion and Pluto work in following manner. motion.conf in /etc/motion includes separate thread pointers for each child camera - those points to separate "threadx.conf" configuration files for each camera. Now generic_analog_capture_card (I already call it "Motion wrapper") writes "num of ports" threads pointers, but comments out all of them. Now when you define and start child camera, it uncomment its thread pointer in motion.conf and writes its own threadx.conf, so motion spawns separate thread for this device.

I already set "num of ports" parameter to 16 (that represents max video surveillance devices) and then add only real existing devices... In this way we can add analog camera on capture card with same template as usb cam and IP cam - only some parameters will differ...

My problem is that child camera devices don't do their work, don't uncomment and don't write their own threads - so only 1 camera is wokring at the time (from default motion.conf).

Do you know how to start those devices by hand ? That would help me a lot, cause I could get further into changes I already proposed in another forum threads about motion support...

Also I guess there is another problem - I've added 4 camera view scenarion, but don't see any picture (I guess I could see 1 working camera ?)
 
Quote from: "aaron.b"

If the problem you're having is related to the framework or DCE (ie DCEGen, the internal creation of the classes, DCE messages, etc.) then I can help you.  I'll be at my computer this weekend too, and we can troubleshoot with instant messenger or a phone call.  Just let me know. (my email is aaron.b)


Yes, I guess more of work will be DCE, DCEGen , parameter, DCE messages related (BTW, did you get anywhere with automatic wrapper generator - "swig" that was proposed in another thread - BTW2 which library should be wrapped ?).

I guess getting DCE messages and devices engines into scripting languages (Perl, Python) could boost contribution from other developers (for sure also Misterhouse community - recently we discussed this and Bruce (MH Master) said he's interested).

I'd really like to get motion into working state, so can proceed to media and Asterisk part...

I'm looking forward to cooperation - will get in touch. For now I need to know how to start those child cameras by hand... So can trace where the problem lies....

Regards,

Rob.

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Here we go - Pluto started but quite some of features dead
« Reply #19 on: March 26, 2005, 10:44:19 am »
I don't know how Dan wrote his code for motion.  I know that he didn't spend much time on it, so we don't have much invested in Motion.  If you can think of a better way, we don't have to stick to the current implementation much.

I can comment, though, on the structure as I see it from DCE's standpoint.  If you look at the Device Template for "Generic Analog Camera", you'll see that Implements DCE is *not* checked.  That means this is a dumb device--dumb in the sense that there is no code that will be run for this device.  Some other device--an intelligent device--will need to be responsible for all the code.  That device will be the 'Controlled Via' device, or the parent device when you look at the tree in Advanced Devices.  A device is responsible for handling all the code for it's children that do not implement DCE.

You see that the Camera has: This device is controlled via category:  Category: Generic Analog Capture Card.  That section of the device template page is where you specify what are the valid choices for the parent (or controlled via).  If you don't specify anything in either of the "This device is controlled via", then when the user creates this device, he can pick any parent/controlled via device he wants.  He could stuck a camera underneath the Xine DVD Player, for example.  If the Camera was an intelligent device that *did* implement DCE, this actually would be okay.  According to the framework, each device just spawns all of it's intelligent children as separate devices.  So, if the camera implemented DCE (meaning had it's own binary executible), you could make the parent anything you wanted.  If it was Xine, Xine would just spawn the program 'Camera' and let it take care of itself.

But since the 'Camera' is not an intelligent device, the parent/Controlled Via must be specified since that device needs to know what to do with it, and if the user put a dumb Camera as a child of Xine, Xine would just ignore it not knowing what it was.

So, the first question is: Is this structure with an intelligent device (the capture card) and dumb children (the cameras) correct?  With the structure the way it is now, that means there is only 1 binary, 1 thread that is going to be spawned--the Capture Card (the intelligent device that implements DCE).  The capture card's child devices (the cameras), as dumb devices, are really nothing more than a 'for your information' for the capture card.  So, when you wrote: "I don't get threads properly activated and started" for the cameras, understand that with this structure the Pluto DCE framework will not spawn any threads or devices for the cameras--Pluto will only spawn 1 thread for the capture card, which must do whatever it needs to do internally to support the cameras.

Going back to the issue of 'is this the right approach', note that it's possible to mix.  You can have some cameras that are intelligent devices, with their own binaries, and others that are not.

We have this same mixture throughout Pluto.  For example, most of the time light switches are dumb devices.  With X10, there's only 1 intelligent device--the CM11A interface--and that's the only thread that's run.  A light switch called "Living Room Light" is actually just a dumb device.  When the user hits the button to run on the Living Room Light, the "ON" command ends up in the CM11A device, which has the code to handle the "ON" command--it just looks up the child device, looks up the house code from it's data, and then sends the X10 command.  But, later, someone may add an intelligent light switch that acts independently, without needing a cm11a interface.  In this case, the light swith would be "intelligent" (ie implement DCE) and would get it's commands itself.  From the users standpoint, there is no difference.  Whether a device implements DCE isn't even shown on any of the wizard pages--it's too technical.  The user just adds light switches and knows that they can turn any switch on.  Where the code resides is unimportant.

So, it sounds like there may be a similar mix for motion, where some cameras are intelligent and some are dumb.  When you're using a single capture board, like the Grandtek BT878-based 16-port analog board we use, it seems to make the most sense that the cameras are dumb.  You don't want to run 16 different programs for each of the cameras--you just want 1 program that runs for the capture board.  When a command is sent to provide a video frame from camera #5, then you want that command to go to the single device for the capture board, and the capture board device will grab a frame from port #5.

However, in the case of USB cameras, perhaps the cameras should be intelligent (implement DCE and have their own device) since there is no 'capture board' device that will handle the logic for them.

Therefore, from a hardware standpoint, the way I would see the devices is as follows (smart devices shown in caps, dumb in lower case).

GRANDTEK BT878 CAPTURE BOARD
  generic analog camera #1
  generic analog camera #2
  generic analog camera #3
USB CAMERA
IP BASED CAMERA

From the user's standpoint (ie the wizard), this arrangement is very clean.  When they add a USB camera or IP Camera, as an intelligent device, the parent/Controlled Via device is just the PC that the software runs on.  But when the user adds a "generic analog camera" device, the wizard pages will automatically require him to first add the capture board, and will make the capture board the parent device.  In the above example, then, 3 separate programs would be run by the framework: the capture board, the USB camera, and the IP Camera.

However, this whole situation does get a little more fuzzy in my mind when Motion enters the picture.  If there were only the GRANDTEK capture board and it's analog cameras, it wouldn't be so difficult.  The Grandtek capture board would be both the wrapper for motion, as well as having the logic for controlling the analog cameras.  However, in the above example, where does motion enter the picture?  In that example, there are 3 intelligent devices, which will therefore all be spawned as 3 completely separate devices.  Should all 3 of them have their own copy of motion, making them completely independent?  That's one possibility.  But what if you want only 1 copy of motion for both the analog cameras, USB cameras, and IP Cameras?  In that case, I can think of two possibilities.  First, leave them as shown, with 3 separate devices.  However, each of the 3 devices (GRANDTEK, USB, IP CAM) will attempt to connect with a Motion back-end, starting it if it's not already started, and each will work with motion.  In that case motion doesn't exist as a separate device, but rather a tool that all 3 devices will use.  The second possibility would be to create a device called Motion that was a wrapper for motion, and then make the 3 devices children of motion (the analog cameras would be grand-children then).

Normally, when we're creating a new, major module, the senior developers get together and brainstorm to be sure we come up with the most logical structure that will grow with us.  At the moment we're all pretty busy with Media, Orbiter, the Installer, and our focus has been on getting 1 piece--the media--to work flawlessly before branching out too much, so we just kind of gave Dan H the task of getting a motion interface going--something basic that would work for our demo.  It hasn't been really thought out, and I haven't even looked at Dan's code before to see what he did.  But, from peeking at it now, it seems this was his intention:

There's only 1 intelligent device which a combination of both a motion wrapper, and an interface for the analog capture board we gave him (the bt878 based Grandtek).  The child devices (the cameras) are dumb devices.  In the constructor, Generic_Analog_Capture_Card::Generic_Analog_Capture_Card, he doesn't appear to actually look at his list of child devices (cameras), which one would normally expect of a device that has dumb children.  The children are in m_pData->m_vectDeviceData_Impl_Children.  Normally I would have expected him to see what kind of children he had and how many there were.  But it appears that the capture card device has a device data parameter, DATA_Get_Number_of_ports(), and so he just creates a generic threadX conf file for each port.  This isn't really complete.  There are likely parameters that should be specific to each camera, such as sensitivity to motion, etc.  So the dumb camera device should have a device data parameter like 'sensity level', and the constructor should iterate through it's children, reading DATA_Get_Sensitivity_Level() for each of the child cameras, and write out the specific settings for each camera.

There's only 1 command involved, "Get Video Frame".  Since the child cameras are dumb devices, any commands to them come in this, the parents, Generic_Analog_Capture_Card::ReceivedCommandForChild function.  Here he find the child device (the camera) that is the target of the command.  // find child device  There's only 1 command: case COMMAND_Get_Video_Frame_CONST:  He gets the port number of the camera: string sPortNumber = pDeviceData->mapParameters_Find(DEVICEDATA_Port_Number_CONST);

So the framework that's there is really simple.  He's got about 65 lines for the constructor, and 50 lines to get a frame, and that's the whole extent.  What he wrote would seem to work okay if there's only 1 capture card in the system, but doesn't really have any means to account for USB cameras, IP Cameras, or be a full-fledged video monitoring solution.  BTW, that's ok--that was Dan's instructions, to throw something together quick for the video surveillance since we had to do a demo.

In terms of a more robust solution, without knowing much about how motion works, my gut feeling would be to use a structure like that shown above, with no specific device for motion, and then let all the devices that need motion to either spawn their own copy of motion, or attach to a shared one.  I remember from series 1 that Motion can require a lot of CPU, particularly with lots of cameras.  So, we were directing customers with lots of cameras away from the analog capture card in favor of IP cameras which had their own motion detection built-in.  Making motion a separate device, and making the user decide what cameras use motion and what don't might be complicated.  So, by taking Motion out of the picture, then in the example above, the DCE Device for the Grandtek capture board may use motion, as may the USB Camera, but the IP Camera may not, if it has its own motion detection built-in.

I'll talk to Dan about it, and since you understand motion (and hopefully after this long discourse more about DCE), let me know your ideas too.

archived

  • Hello, I'm new here
  • Posts: 0
    • View Profile
Here we go - Pluto started but quite some of features dead
« Reply #20 on: March 26, 2005, 11:01:29 am »
Per your comment about manually compiling and starting and debugging the startup:

With the current layout, the only device that will be started automatically is Generic Analog Capture.  The parent/controlled via should be your Core or a Media Director.  In that case, the script "Start Local Devices" in /usr/pluto/bin should try to spawn it automatically, and spawn it in a continuosly looping screen session that will keep restarting it over and over if it dies.  If you want to start it manually, run Generic_Analog_Capture -d [device] -r [router's ip].  If you want to see why it's not starting automatically, look in /var/log/pluto/pluto.log -- everything that StartLocalDevices tries to spawn is logged tehre.

To compile from SVN...  I assume you already have an svn checkout in  your /usr/pluto/sources, right?  If so, run 'make' in the PlutoUtils, and DCE directories, and then run 'make bin' in the Generic_Analog_Capture directory.  You can then run the binary from right there for testing.  Before you do, though, do a "screen -ls" to see what devices are running in screen sessions, and if the same Generic_Analog_Capture is already running in a screen session, do a screen -r [pid] to attach to it, and then a Ctrl+C to kill it.

If you have 2 devices running with the same device id, they will 'fight' and continuously disconnect each other.  For example, if you run GAC twice with 2 different device id's, that's ok.  But twice with the same device ID means that the first one will connect to the router (say as device #1000), and when the second one also connects as device #1000, the router will drop the connection to the first #1000, which will then re-attempt a connection, causing the 2nd one to drop, and so on.