ArduRover v2.40 obstacle avoidance using the Maxbotix MB1240 long range acoustic sonar

451 views
Skip to first unread message

Tom Coyle

unread,
Apr 10, 2013, 3:03:16 PM4/10/13
to drones-...@googlegroups.com

Hi Tridge/Linus,

I achieved some pretty good and consistent results using the Maxbotix MB1240 long range acoustic sensor. It has a range around 760cm and I had the sonar_trigger set at 300cm. Even at that distance the reaction time results in an avoidance turn about 90cm from the obstacle. The resistance to false triggers on a concrete sidewalk is very, very good even with a reasonable amount of wind at street level. Resistance to false triggers on asphalt roadway was not as good, but I think that it was due to some vertical and horizontal sensor vibration and the fact that the sonar_trigger distance was set at ~10 feet and it could have been seeing a parked car slightly off to the right of its travel. I had to tilt the sensor upwards slightly to prevent falsh triggering, but you can hardly notice the tilt.

Presently my sensor mount is not very robust and needs to be strengthened, but the acoustic sonar may be a resonable answer to the false target issue unless we can improve the ir sensor false target filtering.

Regards,

Tom C

Tom Coyle

unread,
Apr 13, 2013, 2:22:52 PM4/13/13
to drones-...@googlegroups.com
Tridge/Greg/Linus,
 
Here is the range data filter that I believe JLN was using in ArduRover2 v2.20b:
 

// This filter limits the max difference between readings and also apply an average filter

int Filter(int new_value, int old_value, int max_diff)

{

int diff_values;

int result;

if (old_value==0) // Filter is not initialized (no old value)

return(new_value);

diff_values = new_value - old_value; // Difference with old reading

if (diff_values>max_diff)

result = old_value+max_diff; // We limit the max difference between readings

else

{

if (diff_values<-max_diff)

result = old_value-max_diff; // We limit the max difference between readings

else

result = (new_value+old_value)>>1; // Small filtering (average filter)

}

return(result);

With the new acoustic sonar mount finished on my Slash rover, I went out this afternoon to do some impromptu testing.

I was just testing for the occurrence of false targets at this time and looking for some subjective results.

The Maxbotix MB1240 performed flawlessly on reasonably smooth, white, concrete sidewalk. There were no false triggers.

On black asphalt roadway I obtained several good runs without false targets.

However there were a couple of starts on the roadway where the rover immediately started turning and went in a complete circle.

Also, there were a couple of runs where there was a random false trigger between the middle and the end of the run.

The black asphalt roadway is still the surface of contention in relation to false triggers.

I will perform more objective testing tomorrow and include tlogs.

Regards,

Tom C

Message has been deleted
Message has been deleted
Message has been deleted

Tom Coyle

unread,
Apr 20, 2013, 12:56:08 PM4/20/13
to drones-...@googlegroups.com

Hi Tridge/Linus,

Find attached two log files from the Flash EEPROM.

The first log is from runs on a concrete sidewalk and the second log is from runs on an asphalt roadway.

 I was in the steering mode for most of the runs.

 Regards,

Tom C

2013-04-20 11-44 1.log
2013-04-20 11-46 2.log

Tom Coyle

unread,
Apr 20, 2013, 2:32:07 PM4/20/13
to drones-...@googlegroups.com

Tridge/Linus,

Find attached Flash EEPROM log files from runs against a 2' wide target on the sidewalk and on the roadway.

The first log is from target runs on the sidewalk which were pretty good.

The second log is from target runs on the roadway and I could barely start out in the steering mode before the rover was making a steering correction due to a false trigger.

Regards,

Tom C

2013-04-20 14-11 4.log
2013-04-20 14-12 5.log
Message has been deleted

Tom Coyle

unread,
Apr 25, 2013, 9:52:38 AM4/25/13
to drones-...@googlegroups.com
Tridge/Linus,
Find attached Flash EEPROM logs of four different runs that I conducted with my Slash Rover this morning.
Run 1:
log 10-14 1 Auto mode, sonar off, speed 5m/s, turn speed 50%
Run 2
Logs 10-34 4, 10-35 5 Auto mode, sonar on, speed 5m/s, turn speed 75%
Run 3
Logs 11-03 1, 11-04 2 Auto mode, sonar off, speed 5m/s, turn speed 75%
 
Run 4
Logs 11-36 1, 11-38 3 Auto mode, sonar off, speed 5m/s, turn speed 100%
Rung 5
Logs 12-05 1, 12-05 2 Auto mode, sonar on, speed 5m/s, turn speed 100%
With the sonar off, the rover would run a pretty straight course from waypoint to waypoint. Since my course is very narrow, I sometimes had to stop the rover on the return leg of the the narrow rectangular course because it was going into the bushes by the side of the asphalt road.
With the sonar on, the rover would initally start out straight towards the first waypoint, but would then sort of exectue a serpentine route between the waypoints because of the false triggers.
During the second and fifth runs I placed a 2' wide obstacle in front of the rover after it had got going towards the first waypoint. During the second run it crashed into the obstacle several times. During the fifth run it managed to avoid the obstacle several times without running into it.
Hope this helps to find a way to reduce the excessive false trigger issue.
Regards,
Tom C
 

On Wednesday, April 10, 2013 3:03:16 PM UTC-4, Tom Coyle wrote:
2013-04-24 10-14 1.log
2013-04-24 10-34 4.log
2013-04-24 10-35 5.log
2013-04-24 11-04 2.log
2013-04-24 11-36 1.log
2013-04-24 11-38 3.log
2013-04-24 12-05 1.log
2013-04-24 12-05 2.log

Tom Coyle

unread,
Apr 26, 2013, 9:06:24 AM4/26/13
to drones-...@googlegroups.com

Tridge/Linus,

The first flash eeprom log 2013-04-25 22-34 2 is from last night where we saw the multiple returns on the #1 sonar and not on the #2 sonar.

The next flash eeprom log 2013-04-26 08-32 3 is where I hooked the #2 sonar to the #1 sonar input and vice versa, the #1 to the #2 sonar input.

As you can see both sonar outputs look pretty clean and nothing like the noisy output of the the #1 sonar from last night.

The final flash eeprom log 2013-04-26 08-45 2 is where I went back to the normal configuration of the #1 sonar on the #1 input and the #2 sonar on the #2 input.

Again, both sonar outputs look pretty clean and pretty similar. There is a slight bit of artifacting on the #1 output, but it is minor and I think has to do with what the #1 sonar is seeing at infinity compared to the #2 sonar as they diverge slightly from the center line of the rover at infinity.

Looks like both sonars are working properly, though it might be good to experiment with the settling time of the #1 sonar.

Comments?

Regards,

Tom C

2013-04-25 22-34 2.log
2013-04-26 08-32 3.log
2013-04-26 08-45 2.log

Tom Coyle

unread,
Apr 28, 2013, 2:06:27 PM4/28/13
to drones-...@googlegroups.com
Hi Tridge/Linus,
 

Find attached a log of rover runs when both sonars were enabled. I started out with a clear path and then put an obstacle in the way of the rover on the last few runs. It hit the obstacle 50% of the time. Maybe I need to increase the steering angle from 20 to maybe 30 deg? Or maybe change the steering time which is at 1sec.

Regards,

Tom C

2013-04-28 13-22 2.log

Tom Coyle

unread,
May 7, 2013, 3:39:44 PM5/7/13
to drones-...@googlegroups.com

Hi All,

Lately I have been putting in quite a bit of time with Tridge trying to debug the twin sonar range sensors on my rover.

Tridge has set up the code so that the sensors can be triggered sequentially so that they will not see each other's return. This works great and will help to reduce false targets due to one sonar seeing the other sonars beam.

However, I am still having problems with false returns when the rover is moving and here is what I have found:

I think that I have found the cause of the false triggers on my setup when the rover is moving on an asphalt surface.

I put the rover on a tabletop pointed at a wall 135cm from the sonar sensor.

Then I moved a 1.6cm high piece of foam forward from the rover, on the tabletop, towards the wall.

At approximately 32cm from the rover the sonar sensor beam detected the foam.

What this means is that even with the sonar sensors tilted slightly upwards from the horizontal, the vertical beam spread is such that with a little vertical bouncing of the rover chassis, the sensor is detecting the ground in front of it.

This means that I need to tilt the sonar sensors even more from the horizontal to give the beam enough vertical margin such that it does not see ground reflections, due to vertical beam spread, in front of it when the rover chassis bounces vertically.

Comments?

Regards,
Tom C

Robert Lefebvre

unread,
May 7, 2013, 3:55:25 PM5/7/13
to drones-discuss
I'm surprised that the sensor is picking up a return from an object flat on the ground (or the ground itself).  I would have thought the pulse would reflect off the ground and keep moving forward and up.  

Have you talked to Maxbotix directly about your problems?  It seems like your use case is very typical, and I'm surprised you're having this much trouble.  They should be able to help sort you out.  They were great helping me figure out what's wrong with the sensors on the copters.

Which sensor are you using?


--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Olivier ADLER

unread,
May 7, 2013, 4:07:52 PM5/7/13
to drones-...@googlegroups.com

I had this false target problem with my sonar on my multicopter.

The solution i did find was to modify the sonar directivity with a horn.

Here is the modified sonar i did :

Gary McCray

unread,
May 7, 2013, 5:55:33 PM5/7/13
to drones-...@googlegroups.com
Hi Tom,

As I see it the real problem is both that the SONAR beam spreads and the Rovers tend to bounce around a bit.

The return it sees is always the first return from anything, anywhere in its expanding detection cone.

It's not really a false return it is just doing what it is designed to do.

There at least two solutions:

1. Use one of the really narrow beam horn type sensors.
Their tightest one has a very narrow beam and they are about $100.00 each.

2. Use a stabilizing servo driven platform on the rover itself utilizing a modified version of the camera stabilizing function to keep the sonar pointed ahead of the Rover.
It would ideally differentiate between normal suspension movement from normal driving and bouncing over obstacles and a general up or down track and maintain SONAR level according to that.

This could be further extended by providing a side to side scan capability if you used a roll and pitch stabilized platform, a direct 3rd axis servo controlled yaw could provide the required scanning.

I'm planning on pursuing both of these myself.

Gary

Tom Coyle

unread,
May 7, 2013, 6:13:50 PM5/7/13
to drones-...@googlegroups.com
Hi Gentlemen,
 
I appreciate your inputs, however since time is of the essences in relation to the upcoming AVC, a simple solution is in order that mitigate the early reflections.
 
Since my AVC entry is a Slash Truck chassis  and the two Maxbotix MB1240 sonar sensors are mounted near the very front, I think that the most effective solution at the moment is to experiment with various sensor positions in angular displacement above the horizontal.
 
Presently the senors are angled up from the horizontal by about 5 deg. I will experiment with angles between 5 - 15 degrees and use the smallest angle possible that mitigates the early reflections. Since the targets that the sensors must detect are large, tall barrels, having them angled up should not affect their ability to detect the barrels.
 
Regards,
Tom C
 
 

On Wednesday, April 10, 2013 3:03:16 PM UTC-4, Tom Coyle wrote:

Gary McCray

unread,
May 7, 2013, 7:19:06 PM5/7/13
to drones-...@googlegroups.com
Hi Tom,
I understand, here is at least an idea worth trying.
Put a sheet of some flat material under and extending out in front of your SONAR several inches parallel with the ground.
Ideally it would serve to both reduce the spread of the sound out cone and possibly to shear off the unwanted lower part of the sound return. 
Even if the board is sound reflective, the unwanted part of the outgoing transducer pulse should simply be reflected up at an angle and away from the vehicle.
I am less sure about the sound return because it is a matter of sonic focus and completely outside my realm of knowledge.
But even if it only works on the outgoing sound it should permit you to get a wider part of the beam nearer the ground where you want it.
Might try an ordinary playing card.
Or even soft sound absorbing foam glued to a card. 
Like to know if it does any good anyway.

Tom Coyle

unread,
May 7, 2013, 7:44:32 PM5/7/13
to drones-...@googlegroups.com
Hi Gary,
 
Thanks for the ideas, I will try and give them a shot.
 
Actually, the real solution is to use LIDAR, but that will take a PX4, deep pockets, and maybe a bigger rover. I actually have a Traxxas E-Maxx that I was planning on entering in the AVC, but it has a high CoG, compared to the Traxxas Slash CoG, which can make it slow in the turns to avoid turning over. Also, there does not appear to be any sway bars available for the E-Maxx while the sway bars for the 2WD Slash make it turn like it is on rails. I had actually planned to use the E-Maxx for RoboMagellan.
Regards,
Tom C

Craig Elder

unread,
May 7, 2013, 8:40:43 PM5/7/13
to drones-discuss
Tom

The 1240 datatsheet
Inline image 1

Shows the area of insonification is about +/- 20degrees from the centerline of the transducer.

You need some combination of how high you mount the sonar unit above the ground and the angle that you mount it at such that there is nothing in that +/- 20 degree cone that will cause a reflection back to the transducer other than the target you are looking for.

If you are already 15 degrees above the horizon you will probably get better results by raising it higher on the vehicle.  By 60cm above the ground you probably would not see anything except what was in front of you.

Cheers,

Craig



--
image.png

Robert Lefebvre

unread,
May 8, 2013, 9:20:40 AM5/8/13
to drones-discuss
If you can get stiffer springs for the E-Maxx, it can have the same effect as stiffer swaybars.

Swaybars are not a panacea for turning with a high CoG.  They are merely one solution to a compromise between the desire for anti-roll stiffness, without putting excessively stiff springs on passenger cars.

At the end of the day, the problem with a monster truck based chassis is merely the CoG.  Swaybars are a bandaid solution.  Using stiffer, shorter springs, lowering it, will have it go around corners faster than keeping it at the existing ride height and using swaybars.


--

Aditya Mehrotra

unread,
Nov 17, 2015, 3:28:16 PM11/17/15
to drones-discuss

Hello All,

I am fairly new to developing with the APM Platform. I was looking at an ardurover with accident avoidance as well. I know the basic hardware setup I want but do any of you know where i could get an ardurover firmware with the obstacle avoidance preprogrammed in? It would make my project quite a bit faster, I would more like to modify a sample code other than create my own from scratch. I know this thread is very old but if any of you could help me out  it would be greatly appreciated, of course credit will be given I do not plan to "plagiarize" anyone's code.

Thank You,

Aditya M

Grant Morphett

unread,
Nov 21, 2015, 6:09:11 PM11/21/15
to drones-discuss
Rover has some simple obstacle avoidance built in.  The code is here.

https://github.com/diydrones/ardupilot/blob/master/APMrover2/sensors.cpp#L39

Thanks, Grant.
Reply all
Reply to author
Forward
0 new messages