When simulating a lidar sending MP a MAVLink message with mavlink_msg_obstacle_distance_pack() with this test data:
const uint16_t distances[] = {
1100,990,880,770,660,550,440,330,220,110,
100,200,300,400,500,600,700,800,900,1000};
the distances appear displayed correctly on the radar:
Can that garbage be avoided?
Thanks, that is clear. So how does MP know the number of samples of the 72 that must appear in the radar? First 0 is the end?
My understanding is that this line here sets the array up to avoid the garbage, if im honest im not 100% sure on how it works, it was @count74 that done it originally.
memset(distances, UINT16_MAX, sizeof(distances)); // Filling the distances array with UINT16_MAX
The docs explain it pretty clearly…
This line fills the array with placeholder (which tell ardupilot to ignore these segments) values, before the actual distance values are written to the array.
And you give me way to much credit for this code. I frankensteined it together until it worked.
I havent found anything better to use as an interface for proximity projects so im still using your frankensteined code. I really havent changed much other than the type of rangefinder and how it moves.
Using your 72 segment proximity, and the i2c rangefinder adapter that @ppoirier done I can pretty much interface any rangefinder I can find a library for usually by just copy and pasting a couple of lines.
Perhaps the field called number of segments tells it… 
All I find is offset, initial angle, and angle occupied by each sample. Anyhow, according to all said above, I modified the data as follows:
const uint16_t distances[72] = {
100,110,120,130,140,150,160,170,180,190,200,210,220,230,240,250,260,270,280,290,300,310,320,330,340,350,360,370,380,390,UINT16_MAX
};
Anyhow, that didn’t solve the problem I am observing: the distances radar (yellow traces) hangs frequently.
I made a 1920x768 video of it:
It is long so you can go directly to the end, as indicated on the Youtube video index.
As far as I have seen, the Delta2G lidar sends a frame of 30 distances for each 24º (0.8º/sample as seen on the MAVLink inspector), with 16ms from frame to frame. Each frame corresponds to a yellow arc. For producing some video animation, the offset of the first sample in each frame is changed on the simulation.
The MP (1.3.80 build 1.3.8693.15776) error trace window is:
that yellow proximity display does not look correct, I have never seen anything like that. you must not be maping the lidar to the mavlink correctly as the only way you would get that swirl on the display is if your trying to feed more than 72 slices into it so it gets offset more each rotation.
so 30 measurements for each 24 degrees, 360/24=15 15x 30 = 450 slices
so mavlinkAngle = map(lidarAngle, 0, 449, 0, 72);
that will map the 450 slices to the 72 slices of the mavlink interface.
your only sending 72 slices not 450 so it cannot be less than 5 degrees on a 360 degree sensor I dont know why you have it set to 0.8.
I am not doing that on the video; I am simulating the lidar.
All comes from changing arcs on an video which tries to be animated. Later comes the slow image capture at 10fps.
If you want to see the details of the arcs, a slight change on the simulation gives:
Easy: 24º/30samples. You can see it on the MAVLink inspector on the video.
But the important thing is that the simulation simply sends mavlink packets using standard mavlink calls (also for above image) to MP: it should not hang.
your not sending anything correctly, you cannot get 0.8 degrees, it best you can get is 5 degrees as you can only send 72 slices when using a 360 degree sensor.
Have you ever tried to sample the 450 samples per revolution that a real Delta2G produces?
The one I got was faulty so I never got to test it. if your struggling to process it with the 2040 then you might need to look at the stm32 f4 blackpill board as its a much more powerful chip. the 2040 is pair of very low power m0+ cores and is just barely fast enough to run the XV lidar.
another option would be to split the code so the reading the lidar is done with core 1 and sending the serial data is done with core 2.
Forget about the lidar simulator. It keeps bussing after the failure, as seen on MP red traces radar window and MAVLink inspector window. It doesn’t even read the lidar: it simply generates the MAVLink messages towards the FC for the 30 first distances in the distances[72] array, on the video above as if the vehicle carrying the simulated lidar were rotating. But connecting its wires requires time, and I am not going to lose it trying a different processor.
There is a physical FC for sending the stream with all the MAVLink messages to the laptop on a 921800bps stream over wifi, which also keeps bussing as well as MP itself other windows (main, MAVLink inspector, red traces radar, ^F window with thousands of buttons…). It is a core i5, but I have observed this hanging also now on an i7 and a Celeron. About its performance for MP, I have run in the past on it four MP instances at the time for four vehicles, each with a 921800bps stream over wifi, having a mechanical disc (now it has a SSD, with much better start time and general performance), and it kept bussing.
The MP tracing error window says something about a matrix destination not long enough.
Are you sending regular heartbeats? I dont see any on mavlink inspector?
After some corrections on the simulator, and having connected a physical lidar for the timing, this is the result:
The vehicle transporting the lidar rotation simulation is clearly visible.
This is with the rotation even slower:
BTW, slowing the rotation seems to hang MP distances radar window faster, if there is a scientific explanation.
Both MP error trace windows say:
Reference to object not stablished as object instance.
Not on previous video, yes on two videos above, irrelevant:
Other, with rotation even slower and capture at 4K with MP running on a core i7:
Also:
Could you send your simulator for debugging MP ?
I will put here shortly a link to a parameterizable version not requiring lidar.
