Using a PIR sensor in a robotic head project is awesome... while tracking with MRL, PIR sensor is helping to identify human presence and start tracking... I have tested this and proved to be very useful... but I have some issues now... PIR sensors have retriggering option for detecting human presence and movement and continue keeping the tracking process on... there is always 2 pots on the sensor, one for sensitivity adjustment (detection range) and one is for continuity of open circuit after triggering... I usually use 30sec continuity, this allows to keep the circuit open for enough time... if the movement continues, retriggering option keeps the tracking open until movement stops or human leaves the room... this works ok for Arduino scripted tracking but when I use MRL opencv tracking service, the tracking stops in few seconds after PIR is triggered... Indeed tracking must keep on as long as the human movement is present because PIR has retriggering... but MRL doesnt check that and service stops soon... It takes some time to realize that sensor is triggered again... in the oscope image I was testing PIR triggered tracking with Greg and I was dancing in front of the sensor all the time, but as you can see service interrupts frequently... I think this is a software issue...
Thanks for the excellent post
Thanks for the excellent post borsaci.
I have more questions :
PIR sensor retriggering issues...
-- I am using the py script which you have prepared the basis for PIR tracking for me... here is it:
tracking.PIRTriggered.borsaci06.py
So the problem is the pin
So the problem is the pin appears (at least through MRL) to flip values more than it should? If I understand you correctly, your POT value should inhibit the ability for the pin to change values for over a period of 30 seconds - So you think its a software problem where MRL is making up changed states on that pin?
We could fix this in the Python software just by setting up a timer which does not allow states to change (tracking / not tracking) until at least 30 seconds from the previous state has transpired.
But as a wise sage said to me, "You should always solve your problems up-stream!" .. meaning this would be just masking the root problem.
The root problem is the pin is changing states many more times than it should in 30s.. This "seems" like a hardware problem to me, no ?
retriggering...
I completely understand what you mean and agree with you... restricting the state change with a timer in py script will not solve the problem but will keep tracking on for at least 30secs... I dont agree with you about this being a hardware issue because when I test the PIR with std arduino sketch, the state led never goes out when there is movement within the sensor detection range... however when using with MRL tracking, the state led doesnt even lit... but as we can see on the oscope the state changes are there... we should more elaborate on this issue...
can you copy paste the
can you copy paste the Arduino sketch into a comment, I'd like to see it.
Arduino sketch for PIR sensor...
sure here it is...from Arduino playground site... PIRsense.ino
AH HA ! Your sketch is just
AH HA !
Your sketch is just hiding the hardware problem !
When it switches high .. it looks like it tries to play a tone for 300*100 milliseconds ! This would keep it in a high state (since its single threaded) for that length of time !
So when you say you turned some pot on the hardware for 30 second delay - this apparently is not working. Now your saying MRL has a "bug" because its not behaving like the sketch ? hmmmm..
I would not consider this a bug in MRL, its behaving as I would expect given the hardware's behavior. So if your interested in having MRL change its behavior, lets call it an "enhancement" :)
retriggering problem...
Grog,
I never complained about a "bug" in MRL... :) I just posted a problem about PIR retriggering not handled properly by MRL... Thought that this can be solved within MRL and as a Guru, by you... I just asked your help about the issue... :) to be of a little bit more help, I didnt say that "when tested by Arduino sketch the PIR sensor stays on for 30secs", the state led on the sensor stays lit as long as movement continues... I know that there is a "buzzer" in the sketch which I didnt use,( will test deleting that parts of the code), whether the buzzer works or not, the state led on the sensor stays on as long as the movement continues, sometimes longer than 30secs if I am in the vicinity of the sensor... but when I use MRL PIR affected tracking, the case is not like that... the led on the sensor doesnt even lit... I am sure you will find an "enhancement" about the issue...
Ok, I just needed to get more
Ok,
I just needed to get more understanding of what is going on. Usually, I have higher priority on fixing "bugs". Bugs are defects, enhancements are ways we want it to behave. Not really a big deal and the distinction between the two is subjective. The part I was concerned about is MRL "making up" values the hardware was not sending - this would definately be a bug .. but that's not happening .. so Onward !
I believe I understand most of the details, now lets jump back and get the big picture :D
How do you want it to optimally behave ? I'm pretty sure I could get it to do what you want if you could very clearly describe what you want. For example, turning on the LED would be easy - and you want it on continuously for 30 seconds after the last movement is sensed?
retriggering problem...
I just want the tracking to continue as long as a human is inside sensor's detection range.. whether 10secs or few mins... the state led is not a problem too, because it is inside the head enclosure and we dont see it lit... but it is an indication of sensor output... :)
I am sure you will find a solution inside MRL to this problem... Gael and I will be so happy if this is solved... and I am sure you will also want PIR triggered tracking when your InMoov is finished and start tracking...
Problems will always be a part of robotics... and challenge us.... :)
retriggering problem...
Grog,
I tried to test the Arduino sketch for PIRsense without the buzzer parts and realized that it was not the actual sketch I first tested the sensor... It was this sketch: