NewPing Library: HC-SR04, SRF05, SRF06, DYP-ME007, Parallax PING))) - v1.7

I like your choices will read about Crius. I'm going low cost. ESC for $6. Motors for $7 for my first model. Ebay or Amazon free shipping.

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.

sbright33:
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.

The AIO had one hardware issue, which has since been resolved (weak USB connector). Software-wise, it's just using MultiWii, and nothing special as it's all standard hardware with standard connections. To MultiWii, it's just a ATmega 2560 with a 6050 and other sensors attached. Not saying there couldn't be a problem, but those that have it have had success and it's been out for a few months now so there's a lot of them out there. There's been a couple with problems, but problems with vibration and losing a radio connection can be found for every flight controller (as it's the fault of something else, like unbalanced motor or a cheap radio).

It's not Crius' first flight controller either. So, they've had some experience. Finally, nothing they're doing is revolutionary. They just print up a board connecting very common chips together in common ways. Really, all Crius did was make traces between very common and well documented processors/chips. It's only $60, if it was $300 from some unknown I'd reconsider. Heck, a branded Arduino Mega is almost $60 with 0DOF.

Tim

Does this library works with URM37 v3.2 ( URM37_V3.2_Ultrasonic_Sensor__SKU_SEN0001_-DFRobot )

Mode 3: PWM passive control mode
Under 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

Stanley:
Does this library works with URM37 v3.2 ( URM37_V3.2_Ultrasonic_Sensor__SKU_SEN0001_-DFRobot )

Mode 3: PWM passive control mode
Under 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

Reading the documentation, it appears that it will work with the NewPing library. It does appear that you would need to change the US_ROUNDTRIP_CM to 50 and US_ROUNDTRIP_IN to 127 for the distance calculations to be correct.

With that said, if you don't already have the URM37 and there's not a good reason why you need to buy this specific one, I would suggest getting one that's known to work with NewPing. As a bonus, they're also cheaper than the URM37.

Further, if it was me, and I already had this sensor or was required to use it for another purpose, I would use the serial interface instead of the trigger/PWM interface. There's many benefits of using the serial interface, including setting up automated pings, not waiting for ping echos, getting temperature, etc. They've also created a serial library for the sensor so you don't need too much effort to get it working in this way.

If you do get the sensor working with NewPing, let me know. I'd like to hear your experience.

Tim

This may have been answered before in the thread, but I didn't see it on a quick read-through.

I'm using the NewPing library (which is awesome) and the Arduino Motor Shield. Unfortunately the shield uses pins 3 and 11 to do the motor PWM, which conflicts with Timer2 used in NewPing.

Is there a way to change what timer NewPing uses? Or, is it just simpler to un-stack the shield and the Arduino and manually wire the PWM into different pins?

crispy:
This may have been answered before in the thread, but I didn't see it on a quick read-through.

I'm using the NewPing library (which is awesome) and the Arduino Motor Shield. Unfortunately the shield uses pins 3 and 11 to do the motor PWM, which conflicts with Timer2 used in NewPing.

Is there a way to change what timer NewPing uses? Or, is it just simpler to un-stack the shield and the Arduino and manually wire the PWM into different pins?

First off, NewPing does not use Timer2 for the standard ping() and ping_median() methods. It's only for the timer interrupt ping_timer() method where NewPing uses Timer2 on the Arduino Uno. Also, the library uses Timer4 for the Teensy and Leonardo (ATmega32U4). So, if you're just using ping() or ping_median(), you have no conflict with Timer2 (or Timer4 on the ATmega32U4).

However, if you're using the timer interrupt ping_timer() method, yes, it will use Timer2 and there isn't an option to use Timer1. I had first written it to work with both Timer1 and Timer2 but decided to only implement Timer2 because the servo library uses Timer1, which is a common library. However with motors, there's many different ways of doing it, most of which don't use any timers (I use serial motor controllers for example).

Also, because Timer2 is 8 bit and Timer1 is 16 bit, it's not as simple as changing all the 2's to 1's to make it work. It wouldn't be too difficult for someone to modify the code to allow a switch for Timer2 or Timer1. But, they would need a good deal of knowledge on how the timer interrupts work on the ATmega at a lower level. I don't feel it's worth doing as I would think most people writing event-driven code that requires using the ping_timer() method also wouldn't be using the motor shield and instead using an outboard motor controller with better PWM control. But, maybe I'm mistaken. In any case, I'm probably not the one to add this support, someone else will if they feel it's required for their situation.

Tim

Tim,

Thanks for your very thorough response. The sketch I'm developing does use the interrupt_ping_timer() method, since the sketch needs to "multitask". It sounds like changing the timer that NewPing uses is a non-starter, since I will also need to drive a servo (in addition to 2 motors).

It sounds like the best option for me is to unstack the shield and change which pins are used for PWM.

crispy:
Tim,

Thanks for your very thorough response. The sketch I'm developing does use the interrupt_ping_timer() method, since the sketch needs to "multitask". It sounds like changing the timer that NewPing uses is a non-starter, since I will also need to drive a servo (in addition to 2 motors).

It sounds like the best option for me is to unstack the shield and change which pins are used for PWM.

The ATmega328 has limited timers (3, but Timer0 is used for millis and delay so you really only have 2 available). When doing a project where motors and servos are involved, you're really cutting it close when using an ATmega328. You can still do it, using a serial motor controller or I2C motor controller (which are cheap, small, use fewer pins and allow for control of many motors using multiple controllers). Or, you can use a Teensy/Leonardo (ATmega32u4) or ATmega2560 based microcontroller systems that have additional timers/PWM pins.

Tim

teckel:
The ATmega328 has limited timers (3, but Timer0 is used for millis and delay so you really only have 2 available). When doing a project where motors and servos are involved, you're really cutting it close when using an ATmega328. You can still do it, using a serial motor controller or I2C motor controller (which are cheap, small, use fewer pins and allow for control of many motors using multiple controllers). Or, you can use a Teensy/Leonardo (ATmega32u4) or ATmega2560 based microcontroller systems that have additional timers/PWM pins.

I looked into the motor controllers you linked, and frankly serial communication is something I'd rather avoid if possible on this project. I'm trying to keep the scope somewhat limited so I actually have a chance of getting the whole thing to work.

I've looked at my pinout list and I show 2 pins (5 and 6) will still have PWM available even if I use both the Servo and NewPing libraries. I will also have enough pins free to drive a conventional motor shield. So this is the route I would prefer to go. However, I haven't found much in the way of discussion about using the "official" motor shield un-stacked from the Arduino.

crispy:

teckel:
The ATmega328 has limited timers (3, but Timer0 is used for millis and delay so you really only have 2 available). When doing a project where motors and servos are involved, you're really cutting it close when using an ATmega328. You can still do it, using a serial motor controller or I2C motor controller (which are cheap, small, use fewer pins and allow for control of many motors using multiple controllers). Or, you can use a Teensy/Leonardo (ATmega32u4) or ATmega2560 based microcontroller systems that have additional timers/PWM pins.

I looked into the motor controllers you linked, and frankly serial communication is something I'd rather avoid if possible on this project. I'm trying to keep the scope somewhat limited so I actually have a chance of getting the whole thing to work.

I've looked at my pinout list and I show 2 pins (5 and 6) will still have PWM available even if I use both the Servo and NewPing libraries. I will also have enough pins free to drive a conventional motor shield. So this is the route I would prefer to go. However, I haven't found much in the way of discussion about using the "official" motor shield un-stacked from the Arduino.

The serial and I2C suggestions also solves the problem with needing more than 2 motors (you can daisy chain many of these controllers for control of many motors using only 2 Arduino pins in total). When you want to control 4 motors as well as doing anything else, it's a real challenge with the limited pins of the ATmega328. There's other advantages also, like ultrasonic PWM to avoid motor hum and whine.

If you only want motor control and want to use the Arduino PWM pins to control speed, you can use the TB6612FNG Dual Motor Driver Carrier which uses the same TB6612FNG MOSFET-based H-bridge as the serial controller but without serial control (you control it directly with Arduino pins). The TB6612FNG is a better H-bridge than the L298N used in the Arduino motor shield (it's also very cheap). While the Arduino motor shield says it can take 2A, the L298N really can't deal with that well and gets very hot. The TB6612FNG is rated for 1A with 3A max, but it can actually handle two motors going at 1A each at the same time as well as 3A spikes without causing a fire like the L298N will try to do. If your motors are even close to a 1A rating, the TB6612FNG would be a better option than the L298N.

Or, you can hack up your motor shield to use pins 5 and 6. I'd probably cut traces and wire new jumpers to keep the shield basically as-is.

Tim

I agree that the official motor driver is not the most ideal for my application. I already have one on-hand though, so I have an incentive to try to get it to work before buying additional components. The motors I'm using are low-current low voltage motors that come with the Tamiya double gearbox so the current limit should not be an issue.

I like the look of the pololu driver you linked, I will keep it in mind if the shield does not work out.

Thanks again for your help.

crispy:
I agree that the official motor driver is not the most ideal for my application. I already have one on-hand though, so I have an incentive to try to get it to work before buying additional components. The motors I'm using are low-current low voltage motors that come with the Tamiya double gearbox so the current limit should not be an issue.

I like the look of the pololu driver you linked, I will keep it in mind if the shield does not work out.

Thanks again for your help.

Actually, those low voltage motors are typically worse. Higher quality, higher voltage motors will typically be easier on an H-bridge and keep things cooler. Just keep your fingers and flammable material away from the L298N :wink: And if you do decide to get another motor controller, consider the serial interface version. It's far easier to connect and use, control using just two wires no matter how many motors you have, and simple library commands. I have a half-written updated library for it that simplifies things even more.

Tim

teckel:
Reading the documentation, it appears that it will work with the NewPing library. It does appear that you would need to change the US_ROUNDTRIP_CM to 50 and US_ROUNDTRIP_IN to 127 for the distance calculations to be correct.

With that said, if you don't already have the URM37 and there's not a good reason why you need to buy this specific one, I would suggest getting one that's known to work with NewPing. As a bonus, they're also cheaper than the URM37.

Further, if it was me, and I already had this sensor or was required to use it for another purpose, I would use the serial interface instead of the trigger/PWM interface. There's many benefits of using the serial interface, including setting up automated pings, not waiting for ping echos, getting temperature, etc. They've also created a serial library for the sensor so you don't need too much effort to get it working in this way.

If you do get the sensor working with NewPing, let me know. I'd like to hear your experience.

Tim

Thanks for the reply...

I could not get it to work with the NewPing libraries after making the changes to the header file... :~

Instead I use the serial library for the URM37 but still have some issues on using two sensors at once....

I'm using this as a people counter sensor to be mounted at the ceiling of retail store...

Stanley:

teckel:
Reading the documentation, it appears that it will work with the NewPing library. It does appear that you would need to change the US_ROUNDTRIP_CM to 50 and US_ROUNDTRIP_IN to 127 for the distance calculations to be correct.

With that said, if you don't already have the URM37 and there's not a good reason why you need to buy this specific one, I would suggest getting one that's known to work with NewPing. As a bonus, they're also cheaper than the URM37.

Further, if it was me, and I already had this sensor or was required to use it for another purpose, I would use the serial interface instead of the trigger/PWM interface. There's many benefits of using the serial interface, including setting up automated pings, not waiting for ping echos, getting temperature, etc. They've also created a serial library for the sensor so you don't need too much effort to get it working in this way.

If you do get the sensor working with NewPing, let me know. I'd like to hear your experience.

Tim

Thanks for the reply...

I could not get it to work with the NewPing libraries after making the changes to the header file... :~

Instead I use the serial library for the URM37 but still have some issues on using two sensors at once....

I'm using this as a people counter sensor to be mounted at the ceiling of retail store...

Did you wire it to use PWM passive control mode instead of the serial? Also, it's possible it needs a longer MAX_SENSOR_DELAY or trigger length. Anyway, if you can't get it to work correctly with 2 sensors using the serial method, you could send it to me and I'll try to get the PWM mode working with NewPing and then send you the sensor back. It seems as though with a little tweaking it would work. And if so, when you got the sensor back you could implement both sensors. I'd like to add support for this sensor so it's worth my time to try to get it working for you.

Let me know.

Tim

teckel:
Did you wire it to use PWM passive control mode instead of the serial? Also, it's possible it needs a longer MAX_SENSOR_DELAY or trigger length. Anyway, if you can't get it to work correctly with 2 sensors using the serial method, you could send it to me and I'll try to get the PWM mode working with NewPing and then send you the sensor back. It seems as though with a little tweaking it would work. And if so, when you got the sensor back you could implement both sensors. I'd like to add support for this sensor so it's worth my time to try to get it working for you.

Tim

Tim,

I double check and wire the pins are correctly... now pin 4 = PWM, pin 5 = trigger

I tried the NewPing library again and this time I put it on a oscilloscope to "see" what's going on....

The URM37/echo pin seems to be working correctly as the pulse width decreases when range is near and pulse width increases when range is far away...

The serial monitor is still showing 0cm ....

I measured the width from the scope and here is what I got :-

1cm = 0.5ms ( 500us )
20cm = 1ms
30cm = 1.5ms
40cm = 2ms
100cm = 5.16ms
185cm = 8.00ms ( my ceiling height )

The period is 68ms for every distance measurement....

The codes is as per the NewPingExample and I only made changes to the defines below

#define US_ROUNDTRIP_CM 50
#define US_ROUNDTRIP_IN 127
#define TRIGGER_PIN 5
#define ECHO_PIN 4
#define MAX_DISTANCE 500

Please suggest what else should I try...

Stanley:

teckel:
Did you wire it to use PWM passive control mode instead of the serial? Also, it's possible it needs a longer MAX_SENSOR_DELAY or trigger length. Anyway, if you can't get it to work correctly with 2 sensors using the serial method, you could send it to me and I'll try to get the PWM mode working with NewPing and then send you the sensor back. It seems as though with a little tweaking it would work. And if so, when you got the sensor back you could implement both sensors. I'd like to add support for this sensor so it's worth my time to try to get it working for you.

Tim

Tim,

I double check and wire the pins are correctly... now pin 4 = PWM, pin 5 = trigger

I tried the NewPing library again and this time I put it on a oscilloscope to "see" what's going on....

The URM37/echo pin seems to be working correctly as the pulse width decreases when range is near and pulse width increases when range is far away...

The serial monitor is still showing 0cm ....

I measured the width from the scope and here is what I got :-

1cm = 0.5ms ( 500us )
20cm = 1ms
30cm = 1.5ms
40cm = 2ms
100cm = 5.16ms
185cm = 8.00ms ( my ceiling height )

The period is 68ms for every distance measurement....

The codes is as per the NewPingExample and I only made changes to the defines below

#define US_ROUNDTRIP_CM 50
#define US_ROUNDTRIP_IN 127
#define TRIGGER_PIN 5
#define ECHO_PIN 4
#define MAX_DISTANCE 500

Please suggest what else should I try...

It appears the ping trigger process is working if you're getting activity on the echo pin. Does it look like a nice square wave? Is the pulse width measured high, low, or are both the same? NewPing waits up to MAX_SENSOR_DELAY for the echo pin to go high and then measures the time it's high. If the distance measurement is on the low state instead of high, it would obviously be wrong. Also, if you modify the sketch to trigger just one ping, how long will the echo pin give the PWM distance?

I'd try set the MAX_SENSOR_DELAY to a very large number, maybe a million. Also, set the ping rate to be very slow, like once every 5 seconds.

Tim

teckel:
It appears the ping trigger process is working if you're getting activity on the echo pin. Does it look like a nice square wave? Is the pulse width measured high, low, or are both the same? NewPing waits up to MAX_SENSOR_DELAY for the echo pin to go high and then measures the time it's high. If the distance measurement is on the low state instead of high, it would obviously be wrong. Also, if you modify the sketch to trigger just one ping, how long will the echo pin give the PWM distance?

I'd try set the MAX_SENSOR_DELAY to a very large number, maybe a million. Also, set the ping rate to be very slow, like once every 5 seconds.

Tim

Yes nice square wave as per the snapshot I sent to your e-mail..

From the scope, the URM37 PWM pin is ALWAYS HIGH (5V) and when it is activated, it goes low instead... that is where I got my above measurements....

Codes from the URM37 using PWM passive mode :-

unsigned long DistanceMeasured=pulseIn(URPWM,LOW);

Mode 3: PWM passive control mode
Under 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.

Dear Tim,

Are you able to add the option to have the distance measurement/pulse width based on LOW signal instead of HIGH signal ? With this, the URM37 passive PWM mode should work with the NewPing library...

Thanks

Stanley:

teckel:
It appears the ping trigger process is working if you're getting activity on the echo pin. Does it look like a nice square wave? Is the pulse width measured high, low, or are both the same? NewPing waits up to MAX_SENSOR_DELAY for the echo pin to go high and then measures the time it's high. If the distance measurement is on the low state instead of high, it would obviously be wrong. Also, if you modify the sketch to trigger just one ping, how long will the echo pin give the PWM distance?

I'd try set the MAX_SENSOR_DELAY to a very large number, maybe a million. Also, set the ping rate to be very slow, like once every 5 seconds.

Tim

Yes nice square wave as per the snapshot I sent to your e-mail..

From the scope, the URM37 PWM pin is ALWAYS HIGH (5V) and when it is activated, it goes low instead... that is where I got my above measurements....

Codes from the URM37 using PWM passive mode :-

unsigned long DistanceMeasured=pulseIn(URPWM,LOW);

Mode 3: PWM passive control mode
Under 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.

If it only goes low once that would be the problem, as NewPing is looking for a high signal, not a low signal. I had figured it would put out a constant PWM with the same duration of high as low, as it says it puts out pulses, not pulse. I'd really need to see the rise and fall timings to see if there's a way of doing this without switching it to sensing a low signal rather than a high signal. Also, the number of pulses it outputs (or is it just a single pulse).

Tim