Is obstacle-avoidance implemented in 3.1.1 Rover? Parameters RNGFND_TRIGGR_CM, RNGFND_TURN_ANGLE and RNGFND_TURN_TIME suggest that it is, but trials seem to have proved negative. I’m working with a small catamaran ArduBoat with skid steering, Pixhawk, LidarLite (I2C), and v. 3.1.1 Rover firmware. I have correct range indicated (in Mission Planner as “sonarrange”), but no avoidance action. Occasionally a spurious “obstacle” message is issued, unrelated to real obstacles, and typically at range below that specified by RNGFND_MIN_CM, but again, there appears to be no concurrent action. No message at all appears to be issued when real obstacle detection is indicated by “sonarrange”.
@martinandriener,
There were problems using the LidarLite I2C for communication with the Pixhawk. You might try using the PWM output instead.
Regards,
TCIII AVD
Thanks for the idea, Thomas. I had read of that, and hoped that it was true that the problems were resolved with the Garmin v3 which I have. I assumed that, since range data appeared stable and accurate as viewed in Mission Planner as “sonarrange” (given a target), then any collision-avoidance algorithm using that data should work. But you have motivated me to experiment with PWM as an alternative.
Has collision avoidance been proven by ArduBoat users, working with the RNGFND parameters?
I don’t think its popular with boat users due to the boat moving up and down and getting false triggers. Plus its not waterproof. I have a maxbotic sonar on a rover at the moment and the obstacle avoidance is working but its limited. If it detects an object it just tries to steer away from it. I have a gen 1 LidarLite which I could put on the rover and test. I’ll try and make that happen.
Tom is right though - PWM is much better then I2C for these LidarLite’s as they interfere with the whole I2C bus. The PWM wiring and setup isn’t too hard and is documented on the Wiki.
I’ll let you know how I go.
Thanks, Grant.
Hi Grant,
During my testing using sonar for obstacle avoidance during the Sparkfun AVCs, I found that I could not go much faster than 3m/s and have sufficient time for obstacle avoidance. It just took too long at higher speeds to avoid head-on obstacles.
Regards,
TCIII AVD
That sounds about right Tom. Sonar’s rely on the speed of sound and only work out to about 7m so when we detect an object we have just over 1 second to react. Its just the nature of Sonar I’m afraid.
Thanks, Grant.
Since my first query post I’ve done quite a lot of trials with LidarLite v3, with Rover 3.1.1 and with Rover 3.2.0-dev. Results:
- Both I2C and PWM interfaces (with RNGFND_SCALING = 0.9) yield valid range readings with 3.1.0.
- PWM interface yields valid range readings with 3.2.0-dev, but I2C interface does not work with 3.2.0-dev.
- Both interfaces result in severe interference with autopilot motor control, so that the question of implementing collision avoidance becomes moot.
The test track, comprising 4 waypoints in a partial “W” pattern, with RNGFND_TYPE = 0 can be seen here. The test track with RNGFND_TYPE = 5 (PWM) can be seen here. The erratic track with RNGFND_TYPE = 4 (I2C) is similar to that for PWM.
Examination of graphs for RCout, Ch1 (port, on my skid-steer ArduBoat) and Ch2 (stbd), for the cases of RNGFND_TYPE=0 and RNGFND_TYPE=5, reveal the surging that I witnessed. Again, the data for I2C interface is similar to that for PWM interface.
In the unlikely event that anyone cares to analyze the log files, I’ve posted those for three runs with firmware v. 3.1.1, for RNGFND_TYPE=0, for RNGFND_TYPE=4, and for RNGFND_TYPE=5.
There is no apparent interference with motor control in MANUAL mode, only in AUTO; leading one to believe that the problem is not one of electrical/magnetic interference, but perhaps one of processing.
No improvement in performance was obtained by masking the send and receive lenses of the LidarLite.
Pete
Hi Pete. In 3.2.0-dev there has been a re-write of the low level drives to remove the inefficiency of the PX4 drivers. This includes the I2C driver. I don’t have a LidarLite v3 but I do have a v1 which I will test with.
Odd that it interferes with the motors. Not something we have observed previously - I’m not saying its not an issue but just stating the odds that its more likely something particular to your vehicle. Do you have a photo of your build so I can see the wiring any layout?
I’ll have a look at your bin files to see if I can identify what’s going on.
Thanks, Grant.
Hi Grant, Thanks for the response, which I luckily caught while on the road back to Oregon from the site of the water trials in Florida.
A wiring schematic is in the works, but for quick response I’ll say again that the problem appears already in the RCout signals and does not manifest itself when operating in MANUAL mode, so I really thought it was likely an I/O processing problem.
I was working mainly with 3.1.1 since I2C interface did not work for LidarLite with 3.2.0-dev, and I did not yet have 3.1.2 to experiment with. There is a typo in my previous post where I say “Both I2C and PWM interfaces (with RNGFND_SCALING = 0.9) yield valid range readings with 3.1.0.” I meant 3.1.1.
Thanks,
Pete
I’ve just tested with the 3.2.0-Beta1 and my LidarLite 1 is working fine on I2C. I’ll see if I can borrow a LidarLite 3 from someone and test with that.
Note I set RNGFND_TYPE to 3. For a v3 you should use 15. See the doco here:
http://ardupilot.org/rover/docs/parameters.html
Thanks, Grant.
Your not seeing electro magnetic interference. Your seeing ArduPilot driving your motors back and forth as a result of your tuning. Try doubling the NAVL1_PERIOD to slow down the aggressiveness of the steering. A boat is more like a plane then an RC car when it comes to steering so the NAVL1_PERIOD needs to be higher. After that you can change your PID values to smooth out the steering.
You have set STEER2SRV_D to 0. The default is 0.005.
You also have your arming checks turned off which isn’t a good idea.
Thanks, Grant.
Thank you, Grant. The pointer to Rover parameter documentation evidently filled a blind spot for me. I mistakenly relied on Mission Planner (v. 1.3.44) built-in parameter documentation, which misled me to choose RNGFND_TYPE=4 for PX4-I2C and RNGFND_TYPE=5 for PX4-PWM.
In any case, using RNGFND_TYPE=4 resulted in the wildly erratic motor-drive signals from ArduPilot that you can see in the log files or RCout graphs that I posted, which are certainly not present when the LidarLite was not operational (i.e. RNGFND_TYPE=0), even with NAVL1_PERIOD=8.
As a matter of fact I did run a series of trials my last day in Florida, with NAVL1_PERIOD set to 5, 20, 30, and 40, to confirm a previous probationary determination that NAVL1_PERIOD=30 worked pretty well for us; I used NAVL1_PERIOD=8 for the LidarLite trials only because it was the “default” value (albeit for land Rovers, not water-borne Rovers) and I’d observed quite acceptable, stable behavior with that setting without the LidarLite interface.
On arming checks: forgive me for saying, but it is a code feature that I felt I could do without. Beginning with Rover 3.0 (after 2.5), I found that I had to set ARMING_REQUIRE=0 to run at all, so I became disenchanted with what seemed like code overburden. Also I worked quite a bit trying to effect remote arming (for the purposes of starting a new log file and setting “HOME” since it always reset to the location where arming occurred), and was unable to arm the Pixhawk any other way than by the hardware switch.
Unfortunately I’m not able to do more water trials with RNGFND_TYPE=15 where I am now.
Thanks for all your help,
Pete
Grant and all,
Apologies, I just realized that my link to graph of RCout for Ch1 and Ch2 in #7 of this thread, “RNGFND_TYPE=5” was broken.
Comparison of that to the graph of RCout for RNGFND_TYPE=0 was meant to illustrate that the wild excursions of ArduPilot control signals to the motors are certainly not the result of tuning parameters. This would be even more clear by careful examination of all three log files for which links were provided, for the cases of RNGFND_TYPE=0, RNGFND_TYPE=4, and RNGFND_TYPE=5.
I now understand from Grant’s post #10 of this thread that RNGFND_TYPE=15 should have been used for I2C interface rather than RNGFND_TYPE=4; however, it remains true that valid range readings were obtained with I2C interface of LidarLite v3 using RNGFND_TYPE=4, and I know of no alternatives to RNGFND_TYPE=5 for PWM interface.
Pete
The Parameter documentation is “auto” built from the code. In Mission Planner it will only have the documentation for the Stable release of the code however the Wiki is dynamically updated all the time. You were using a DEV build for which the parameter documentation had changed in the Wiki but not in Mission Planner.
You should be able to use the “SET HOME” function in the ground station to reset the HOME position.
Remote Arming on the water is difficult as the code by default wants to calibrate the GYROs on startup and on water they are moving around. You can turn off the gyro call on startup - see this parameter:
http://ardupilot.org/rover/docs/parameters.html#ins-gyr-cal-gyro-calibration-scheme
If the arming checks are failing it should give you some indication of what’s going wrong on the ground control station screen. In Mission Planner you can also check the console tab for information. The arming checks are helping you by telling you something is wrong with the vehicle. Its normally best to figure out what they are saying and then if that arming check is invalid for some reason you can turn off that check only but leave the others in place. At the end of the day the arming checks save vehicles by telling people something is wrong before they operate their vehicle.
RNGFND_TYPE=5 for the PWM interface is the same for ALL versions of the LidarLite. They have not changed their PWM interface.
I see your point regarding the RC output no oscillation when the RNGFND is disabled. I’ll have a look.
Thanks, Grant.
1 Like
Kind thanks again for your thoughts on this, Grant.
Not to nit-pick, but for the LidarLite trials I was using Rover v. 3.1.1, stable release, as the I2C interface did not work for me with v. 3.2.0-dev (with RNGFND_TYPE=4). Both I2C and PWM interfaces worked with 3.1.1 insofar as valid range readings were obtained.
In trials of operation with and without EK3 and Compass enabled, discussed elsewhere, I used Rover v. 3.2.0-dev because v. 3.1.1 would not work at all with EKF disabled—no target heading.
Thanks -
Pete
has anyone done much more with collision avoidance on boats. my main concern is sonar or lidar giving false readings when the boat is rocking, does anyone know if the flight controller will reject range information if its at extreme angles ?
Did you get further with this?
I’ve just started playing with a friends OAK-1 for collision avoidance on our arduboat.
amazing camera - but lots of learning required - both me and the camera.
No, I am waiting for a lidar to arrive for testing. its my understanding it will be more resilient than ultrasonic as the water should absorb it rather than cause refections. I eventually plan on going to forward looking radar as waves shouldn’t effect it and it should work better in rain or fog.