More testing now with 7 way scanning, I think what I am eventually going to do is have a dynamic scan radius based on vehicle speed,
when stationary it can scan all 8 sectors,
when moving slowly forward it can scan 7 sectors,
as it gets faster it will limit that down to 5 sectors then 3 then just fix it straight ahead once its fast enough that should give a good compromise of scan speed vs coverage.
In the high speed forward facing configuration it could pan the servo slightly as the vehicle turns so it’s looking where the vehicle is going.
If using something like a lidar with a very narrow beam the servo could be moved a little as its taking reading to get a more complete reading of its sector.
This should work with multiple different rangfinders mounted to the same rotating platform, as long as they are at least 45 degrees apart they will never occupy the same orientation.
yes, i remember reading about something similar but it was while ago.
Your solution on constantly scanning and feeding the position back is a much faster way, but as you describe on github that comes with timing problem since there is a delay causing accuracy issues, its also limited to one rangefinder where this script will work with any rangefinder supported by arudpilot but now that I think about it, It wouldn’t be hard to implement your method in the same way but using the ADC to set the rangefinder orientation.
By stopping and waiting at each sector for the readings to stabilize before enabling the rangefinder gives accurate data but at the expense of speed. my plan is to eventually use this for a long range radar or LIDAR so combining enough range with a slow enough speed means that the scan speed required is reduced dramatically.
Every other method i had seen of doing this required extra hardware, usually an arduino and some mavlink or i2c that does the scanning then sends that information to the flight controller, this only uses the lua interface to access ardupilot and nothing else so no soldering is required.
The more I think about it, your method of fast scanning using the potentiometer feedback would be good as a fast search mode, where scan time is more important than directional accuracy, if something is detected it could slow down to the 8 sector mode for more accurate direction and ranging.
Just to test I added a second rangefinder, my idea of having a dedicated forward-looking rangefinder along with the scanning one looks like it should work, this way its always looking the most important way, plus having something like a LIDAR looking forward might catch things the radar misses like vegetation or tree branches.
@ppoirier I was thinking, what if we used your old POC sketch but simplified it, essentially plug 4 VL53L0 rangefinders along with an Arduino running a limited version of poc into the pixhawk i2c splitter then use the Arduino to change the i2c address of the sensors before ardupilot starts up? would they all be detected work natively?
#include <Wire.h>
#include <VL53L0X.h>
//#define XSHUT_pin6 A7 //not required for address change
//#define XSHUT_pin5 A6
#define XSHUT_pin4 A3
#define XSHUT_pin3 A2
#define XSHUT_pin2 A1
#define XSHUT_pin1 A0
//ADDRESS_DEFAULT 0b0101001 or 41
//#define Sensor1_newAddress 41 not required address change
#define Sensor2_newAddress 42
#define Sensor3_newAddress 43
#define Sensor4_newAddress 44
#define Sensor5_newAddress 45
#define Sensor6_newAddress 46
VL53L0X Sensor1;
VL53L0X Sensor2;
VL53L0X Sensor3;
VL53L0X Sensor4;
//VL53L0X Sensor5;
//VL53L0X Sensor6;
void setup()
{ /*WARNING*/
//Shutdown pins of VL53L0X ACTIVE-LOW-ONLY NO TOLERANT TO 5V will fry them
pinMode(XSHUT_pin1, OUTPUT);
pinMode(XSHUT_pin2, OUTPUT);
pinMode(XSHUT_pin3, OUTPUT);
pinMode(XSHUT_pin4, OUTPUT);
// pinMode(XSHUT_pin5, OUTPUT);
// pinMode(XSHUT_pin6, OUTPUT);
Serial.begin(115200);
Wire.begin();
//Change address of sensor and power up next one
// Sensor6.setAddress(Sensor6_newAddress);//For power-up procedure t-boot max 1.2ms "Datasheet: 2.9 Power sequence"
// pinMode(XSHUT_pin5, INPUT);
// delay(10);
// Sensor5.setAddress(Sensor5_newAddress);
pinMode(XSHUT_pin4, INPUT);
delay(10);
Sensor4.setAddress(Sensor4_newAddress);
pinMode(XSHUT_pin3, INPUT);
delay(10);
Sensor3.setAddress(Sensor3_newAddress);
pinMode(XSHUT_pin2, INPUT);
delay(10);
Sensor2.setAddress(Sensor2_newAddress);
pinMode(XSHUT_pin1, INPUT);
delay(10);
//ADDRESS_DEFAULT 0b0101001 or 41
}
void loop()
{
}
I have some VL53L1X ordered too lol.
I have tested 4 ultrasonic sensors and a radar this week and im waiting for VL53L1X VL53L0X, TFmini plus and A02YYUW ultrasonic sensor. im working my way through the driver library lol
@rishabsingh3003 I dont think that is quite what im looking for, I believe I need a lua proximity sensor rather than a lua rangefinder, as im essentially making a proximity sensor from a moving rangefinder.
what would be ideal is way to make a proximity sensor with more than 8 directions. The plan will be eventially to use @ppoirier idea of using the ADC to feedback position from the servo to better track its movement.
@geofrancis ah I posted on the wrong thread. I vaguely remember reading something from you where you wanted support for more rangefinders and wanted to write the drivers for them? This might help you out in that. This PR can also be used as a template to get proximity-based lua driver
yes that was something I was discussing before and now I have had some time to understand your pull I can see how it can be useful. It can be used to make drivers for rangefinders using just lua as a driver meaning adding a driver is just adding a script.
I had a discussion about this with @Yuri_Rage before, about how a lot of device drivers would be much better as lua drivers as they are very simple devices and very niche with few people using them so is it really a good idea using up space for a device that very few people will ever see.
winch, generator, sprayers, lawnmowers, these are all simple devices that could be run with some lua as its just simple GPIO, there is no complex math or timing requirements on these devices. im hoping to start replicating opensource versions when the i2c lua gpio port expander board becomes a reality.
@rishabsingh3003 I’ve got a couple of FMK24-E radars coming my way. Would be very happy to be able to integrate them via LUA rather than necessarily having to write a driver. Either way I’m sure we’ll get something working between myself, @Yuri_Rage and @geofrancis. If a few of us lead the way and agree on a sensor that many others may wish to use then a driver is worth doing.
@rishabsingh3003, I took delivery of the FMK24-E5200 radar from @geofrancis yesterday and already have it working via your new Lua bindings on a Matek H743-Wing v2 (cloned your repo and switched to the lua_rangefinder branch).
Curiously, the rangefinder only seems to keep the last reported target as a persistent obstacle in the database. Since the 5200-series reports obstacles from nearest to distant, that means the farthest obstacle is the one that remains.
I found a workaround for that. I haven’t seen more than 5 target returns in a single message yet, so I just made 5 Lua rangefinder devices (RNGFND1-RNGFND5_TYPE=35). I index the returns in each message accordingly and ignore any beyond the fifth. It works!
Sample script attached (must be run on custom built firmware at present, using this branch).
