Pages: 1 ... 3 4 [5] 6 7 ... 34   Go Down
Author Topic: NewPing Library: HC-SR04, SRF05, SRF06, DYP-ME007, Parallax PING))) - v1.5  (Read 121383 times)
0 Members and 1 Guest are viewing this topic.
Toledo, OH
Offline Offline
God Member
*****
Karma: 36
Posts: 514
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

The sensor does read HC-SR04 between the transducers, yes.  I'm not sure that I'm getting a proper understanding of versions. A search for updates for my Uno gave me an IDE update from 1.0 to 1.0.1 which has been completed. Is there anything else to update/change? I was not able to find a reference to 0223 that made sense to me. Some references to linux but I'm using win7 platform.

With the demo code, it is still necessary to hit the on-board reset button to get data, but if it's the sensor that's faulty and that's the only shortcoming it is going to display, I can tolerate that for the present.

All the benefits of NewPing and the most beneficial to me is the ease of use. I'll be measuring about four times an hour, so speed isn't critical. A 24 inch range is well within the limitations of this device. The rest of this project is "fluff" and fine tuning and fun.

Is there more to an "update" than what I've described above? Where else to check version information if there is more to it?

thanks

When you were talking about upgrading, I figured you meant upgrading the NewPing library, not Arduino.  Arduino 1.0.1 is the latest, 0023 is the previous release before 1.0.  Some people still use 0023 for older sketches/libraries that don't work on 1.0.  You can run 0023, 1.0, and 1.0.1 on the same machine, so it does provide nice options for legacy code.

You said "I've downloaded the library and run the demo code which works just fine unmodified."  Which sounds like the demo works fine, right?  You suggest that you modified the demo, and then it doesn't work correctly.  Which sounds like the problem is with the changes.  Could you try the unmodified demo code again?  If that works, I would need to know exactly what modifications you made, as they appear to be the problem.

Tim
Logged

Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

0
Offline Offline
Newbie
*
Karma: 0
Posts: 33
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I think I've been confusing in my expressions. The most recent activity was to update/upgrade from 1.0 to 1.0.1 and I've not had 023 ever. When I discovered NewPing, I felt it was an easier library to use and to understand than my limited experience with ultrasonic.h library.

The demo code was uploaded and the serial monitor displays one line of non-zero distance then displays continuing zero distance figures, regardless of real world conditions. I suspect the non-zero distance is an anomaly. If I press the reset button on the Uno, the serial monitor displays non-zero distance figures.

I'm going to load the code later today that uses the ultrasonic.h library to see if the results are the same. I'm suspecting that the device is at fault, as you suggested.
Logged

Greenville, IL
Offline Offline
Edison Member
*
Karma: 15
Posts: 1330
Warning Novice on board! 0 to 1 chance of errors!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset


 You may have the trigger and echo wires backwards. I have did it 2 or 3 times already and it didn't damage anything.
Logged


Toledo, OH
Offline Offline
God Member
*****
Karma: 36
Posts: 514
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I've successfully created an interrupt-driven ping function and added it to my development NewPing.  I'm probably going to add a few different interrupt types to satisfy different needs.  This first one uses the timer1 interrupt.  It works fine, but I'm not overly happy with one aspect and I'm hoping someone with experience has some insight.

In the sketch, it's currently being called like this:

Code:
void setup() {
  sonar.ping_timer1(); // This calls the ping
}

// Timer1 interrupt (I'm using prescale at 64 with the interrupt at 7 counts, in other words, every 28 microseconds this function is called).
ISR(TIMER1_OVF_vect) {
  if (sonar.ping_check()) {  // Check to see if we got a ping echo.
    Serial.print("Ping: ");
    Serial.print(sonar.convert_cm(sonar.ping_result));  // Print the result
    Serial.println("cm");
  }
}

Again, it works great.  But, what I'd really like to do is clean it up a bit for the end-user.  Instead, I'd like it to look like the following:


Code:
void setup() {
  sonar.ping_timer1(echoCheck); // This calls the ping and sets the interrupt function to "echoCheck".
}

void echoCheck() {
  if (sonar.ping_check()) {  // Check to see if we got a ping echo.
    Serial.print("Ping: ");
    Serial.print(sonar.convert_cm(sonar.ping_result));  // Print the result
    Serial.println("cm");
  }
}

Functionally, identical, just a little easier to understand for the end user.  I understand the basic concept of adding the ISR(TIMER1_OVF_vect) in the library and setting it, but I just can't seem to get it to work without a compiler error.  So, I went out looking for someone else who's done something similar and found the TimerOne library.  The library is fairly simple so it's an easy read.  Specifically, I'm interested in how he does the ISR(TIMER1_OVF_vect).  I've tried to duplicate it, but it just won't compile.  I could give my errors, but I've tried so many different ways that I've had maybe a half dozen different errors.  I think I've nailed down where my problem is to here:

Code:
TimerOne Timer1;    // preinstatiate

ISR(TIMER1_OVF_vect)          // interrupt service routine that wraps a user defined function supplied by attachInterrupt
{
   Timer1.isrCallback();
}

Anyone know what this "preinstatiate" is?  I would think I could in the case of NewPing do the following:

Code:
ISR(TIMER1_OVF_vect)          // interrupt service routine that wraps a user defined function supplied by attachInterrupt
{
   NewPing.isrCallback();
}

But, no.  Anyone have any tips or could point me in the right direction on how I should implement having a function call set a function and wrap it insde an interrupt service routine?

Tim
Logged

Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

Toledo, OH
Offline Offline
God Member
*****
Karma: 36
Posts: 514
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

15 minutes after I post all that, I think I have it figured out.  I did some snooping around in Arduino.h and WInterrupts.c and I believe this works:

Code:
void (*intFunc)();

ISR(TIMER1_OVF_vect) {
if(intFunc) intFunc();
}

With the ping_timer1 doing this:

Code:
void NewPing::ping_timer1(void (*userFunc)(void)) {
intFunc = userFunc;

Note to self, go snooping in the Arduino code for tips in the future.

Tim
Logged

Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

Ontario, Ohio
Offline Offline
Full Member
***
Karma: 1
Posts: 209
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi Tim,
What object do you use to for your ultrasonic sensors to sense? Could you describe the conditions? I'm gonna try your library soon on my maxbotix sensor soon. It's wired the same way, so hopefully it works.
Logged

Global Moderator
Netherlands
Offline Offline
Shannon Member
*****
Karma: 224
Posts: 13917
In theory there is no difference between theory and practice, however in practice there are many...
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset


Better do not use print statements in interrupt routines as they take relative long times, while interrupts are made for fast responses.

every 28 microseconds this function is called).
ISR(TIMER1_OVF_vect) {


That means the code is re-entered every 28 micros.

the print statements wil take  - 12 bytes * 10 bits / 115200 = about 1 millisecond  // 10 includes start and stop bit, actually it is higher.

1 millisecond means ~35 times reentered.

Needs some rethinking I guess ...
Logged

Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Toledo, OH
Offline Offline
God Member
*****
Karma: 36
Posts: 514
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi Tim,
What object do you use to for your ultrasonic sensors to sense? Could you describe the conditions? I'm gonna try your library soon on my maxbotix sensor soon. It's wired the same way, so hopefully it works.

Objects can be named whatever you want, and you can use any number of objects.  I use "sonar" for the object name in the Example Sketch.  But, in the Two Ping Sensors Example Sketch I use "sonar1" and "sonar2" for the object names. I would imagine that most people would use "ping", "radar", "sonar", "ultrasonic" or something like that for the object name.  But, you could have the object named "maxbotix" and have any number of objects defined, think "look_left", "look_right", "look_ahead".

The only condition is NO_ECHO, which is defined to 0 (false) meaning there was either no ping, or the ping was outside the set range.  Basically, the NO_ECHO (false) condition is that there wasn't a ping.  Other than that, it returns the distance or the ping time (depending on what method you used).

With the next release, there will also be at least one type of interrupt-based ping.  The event-driven methods won't have a NO_ECHO condition.  Because, as it's event-driven, there will only be an event when there's a ping echo within the range specified (the only condition will be that there's something in range).  Basically, the goal of the event-driven methods is that you set a range to say 100cm and then you're off to the rest of your sketch, doing whatever the real goal of your sketch is.  When the ping condition is met (something within 100cm let's say) you then do whatever action is needed in your sketch.  You may have different things you need the sketch to do depending on what the ping distance was.  That's up to your sketch to figure out.

Basically, there's two conditions, NO_ECHO (false) and echo (the distance to the object).  For the interrupt methods, there's only "alarm" conditions, that something is in range, and obviously what that range is.

Tim
Logged

Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

Toledo, OH
Offline Offline
God Member
*****
Karma: 36
Posts: 514
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Better do not use print statements in interrupt routines as they take relative long times, while interrupts are made for fast responses.

That's true. But, by the time the ping_check is called and it's been satisfied, the timer interrupt has already been canceled.  So, the user is free to do whatever they want with the result.  Heck, they can go right back to adding delay(2000) statements in their code for all I care! ;-)

But seriously, what you're not seeing in my little code snippet is what happens in the library before a true condition is met.  It doesn't make total sense with what I posted as it wasn't the full code.  But, be assured that I've made provisions so Serial.print or even long delays won't break anything.  To insure things work for the average joe coder, my development test not only has those 3 print calls, but 6, and I added a delay(1000) in for good measure, and it still works just fine as the timer interrupt has already been canceled.

But, thanks for pointing out a potential deal-breaker if I hadn't thought about that already.

Tim
Logged

Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

Ontario, Ohio
Offline Offline
Full Member
***
Karma: 1
Posts: 209
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi Tim,
I meant to ask what kind of physical objects do you put in front of your sensors to test them?
Logged

Toledo, OH
Offline Offline
God Member
*****
Karma: 36
Posts: 514
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi Tim,
I meant to ask what kind of physical objects do you put in front of your sensors to test them?

Wall, chair, hand, box, coffee cup, etc.  It will seriously see anything, even a fast moving object.  One of my goals was to make the library fast enough where you quickly swing your hand in front of the sensor and it would detect it.  As you can do pings every 37 milliseconds, it can sense a very fast moving object.  Not a bullet, but plenty fast for just about any bot situation I can think of.

On the topic of these sensors on a bot.  One of the reasons I starting writing this library was because one of my end goals was to create a fairly fast moving bot that could have several ultrasonic sensors that would work in combination that could quickly map out an environment and make fast decisions on direction without ever having to stop, delay, back-up, delay, turn, delay, move forward.  If we can get readings 10 times a second from 3 sensors at different angles and use an algorithm to convert that data to a frontal map, I believe fairly effective navigation can be achieved.  But, that's another library for another day...

Tim
« Last Edit: June 02, 2012, 05:06:43 pm by teckel » Logged

Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

Ontario, Ohio
Offline Offline
Full Member
***
Karma: 1
Posts: 209
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Awesome! That's great news. I'm most interested in human detection, but we're definitely on the same page. I have been getting some pretty accurate and precise readings with my maxbotix sensors using the crap (code) that I came up with recently, but there's always room for improvement. It's not in a library, but it works. For my purposes I don't even need to be that accurate, but I need it to be reliable. I have several ultrasonic sensors that I've been messing with, but I always get these stray readings. One or two are fine within a half second, but more than that mucks up my purpose. I will try to implement your library with my sensors (maxbotix) soon, and hopefully get some quality results.
Logged

Toledo, OH
Offline Offline
God Member
*****
Karma: 36
Posts: 514
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Awesome! That's great news. I'm most interested in human detection, but we're definitely on the same page. I have been getting some pretty accurate and precise readings with my maxbotix sensors using the crap (code) that I came up with recently, but there's always room for improvement. It's not in a library, but it works. For my purposes I don't even need to be that accurate, but I need it to be reliable. I have several ultrasonic sensors that I've been messing with, but I always get these stray readings. One or two are fine within a half second, but more than that mucks up my purpose. I will try to implement your library with my sensors (maxbotix) soon, and hopefully get some quality results.

The biggest problem with the other ultrasonic libraries is that they wait for up to a second for the ping echo to return.  During that time, the ATmega is doing nothing else but waiting.  It can return quickly if it "sees" something (or should I say "hears" something), but if not it basically just hangs.  NewPing doesn't do that.  And with the new timer interrupt code that will make it in the next release, there's even less down time.  It's also just as easy to use as before too.

Tim
Logged

Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

Toledo, OH
Offline Offline
God Member
*****
Karma: 36
Posts: 514
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

While I have my development library working using Timer1 interrupt, I'm not totally happy with it because Timer1 is also used for the servo library.  The problem with using Timer2 is that it's only 8 bit so you can't do a long timeout event.  I'm trying to do as much as possible event driven, but at the same time I don't want to cause too many conflicts.  It looks like I'll be creating two new timer methods.  Using the Timer1 method will allow a more full-featured event-driven ping scheduler.  Using the Timer2 method will have reduced features but won't conflict with the servo library (Timer2 does conflict with the tone library, but that shouldn't be a deal-breaker for most).  When using a timer you also lose PWM control on two pins, but again, having two timer options allows you to use the one that would conflict with the rest of your project the least amount.  Keep in mind you can still use these pins, you just can't use them for PWM.

In any case, there's been no new updates because I want to make sure I'm heading in the right direction before I release something half-baked and then have to change things down the road which may require sketches to be adjusted.  I'd rather avoid a situation where an old sketch doesn't work as-is with a new library release.  I hope to have something to release by Thursday, but that's if I have no snags.

Tim
Logged

Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

Global Moderator
Netherlands
Offline Offline
Shannon Member
*****
Karma: 224
Posts: 13917
In theory there is no difference between theory and practice, however in practice there are many...
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
The problem with using Timer2 is that it's only 8 bit so you can't do a long timeout event.
You could add a counter in the timer2 ISR that will check only every 10 overflows (sort of cascading)

Code:
volatile byte counter = myPreferedValue;
void ISR()
{
  if (counter-- == 0)
  {
    do your check
    counter = myPreferedValue;
  }
}

does that make sense?
Logged

Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Pages: 1 ... 3 4 [5] 6 7 ... 34   Go Up
Jump to: