Motion detecting changes long after objects have stopped moving

Question

I am having the same problem with two different computers running Motion 3.2.12. One box is running Gentoo on an Intel Atom and the other is running Gentoo on an Arm based device. I am using two different cameras, a USB frame grabber + composite camera on the Atom, and a Logitech C270H on the Arm device. I do not suspect that this problem is hardware related.

The problem is as follows: When running Motion in setup mode, I can see the "Raw Changes" and the "changes after 'EedDl'" values. When I move my hand in front of the camera, the values increase as expected. When I move my hand away, and out of the frame, the raw changes value sometimes (~70% of the time) drops to a low (but non-zero) value for several seconds before going to zero. The changes after filtering value will usually be very near to the same value as the raw changes. The problem is that often times Motion will stick at about 2000-2500 which is well above my threshold of 500.

The end result is that Motion does not trigger the 'end event' command that I have specified until many seconds after the event has ended. This is not a hardware lag or CPU load issue, as I can place my hand back in front of the camera while Motion is 'hung' at 1500-3000 changes and the value instantly jumps up to reflect the newly detected motion. Unfortunately this behavior is a deal breaker when it comes to the project that I am working on as I need the device to respond within 1-2 seconds after motion has ceased.

What change can be made to the configuration files to remedy this problem?

/etc/motion.conf

daemon on
process_id_file /var/run/motion/motion.pid 

setup_mode off
videodevice /dev/video0
v4l2_palette 6

input 8
norm 0
frequency 0

rotate 0
width 320
height 240
framerate 30
minimum_frame_time 0

netcam_tolerant_check off

auto_brightness off
brightness 0
contrast 0
saturation 0
hue 0

roundrobin_frames 1
roundrobin_skip 1
switchfilter off

threshold 500
threshold_tune off
noise_level 32
noise_tune on
despeckle EedDl

smart_mask_speed 1
lightswitch 0

minimum_motion_frames 2
pre_capture 0
post_capture 0

gap 2
max_mpeg_time 0

output_all off
output_normal off
output_motion off
quality 75
ppm off

ffmpeg_cap_new off
ffmpeg_cap_motion off
ffmpeg_timelapse 0
ffmpeg_timelapse_mode daily
ffmpeg_bps 800000
ffmpeg_variable_bitrate 0
ffmpeg_video_codec mpeg4
ffmpeg_deinterlace on

snapshot_interval 0

locate on

text_right %Y-%m-%d\n%T-%q
text_changes off
text_event %Y%m%d%H%M%S
text_double off



target_dir /var/www/localhost/htdocs/cam1
snapshot_filename %v-%Y%m%d%H%M%S-snapshot
jpeg_filename %v-%Y%m%d%H%M%S-%q
movie_filename %v-%Y%m%d%H%M%S
timelapse_filename %Y%m%d-timelapse

webcam_port 15180
webcam_quality 50
webcam_motion off
webcam_maxrate 1
webcam_localhost off
webcam_limit 0

control_port 8080
control_localhost on
control_html_output on

quiet on
on_event_start /usr/local/bin/goActive.sh
on_event_end /usr/local/bin/goIdle.sh

Environment

Motion version:	3.2.12
ffmpeg version:
Libraries:	ffmpeg, mysql, postgresql
Server OS:	gentoo 2.6.35 armv7l

-- JasonWestervelt - 29 Sep 2011

Answer

I discovered the fix. By making the following change in alg.c, the problem went away.

ACCEPT_STATIC_OBJECT_TIME 0

I understand what is being attempted with this part of the code. Unfortunately, I feel that the object's color, shape, and size during the last motion event should be monitored to see if there is a match within the image. With the current implementation, large movements (or movements of the camera itself) can cause Motion to detect activity for the default length of 10 seconds after the movement has ended and the object is out of view.

While this behavior may not be a problem for most, the project that I am working on requires prompt notification once movement has ceased. For anyone interested, I am utilizing Motion for the purpose of building an autonomous paintball/airsoft sentry gun. While there are tools out there (OpenCV) that are better suited to the task, Motion uses vastly less CPU resources on embedded platforms such as Arm (15% of a 1GHz Cortex A8 vs. 100% with OpenCV doing the same task). The code is well put together and documented well enough that a C noob such as myself can make modifications to suit specific tasks.

I have been using this software for several years now in various applications and I truly respect what the developers have given us.