Ultrasonic Distance Sensor/ Module

Hexy Projects and Upgrades
#15

I don’t know how exactly you call the loop, but user interrupt is very easy. Just in each cycle test some parameter for True/False and if False do not continue.
The parameter can be changed by 2 buttons:

def Init(...):
   ...
   Button(self.frame, text="Start Exploring", command=self.startExploring).grid()
   Button(self.frame, text="Stop Exploring", command=self.stopExploring).grid()
   self.bExplore = False
   ...

def startExploring(self):
   self.bExplore = True

def stopExploring(self):
   self.bExplore = False

def poll(self):
      ...
      if self.bExplore:
            autonomousMode (....)

     self.master.after(1000/FPS, self.poll)

if you run it in a separate thread you can pass bExplore as a parameter and in case of False stop the loop

#16

Thanks all for the help. Does anyone have any experience with the ArcPing command being very slow? I think this might be a function of low batteries, but some of my recent tests the movement of Hexy’s head has been very slow, seemingly pausing randomly within the movement, which causes the code to time out. Usually it will complete in ~0.5s and pass back a vector of distances, but these pauses can push it to several seconds.

#17

How many steps you use in arcPing? I use 9, which takes about 2 seconds to perform. The default was 90, I think, which is way to many.

#define ARCPING_STEPS 9
#18
  1. Same software load on the Servotor32 that you published, michal.

I’ll try to document the slow scans when I next get back on with Hexy. Trying to write up a blog post summarising this part of my learning-curve with Hexy, should have a video of Hexy exploring after this weekend :slight_smile:

#19

Progress, of sorts.

I’ve published what I’ve done to make this stuff work on my blog, hopefully should be enough for others to replicate Hexy exploring autonomously.

Unfortunately I’ve not managed to make a video showing off Hexy’s new skills because he’s doing his funny slow ArcPing thing again. Managed to catch the offending behaviour on camera. Any thoughts? Fully charged set of AA batteries, possibly old 9V on the logic circuit, need to go to the shops to get another one to confirm that though :frowning:

#20

This slow ArcsPing is strange. Once you call the function, it should be handled internally by Servotor32, hence independent of any serial communication until the whole scan is done. I have only one idea - that the ping function itself produces delay. Do you get reasonable output when you use multiPing()function? If you copied the code from me it might be that I messed up something in the released code. Check it against this one. I remember that I played with the ping() and mutiPing() functions, trying to optimize it without any success. So I reversed the code back, but it might be that I introduced some errors.

#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.