I had initially posted this discussion on the DIY Drones ArduRover User Group Discussion Forum, but I thought that I would move it to the new APM Rover Discussion Forum as there is only about one month left before the Sparkfun AVC.
Tridge, Linus, and I have been doing a lot of code developement and debugging to provide the most robust operating functionality for any APM equipped rover that will compete in the AVC.
We have added the ability to sequentially trigger the Maxbotix series of acoustic range finder sonars and have added a push button start to the autoonomous mode to meet the AVC requirements of no onboard radio.
Tridge has been working to convert the navigation code to L1, but is still in the testing phase.
Regards,
TCIII
Hi Tom,
What is the status of PX4 for this especially dual sonar support?
@Gary,
I do not know at the moment. Since time is getting short, we have been concentrating on the APM2.5. Tridge can probably tell you the status of the ArduRover2 code in relation to the PX4.
I just received my development PX4 FMU and PX4 I/O, but I only have the older V1 PPM encoder and I do not know if it will work. I believe that it did not have a crystal for the mcu and had excessive jitter.
Regards,
Tom C
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
Hi Tom,
Regarding the sonar sensors, you could also try mounting some sort of shield or cone around the bottom of your sensor to block it’s view of low objects. Just be sure to use a smooth material. I’ve used Maxbotic sonar sensors and discovered that the sonar would bounce off of a smooth surface like tile. I would guess your table may actually be in the sonar envelope, just too smooth to return a strong signal. Shielding the bottom of the sonar should allow you to keep a nice wide envelope where you want it, not angled up into the air.
Kev
Hi Tom,
It could be that the table is actually in the sonar envelope, but that it is too smooth to return any signal. I have seen maxbotic sonars bounce off tile at nearly 45 degree angle without detecting it. You could try shielding the bottom of your sonar sensor with some kind of smooth material. That way the sonar will not be able to detect low objects (like the ground.) You would be able to keep the sonar mounted level, which would still allow you to have the widest part of the sonar envelope pointing at objects level with your rover instead of up into the air.
Kevin
This is going to further complicate things but what if you installed the sonars on a servo controlled tilt platform with a “default” tilt angle you could set as a parameter. Then use the sensors on the board to stabilize the sonar(s) so it holds that angle. It may only really work well for flat areas but if you could take into account a few other things like elevation change and back out the base tilt angle of the sonar relative to flat ground, you could probably have it take care of bumps right?
It’s possible there may be too much noise in the sensors to do this well with something rolling on the ground but I would also assume the suspension on the truck takes care of some of that noise. Filtering the data over X points may be a bit problematic though.
You could also do a comparison of some sort. Any drastic angle changes greater than X within Y milliseconds of a sonar trigger is considered noise and should be ignored. Of course if you’re headed into a wall and it starts to brake, you’ll also get that drastic change but it’s another idea.
For those entering, don’t forget to register and submit video before May 8…
Hi Bot_Thoughts,
Yes, I am registered and approved by the Sparkfun AVC authorities.
Regards,
TCIII
Hi All,
This is an empirical test of the latest ArduRover2 v2.41 firmware:
I started out just running a small preset waypoint course with 8 waypoints and no sonar. Each run got better as the GPS accuracy improved.
Then I set the learning mode and recorded an 8 waypoint course still without active sonar. As before each run got better as the GPS accuracy improved. So far so good.
I then turned the sonar on and ran the recorded waypoint course successfully. There seemed to be minimal false targets as the rover ran pretty straight over the course.
On the final run I decided to put an 2 ft wide object infront of the rover as it started the wapoint course. Well, it did not avoid the object and ran straight into it. Oh boy. What is wrong?
So I went inside, setup the learning mode, and set the trigger distance to 100cm as the nearest target that both sonars can see is ~135cm.
While in the steering mode I placed a target infront of the left sonar and guess what, the steering turned left right into the target. I then tried the same thing with the right sonar and the rover made a right turn into the target.
So I went back to the steering angle parameter and changed it to a -25 instead of the +25 I had it set to originally. Well that cured the problem. Simple fixes are always the best.
Now when I place a target infront of the left sonar, the steering turns right like it should and when a target is placed infront of the right sensor, the steering turns left as it should.
So, I think that Tridge needs to change the obstacle avoidance steering code such that a positive steering angle will result in the rover turning left when it sees a target on the right and turning right when it sees a target on the left. For testing purposes I will keep the steering turning angle at the negative value to be able to continue testing.
Comments?
Regards,
Tom C
Hi All,
Tridge, our ArduRover2 programmer, and I have been analyzing the AVC waypoint files for the placement of obstacle on the vehicle course and have found that they are not consistent with the picture of the parking lot showing the placement of the barrels, hoop, and ramp.
We decided to go with the waypoint files to define the placement of the obstacles on the vehicle course in the parking lot and have built our rover waypoint course based on those files.
We have found other analyses of the vehicle course obstacle placement on the web and they more or less agree with our analysis of the obstacle placement.
Regards,
TCIII
Hi All,
I have finally arrived back in Ft. Lauderdale from the Sparkfun AVC in Boulder. Fortunately for me the weather was just some occasional moderate rain and a few brief down pours on the way back home.
The following is a brief overview of our team’s performance in the vehicle portion of the AVC:
Our waypoints were spot on except for the waypoints between corners 2 and 3 where the hoop was located.
Our waypoints were about 1 m inside the actual course and had there been time to run a practice loop, I would have been able to correct those waypoints before the start of the heats.
So for the first heat the rover turned too soon at the 2nd corner and ran inside the hay bales that marked the end of the parking lot course. Had the rover not run into the hay bale at the 3rd corner and made the turn, we would have made a complete lap, though we would have been penalized for running inside the hay bales between the 2nd and 3rd corners:-)
So I corrected the waypoints between corners 2 and 3 during the stand-down between the heats and completed a successful practice run before the start of the 2nd heat. Since I could not see if the rover cleared the hoop, but did clear the ramp, I did not make any additional corrections in the waypoints between corners 2 and 3.
At the start of the 2nd heat our rover ran straight and true towards the first turn, but was unexpectedly hit by a yellow wayward bug rover that was moving diagonally across the course towards the left side hay bales. The bug hit the right front wheel of our rover, bounced over our rover and hit the hay bales. Our rover took the hit in stride, corrected its course, proceeded towards the first corner, and was the first rover to finish the course during the 2nd heat. We missed the hoop, but cleared the ramp which gave us about 364 points.
On the 3rd heat I forgot to turn the ESC on so at the start of the race the rover did not move until I realized the ESC was off. I think that we only lost a few seconds at the start and we made up for the late start with a higher cruise speed of 5 m/s instead of the 3 m/s I had initially been running at. I believe that we were either the first or second rover to cross the finish line during the 3rd heat.
We scored 50 points on the first heat, 364 on the 2nd heat and 368 on the 3rd heat. I increased the speed of the rover on the 3rd heat so we scored more points for being faster over the course.
I have saved the tlogs and plan to go over them when I get back to Ft. Lauderdale.
Next time I plan to bring my ArduStation Mega to attempt to verify the obstacle “real” GPS coordinates in relation to the “published” coordinates so that I can make some real time corrections to the course waypoints if necessary.
Regards,
TCIII
Some comments about rover jumping and getting wrong signals: maybe it is possible to study acceleration graphs and see what is going on during a jump. Maybe there is usable acceleration characteristics that can be used to mute sonar signal during landing. Maybe it is acceleration and gyro combination.
@Riff_
Since barrels are used as course obstacles the sonars have no trouble detecting and avoiding them on the course. I set the speed through the barrel chicane to 1 m/s so that the sonar would have time to react to the barrels and make course changes as necessary. The rest of the course was run at 3 - 5 m/s.
The course hay bale markers do not reflect well and the sonar cannot reliably see them.
I set the elevation angle of my sonars such that they would not see the ground when the front suspension was fully bottomed out. Also, since the sonar signal debounce parameter was set at two, the sonar does not have time to react to the ramp before the rover front wheels are up the ramp elevating the front of the rover so that the sonars do not see the ramp anymore. Test with an identical ramp proved out this theory before travelling to the AVC.
Regards,
TCIII
What is the current status?
@Riff_,
It depends on what you mean by “current status”.
Sparkfun has announced the 2014 AVC here: https://www.sparkfun.com/news/1317
As far as my participation goes, I plan to be there in 2014. I have refurbished my winning Peloton Class 1/10 scale Traxxas Slash Rover and have built a 1/8 scale Traxxas E-Maxx Rover called Crusher. I am presently ringing out the latest ArduRover2 firmware and tuning my rovers in preparation for the coming 2014 event.
We are presently looking at using a low cost laser range finder for obstacle detection in place of the sonars, but I do not know if they will be ready by the AVC. There is also movement towards replacing the APM with either a Pixhawk or a BeagleBone Black and use object recognition for obstacle avoidance, but that is somewhat down the road.
Regards,
TCIII Developer
I and probably other ppl are most interested in hearing how your build is progressing. Builds are always inspiring…