Ultrasonic Distance Sensor/ Module

Hexy Projects and Upgrades
#21

If you look at the code for ping() you will see that there are a couple of different problem cases that it deals with. Some of these cases will likely cause ping() to take a long time. Add to that the fact that you are actually calling ping() multiple times for each position, some of the measurements will take longer than others.

I found that I had to surround Hexy with a semi-circular wall to get a reasonably smooth run through the arc. However, even then it was sometimes not smooth and those were likely the times that I got bad readings.

I have a version with reworked parsing logic that I posted here earlier. I have actually merged this into the code-base for the next Hexy software release. Email me direct, via this forum, and I will send you the updated files.

Using the new syntax I ran a number of multiPing() calls using 15 measurements each without moving Hexy’s head.
Once I got 4 readings of exactly 19.31 but most of the time I got readings in the 17.8 to 20.2 range. However, there were a number of times that I got a response in the 1.2 to 6.0 range.

The new command parser makes it easy to take a lot of readings. Now we just need to dig into the potential reasons for the problems. I would expect a reasonably consistent answer using 15 measurements.

#22

mrmacro, I’d love to have a look at your code, I’ll pm you with my email address.

As for the apparent variation in the distances returned by the sensor, I’d expect to see some range of answers, just because it’s measuring reality and noise will always creep in. Signal processing and data integrity is a part of my day job, so if I can start to get reliable multiPing() series of measurements back it shouldn’t be too difficult to improve the reliability of these numbers being returned.

#23

I have sent you the code in a ZIP file.
I was not too concerned about the readings from 17 to 20 when 19 was expected. However, when taking the median of 15 readings, I thought that answers less than 7 were a bit unexpected.

I suspect that one potential issue is that ping() does not indicate which kind of error it got. When navigating, the difference between “too far” and “too close” has real meaning to decision making logic. The other errors are just errors.

The multiPing() logic just piles all these zeroes into the array and counts them when finding the median. That is clearly wrong also. That means that there are two places to look for errors.

The new logic has been repaired so that if you tell multiPing() to return the median of just one reading, you will get whatever the only call to ping() returned. I suggest that you start with something like #1mMMMMM and see what you think of those results.

Good luck

#24

I get this error:

Servotor32.cpp: In member function ‘void Servotor32::processChar(char)’:
Servotor32.cpp:388: error: ‘arcPing’ was not declared in this scope
Servotor32.cpp: At global scope:
Servotor32.cpp:479: error: no ‘void Servotor32::arcPing()’ member function declared in class ‘Servotor32’

How do I fix it?

Thanks
Walker

#25

Hi Walker,

Is that error being thrown when you’re using the Arduino programmer?

#26

wokman10, you have to put declaration of arcPing() into Servotor32.h

#27

Yes this the error I get from Arduino programmer and what line do I declare arcPing() in Servotor32.h

Thanks
Walker

P.S Rob I’ve read your whole Hexy website :smiley:

#28

Walker, thanks for the note.

If you’re trying to get Hexy just up and running, you can use the stock Servotor32 code from the main Arcbotics website. This thread is about how to get the ultrasonic distance sensor playing nice with Hexy, which might be more than you need right now.

I think Michael has posted a link to his version of the Servotor32 in an earlier post, if you’re interested.

#29

In the beginning after

#define GROUPS 4
#define SERVOS_PER_GROUP 8

Do I just put #define ARCPING()

Thanks
Walker

#30

Well, yes I have Hexy up and running. I’ve had Hexy for a month and I’ve fix/made a few programs and learned a little python.
I’m trying to get you explore program work.

Oh and check out my website walkerwhitehouse.com I made it myself

Thanks
Walker

#31

Ok So I put in the beginning #define ARCPING() and I still get the same error.
What do I do?

Thanks
Walker

#32

Hello,

Thanks for the edit.
I didn’t notice the “code” control until after I saw the post and then I didn’t know that I could repair it.

#33

This is an update on my last post here regarding the repeatability of the sensor.
The first thing that I did was to modify the ping() routine to stop returning zero when it detects something funny. I used negative values to indicate each of the three detected problems. I also removed the “return 0” before the break what the distance reads excessively high. This was just to let me know if the routine was detecting anything funny.

Note that I am using the new command processor that I have posted on github.

Next I positioned Hexy about 40cm from a door at the end of a narrow hall. There was more than 6.5m to the other end behind Hexy so there there should not be much multi-path reflection. I expect this situation to provide a reasonably repeatable reading in the range of 30-50cm.

I then issued the command: #1mMMMMM a few different times. This causes 5 successive ping results to be reported. The first set of readings was:
10.17, 32.41, 85.17, 31.55, 31.55 which would have resulted in a multi-ping result of 31.55cm.
The second set returned a similar pattern of results. Interesting to note is the very low first reading. Future commands did not repeat this low first reading, but the readings continued to span 30 to 100cm.

I then tried #5mMMMMMMMMMM to take 10, 5-point, multi-ping readings. The results were:
19.31, 31.55, 87.93, 19.48, 75.52, 5.17, 13.62, 32.93, 32.93, 31.55

I acknowledge that I do not know exactly the correct reading, my ruler could be off by as much as a full CM, due to lack of knowledge of the exact location of the reference plane.

Looking at the readings I expect that the correct readings would be 31.5cm. I moved to about 100cm and got something that looked more like 70cm but the variation was still very significant.

Does anybody else see this type of variation in repeatability?

#34

Hi,
Can you post your full coding for the UDS module, so I can attempt to embed it into some coding.

Thanks,
Chris.

#35

What I did to the UDS logic is of no importance. All I did was to provide negative numbers for the various error conditions in order to be able to tell when the routine was exiting early. It never did.

What is more important is the new command syntax to make this easier to test. That is a lot more invasive since it spans the 2 Servotor32 files along with the .ino sketch. I suggest that you go to github to obtain the version that I am testing with.
The page is at github.com/ArcBotics/Servotor32/network and my branch is by Fran-B.

Alternatively, you can email me and I will provide you with a ZIP containing the three files.