Interesting discussion Tim. I disagree about timestamps. Here's how to synchronize 2 Uno's to 2us.As you can see they stay in sync even without GPS once initialized.http://arduino.cc/forum/index.php/topic,120288.0.html
Let me simplify and round to make it easier to discuss. We will use your method of only 1 unit. First send out a single ping and wait up to 100ms. Each 1ms is about 1ft, 2ms round trip. Measure the integer number of msecs rounding down. Let's assume the result is near the middle between 20-21 about 20.5. We don't need to be more exact than that. Now send out 100 pings exactly 1ms apart. Measure the return values mod 1000us. This gives us the part to the right of the decimal. We already know 20ms. Average them. We might get 522us. So the answer is 20.52ms. The last 2 is not significant. Convert to feet. You can see we don't need to identify which ping is which. It doesn't matter since they're all sent at x.000 secs. This could be relative to nothing, or GPS time. But we could figure it out since we know the object is about 20.x ms away. When a ping comes 20.51ms later we know it was sent 20+us ago, not 19 or 21.This would not work if the object were exactly 20.01ms away, because we would hear the ping being sent each 1ms. It would be much louder and block us from hearing the echo. But it would work with 2 devices using an accurate clock! Or you could just change the interval to 1.12ms instead of 1.0ms if your echo was being blocked. More complicated math.The advantage of my idea is that you get 100's of pings per second to average, even if the target is far away. This will let you calculate an accurate distance much quicker than waiting 100ms between sending, if you want an answer in 0.3 secs.If you like my idea you an have it!
I've got a working demo pinging every 1ms using 2 simple transducers. The object is 10ft away.To summarize: First you need to know how many integer feet away it is.Sounds like I cannot use the same hardware you have with 2 units, sender and receiver.My goal is to double my distance, as you said.With a Quadcopter, this S/R method allows me to put the receiver on the ground away from the noisy motors and blades.Again doubling the distance, that's >x4 compared to using a single sensor in the air.
You have to first send a long ping to get the integer part. Then the next pings come 1ms later, so it can't have moved very far. If it does move slowly you can track it's location with only 1ms pings. You don't have to wait for the long ping to return to begin sending more, unless you are concerned about missing the first one and not knowing it.There are 2 new independent ideas here. One of them is sending pings closer together like 1ms. The other is using a separate sender/receiver, with one of them attached to the object. You can choose one or both methods.Yes it would only help for landing at a particular spot. This is better than nothing because it doesn't work otherwise past 3ft.
Your library is suitable if you want slow updates close to the ground before landing. Sometimes that is all we need for a Quadcopter.I have been flying for months. I recommend beginning with a KK board. It has gyros, it's simple, and it just works the first time. KKv2.0 has accelerometers too, to keep it level. It's hard enough to fly even with this, impossible without it the first time.The next step is a pressure sensor to keep it steady at a particular altitude for example 10m above ground.Then a compass to keep it pointed north, now it's easy to control the x,y position manually with only 1 stick on transmitter!I've found a 2D compass works if you have a KK2.0 board first.If you're still having fun add GPS. Hobbyking has a frame and 4 motors for $30. Let me know if you have any question!Steve
I agree, Crius seems like the best choice. It's new and complicated inside. But not many people have tested it in the real world. The code is new too. A small bug might cause a crash if you're not an experienced Quad pilot.
Does this library works with URM37 v3.2 ( http://www.dfrobot.com/wiki/index.php?title=URM37_V3.2_Ultrasonic_Sensor_(SKU:SEN0001) )Mode 3: PWM passive control modeUnder this mode, a low pull on pin COMP/TRIG will trigger a sensor reading. The width of the pulse is proportional to the servo rotating degree. After a successful sensor reading, Pin PWM will output pulses, every 50us represents 1cm. If the reading is invalid, a 50000us pulse will be returned.Can I use the NewPing library and change the NewPing.h to make it work for the URM37 v3.2 ?Thanks
Please enter a valid email to subscribe
We need to confirm your email address.
To complete the subscription, please click the link in the
email we just sent you.
Thank you for subscribing!
via Egeo 16