Hello, Updated stuff toward the end of this post
Before I 'try' and put together some code for my first directive/algorithm for my bot (just a simple..? follow me algorithm), I thought I try and put together a flowchart on what exactly I want it to do.
My bot has 2 PIR sensors on the front(left and right sides) as well as 2 PING sensors(also left and right sides).
I would appreciate any suggestions, ideas & corrections.
I just set the min. distance threshold for the front PING sensors at 36".
I'm a bit unsure on where to put the PING sensor decisions, and what to do if the range distance is under what is set. To stay put/standby? or to back up a bit (12"), or until the minimum threshold is achieved.?
You don't actually handle the 'both' case where you test for left/right/both/none. I assume it means that you are pointing the right way and should go into your range check, but the algorithm as described would start turning in an arbitrary direction.
Gut feeling is that the two checks for PIR sensors picking up motion should be the same check i.e. your initial state is the same as the state when you are clear of obstacles and motion.
I assume you mean to turn towards the motion and then try to move to within 36", but the logic as described would not stop turning if you were already within 36".
What do you intend your 'bot to do about motion detection while it is moving forward? It seems to me that it should always steer towards detected motion but what should it do if there is nothing in range and it stops detecting motion?
PeterH:
You don't actually handle the 'both' case where you test for left/right/both/none. I assume it means that you are pointing the right way and should go into your range check, but the algorithm as described would start turning in an arbitrary direction.
Gut feeling is that the two checks for PIR sensors picking up motion should be the same check i.e. your initial state is the same as the state when you are clear of obstacles and motion.
I assume you mean to turn towards the motion and then try to move to within 36", but the logic as described would not stop turning if you were already within 36".
What do you intend your 'bot to do about motion detection while it is moving forward? It seems to me that it should always steer towards detected motion but what should it do if there is nothing in range and it stops detecting motion?
Thanks for the response Peter.
Below I updated my flowchart...hopefully a bit better.
Yeah, shortly after I posted, I noticed the 'both' condition for the motion sensors.
I may have to modify the 'left, right, both & none' condition with the decision 'are both motion sensors picking up motion?'
On the turning part, I wanted the bot to turn (left or right) depending on what sensor picks up motion, to turn until both motion sensors are picking up motion. Then stop turning & proceed.
On the PING min. threshold, my intention was to check and see if the min. threshold was greater or equal to (36") to proceed (with both motion sensors active).
And also stay at that threshold while following or when the person/motion stops.
When there's no motion, atm, just stop. But later possibly search for motion by turning one way 360deg. or traveling in a 'X' distance radius...
But for now, I think just stop when there's no motion on either left ot right PIR sensors...unless maybe one sensor picks up motion,
then go through the routine to find where both motion sensors are active or pick up motion.
What do you intend to happen in the case where you detect motion, turn towards it and start moving forwards, and do not detect any further motion? Are you going to stop (and try to reacquire somehow) or keep going forwards blindly in the hope you will run into something eventually?
PeterH:
What do you intend to happen in the case where you detect motion, turn towards it and start moving forwards, and do not detect any further motion? Are you going to stop (and try to reacquire somehow) or keep going forwards blindly in the hope you will run into something eventually?
Hey Peter,
I was hoping, from the flowchart, that if no more motion was detected it would stop and stay put in the 'Detect motion?' loop until there is motion detected (you can see where the 'move foward' condition loops back up to 'Detect motion?' decision).
Having it go foward blindly in the hope it will run into something, is part of another algorithm I had planned at a later time: 'Search & Destroy'.....hehe
...just kidding
In all seriousness, definitely did not intend to have it go fowards blindly until hitting something. I hope that's not what the flowchart is doing?
@WillR,
Thanks for the information Will
I'll check out the link and info you posted.
thomas3120:
I was hoping, from the flowchart, that if no more motion was detected it would stop and stay put in the 'Detect motion?' loop until there is motion detected (you can see where the 'move foward' condition loops back up to 'Detect motion?'
I suggest you find out how your motion sensors behave. My experience of PIR sensors is that they're highly sensitive to being moved and need to be stationary (and have time to settle) before they will detect motion. Also that they are motion sensors not presence sensors, so if you intend the bot to detect you and follow you, I suspect you'll need to keep waving at it to maintain its interest.
(You can describe this type of behaviour in many ways including FSM and flow charts - to me a FSM seems like a more natural way to express this type of behaviour because I anticipate that your design will have several modes of operation depending what the sensors tell it. But you can describe it using a flow chart if you find that easier to understand. The important thing is to be clear in your own mind what behaviour you're trying to achieve.)
PeterH:
I suggest you find out how your motion sensors behave. My experience of PIR sensors is that they're highly sensitive to being moved and need to be stationary (and have time to settle) before they will detect motion. Also that they are motion sensors not presence sensors, so if you intend the bot to detect you and follow you, I suspect you'll need to keep waving at it to maintain its interest.
(You can describe this type of behaviour in many ways including FSM and flow charts - to me a FSM seems like a more natural way to express this type of behaviour because I anticipate that your design will have several modes of operation depending what the sensors tell it. But you can describe it using a flow chart if you find that easier to understand. The important thing is to be clear in your own mind what behaviour you're trying to achieve.)
I agree about the sensitivity, it's a bit high on mine (by Parallax). So far I may try a few options(or a combination):
1st: Adding some tape on the lense and allow only the outer, upper quadrant to detect motion on either side PIRs.
2nd: As someone on the boards suggested, add a small tube, possibly a thin walled PVC tube to 'narrow' the sensing range.
3rd: change out a couple capacitors & resistors on the PIR sensor itself to reduce the sensitivity (saw an Adafruit? tutorial on their PIR sensor)
I think I went to flow charts because of a FORTRAN class I took 12+ years ago, and some mech. engineering classes as well...they had a brief chapter or two on flowcharts.
I realize this is an old thread, but I can't be the only person running into these old threads and perhaps being discouraged that they are old and not commenting, so I'm going to comment anyway.
I just ordered a batch of five of these PIR motion sensors from everybody's favorite online vendor of everything and I'm planning to design a robot to incorporate at least four of them. After reading through several different threads, watching videos and reading things on other DIY sort of sites, I've realized people are having some of the same problems with these sensors when it comes to putting them on a moving platform. It seems to be that the trouble is that the sensors will pick up movement when the robot itself is moving. I don't know that I have the solution to that myself, but it seems that the best two ways to try and resolve the issue are to reduce the sensor's field of view a bit and to only worry about weather the sensor is high or low after the robot has stopped and the sensors have been given a moment to settle.
So with that, here's my idea.
Mount four PIR sensors 90 degrees apart on the robot, forward, aft and either side. Then mount them in a short piece of tubing so they're only looking at 45 degrees or less of the room. You're also going to need a servo and an HC-SR04 or comparable ultrasonic rangefinder. I like the HC-SR04 because they're common and inexpensive.
So here's the plan:
The robot is powered on and waits a few moments while the four sensors settle.
Once everything settles, you poll all four PIR sensors for motion.
If a sensor detects motion from the sides or back, rotate the robot so that it is facing in the direction the motion was detected (Roughly) If motion is detected to the front, no need to rotate.
Once facing in the general direction of the motion, Position the HC-SR04 30 degrees to one side and take distance readings every 15 degrees until you have taken your final reading at 30 degrees to the other side. All of these distances can be their own variables so they can be compared to one another.
Once it is determined which sensor detects the shortest distance, rotate the robot a little more so it is facing that direction.
It may be useful at this point to check again for movement, it would also be a good idea to check forward distance to see weather you are within or outside of your maximum distance threshold and back up if needed.
If it is determined that the object is outside of the minimum distance threshold, the robot can move forward
while the robot is moving forward the HC-SR04 can be regularly firing to make sure it's not about to hit something and stop if it reaches minimum threshold.
At this point, you can probably loop back to step 2.
The above obviously will take some trial and error and makes a few assumptions. It's been my experience that unless your robot's wheels are being turned by constant rotation servos or you are using encoders on the axles, you tend to have one motor that turns a little faster than the other, resulting in the robot wandering to one side or the other as it moves forward.
I think it might result in some jerky motion too but this might also be correctable through trial and error.
Last but not least, and I'm sorry if this breaks any hearts. This is decidedly not the best way to design a robot that you want to follow you. The best way it seems is to have the person, or as I like to call them, the robot's master carry a small ultrasonic beacon. Then you put several ultrasonic "ears" on your robot, facing all different directions to it can tell which direction (and distance) the beacon is in. This is actually an idea that has been picked up by a company that is trying to market robots to follow you around the grocery store and carry your groceries, but I'm pretty sure they stole the idea from this guy.. See the link below, pretty good stuff.
