Just got the latest SF40C lidar unit from Lightware. I wired it up straight out of the box. Unfortunately things are off to a bad start similar to my experience with the A2M8. I get the Bad Lidar Health message (PRX_Health = 1 recorded on the log file).
Does anybody have any tips on how to go about diagnosing the issue? I’m guessing I’m not the only one to encounter this on the first attempt to connect the unit. I’ve contacted Lightware support as well, awaiting their response.
Edit: unfortunately the unit does not come with a USB-UART cable. FTDI cable on order now, hopefully I can connect it tomorrow to check all the settings on the Lidar unit.
Running a Cube Orange on standard carrier board
Ardurover 4.0.0 Stable Release
The SF40 unit seems to be a newer hardware release - there is no separate PCB on this unit
Lidar unit connected to TELEM1
Baud set to 115200 (which I believe is the default on the Lightware units)
PRX_Type = 7
I tried powering on the autopilot before powering and connecting the Lidar unit to the autopilot - no success.
It may be that the latest SF40C driver is not included in the Rover-4.0.0 release. Could you try loading “latest” onto the rover instead? If you’re using Mission Planner this should be possible by pressing Ctrl-Q on the Install Firmware screen.
We’re planning to start beta testing of Rover-4.1 in about a month and this will certainly include the new driver… but of course you don’t want to wait that long.
Thanks for the support @rmackay9 - I just installed Ardurover 4.0.1-dev - no success (but I thought in the release notes for 4.0.0 Stable it mentioned the new SF40C compatibility. On the HUD it no longer says “Bad Lidar Health”, but “Prearm Check Failed”. When I check the proximity viewer there’s no data.
Really do need to test the outdoor obstacle avoidance soon, don’t think I can wait a month unfortunately. I know the Ardupilot development team works hard - great work on implementing Rover obstacle avoidance - hoping to share some feedback/results once I can get the unit out in the field.
As a sidenote, with 4.0.1-Dev it keeps cycling through “EKF2 IMU1 Forced Reset” but that’s a whole other issue, perhaps I need to recalibrate.
Mohit @ Lightware support has been very responsive and testing a Lidar unit on their end too to help resolve. If I understood correctly during our discussion this morning, seems to work on Copter fine.
Updated to latest firmware on the Lidar and checked the baud rate - should be good on that side:
It’s probably best to include a onboard log file if you’ve got one so I can have a peek at the parameters.
I’m not sure if I’ve ever specifically tested the new SF40c on Rover… the only thing that comes to mind is that maybe the SCHED_LOOP_RATE needs to be increased from 50 to 200 to allow the driver to run fast enough to capture all the data from the lidar…
If this doesn’t work then I’ll definitely need to try and reproduce it here…
@rmackay9 I’m still getting familiar with the codebase, but reviewing the change history for the new SF40C driver shows Copter’s “AP_Proximity” update rate was increased to 200Hz for the new driver. Rover’s code was unchanged 50Hz. Could this be a possible cause of the issue? Edit: I assume the SCHED_LOOP_RATE change should have had the intended affect?
I have been looking into the code for the RPlidar and I found two things, but I am not sure if they were an issue or not.
First, the initialise function could returns true, but with out checking if there is a positive communication with the lidar.
Second, in the initialising process there is a call to the reset_rplidar function and then a call to the set_scan_mode function. If the call to the set_scan_mode is done before the rplidar resets itself (2 ms). then the code to start scanning could be lost.
We could check this two points. I have also suggested a slightly different initialising process acording to the rplidar documentation initialising process scheme, that first goes to send_request_for_health and then to set_scan_mode. It resets if there is an error.
I tested the SF40c today with both stable (Rover-4.0.1) and latest (Rover-4.1-dev) and the SF40c seemed to be working. At least I could see distances in MP’s proximity view.
The wiki page was out-of-date though, so I’ve fixed at least 2 issues with it:
PRX_TYPE should be 7
SERIALx_BAUD should be 921
I guess from the screen shot you’ve put above the lidar itself has been configured to output 115200 but I think this should be increased to 921600 because it outputs a lot of data.
Re Rover being behind, we don’t normally coordinate the timing of releases across all vehicles but for ArduPilot-4.0, Rover actually went out first, followed by Plane and finally Copter (Sub and Tracker still haven’t happened yet).
Re the speed of development, it really depends upon the number of developers working on the system. Historically there’s been more interest and funding of the flying vehicles although Rover has picked up in the last 2 years.
Reason I was looking is compass offsets. Stuck with fixed values of offsets for compass 1 whereas 2 and 3 are customisable. None of the compass 1 offsets are suitable for my vehicle…
Thanks for testing this. I changed the Baud to 921 and changed a setting in the SF40c - LWNX must be also be set to YES for it to work. It’s working now. Looking forward to outdoor testing.
@rmackay9 yes it’s a setting that can be changed within the Lightware Upgrader app. To be honest I’m not entirely sure what the protocol entails, but Lightware support confirmed it needs to be enabled.
@rmackay9 - back on this project using rover object avoidance after a bit of a break. I’m having zero luck with getting object avoidance to work.
I see the Lidar data coming through fine in proximity viewer and the red circles updating and reflecting the environment correctly in Mission Planner. However, the rover does not avoid any obstacles currently, including stationary objects such as walls.
I might have some basic settings configured incorrectly, and yes I’ve followed the wiki instructions.
Is there any chance you could provide the PARAM file that you used successfully on the Aion R1 on your Youtube vids? A side by side comparison on my end would help greatly. Here’s mine and a full file attached.
