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:
(packets every 16ms: 15x16ms=240ms <> 250rpm moreless)
The vehicle transporting the lidar rotation simulation is clearly visible.
(MP error trace window)
This is with the rotation even slower:
(MP error trace window)
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:
The MP error trace window says:
Destination matrix is not long enough. Check destIndex and lower matrix limits.
Also:
- Again, with a slow rotation simulation hang happens soon (???).
- MP also hangs on a faster PC.
Could you send your simulator for debugging MP ?
I will put here shortly a link to a parameterizable version not requiring lidar.
For your Arduino, adapt serials, pins,… → carry to MP.
Note:
- Comments for having nice numbers.
- Pins to synchronize an oscilloscope.
- Simulates two aligned lidars rotating at the same pace at a vehicle rotating (bigger N_FLOAT/N_INTEGER slower vehicle rotation), but only one on the drop down.
- No heartbeat for component_id MAV_COMP_ID_OBSTACLE_AVOIDANCE+1. Needed? (Easy to add).
- 30 distances commented. 72 distances not appearing all on MAVLink inspector.
- Not possible to display the second distances radar window (no drop down, and which component_id to use?).
- Many yellow arcs missing (very few appear on the core i5).
I have seen a crash on the core i5, but seems to last long on the core i7.
Possibly, you should start commenting the code for the second serial (second packet MAV_COMP_ID_OBSTACLE_AVOIDANCE+1).
Note that if two radar windows were possible, it would be needed to identify which is which. I asked in the past some id on the caption bar for a similar situation, but didn’t get any answer.
I also have had always to stop Arduino activity (with reset or however) while MP connects; if not, it keeps reading parameters forever.
Capture on the core i7:
Seemes yes:
So add line:
mavlink_msg_heartbeat_pack(FC_SYSTEM_ID, MAV_COMP_ID_OBSTACLE_AVOIDANCE+1, &msg, MAV_TYPE_GROUND_ROVER, MAV_AUTOPILOT_INVALID, MAV_MODE_PREFLIGHT, 30, MAV_STATE_STANDBY);
between the two Serialx.write’s.
Simulating two lidars, with 20 frames and 72 distances/frame, this is the result, captured at 4K:
Right distances radar window (197) crashes first:
and later left distances radar window (196) crashes:
Since there is too much flickering (lidars rotation is difficult to appreciate), I reduced simulator to 5 frames, also with 72 distances/frame:
Lidars rotation is easily appreciated.
Left distances radar window (196) crashes first:
and later right distances radar window (197) crashes:
To reduce flickering further, I reduced simulator to 1 frame, also with 72 distances/frame:
Lidars rotation is easily appreciated, and also the archimedean spiral shape.
Although it took longer, both distances radar windows crash.
Left distances radar window (196) crashes first:
and later right distances radar window (197) crashes:
Testting, but I don’t get something. Why are you doing this magic with scan index and angles?
The Delta is capable of scanning at 4Hz or more; why don’t you collect one full 360-degree scan in your program and send it as a single Mavlink message.
1 Like
Consider a previous capture, which corresponds to the Delta2G (commented distances in the simulator):
So it scans 15 times (SCAN_STEPS, with frameIndexTest 0 to 14) per revolution, 30 distances each scan (EFFECTIVE_DISTANCES, up to 72 (not all the 72 appear in the MAVLink inspector)). Since the distances are uniformly incremented, the center of the yellow segmented arcs can be in a archimedean spiral, so if you place 15 walls like them, segments of archimedean spirals (lidar in the starting point, by now static), you would obtain those measurements (total 15*30=450 so 360/450=0.8).
But I saw that MP radar distances window crashes. If doing a video capture of that static image to catch the crash, it would be very boring and not informative, so the program simulates that the lidar is over a CW rotating surface, and it evolved to other values of number of scans, number of measurements per scan (up to 72 (not all the 72 appear in the MAVLink inspector)), rotation speed, and two lidars one over the other (aligned and rotating at the same speed).
startAngleTestN is an auxiliary variable. The important thing is that the angle of the first measurement in each scan (distances[0]) is:
startAngleTestN/N_FLOAT+(frameIndexTest*360.0)/SCAN_STEPS.
Surprisingly, even in the most simple case (SCAN_STEPS=1, 72 distances (not all the 72 appear in the MAVLink inspector), 360/72=5º) MP distances radar window crashes, even on a core i7.
Number of distances limited to 72 (not all the 72 appear in the MAVLink inspector) in one MAVLink message.
Did you consider that the Object avoidance database’s maximum angular resolution is 1 degree in the ardupilot? Did you tried to feed this data to an ardupilot controller ? And see how it is cope with it ?
For Delta2G lidar 360º/(15*30)=0.8,º close to that. But the simulator only simulates; if the angle is large or small doesn’t matter. For parameters used for above videos the sample angle goes from 0.25º to 5º.
Two (or one modifying code) serial MAVLink 2 connections from the Arduino (no physical lidar connected to it) with the simulating code to the FC, in this case a Pixhawk1, 2GB, STM32F427, running Ardurover Balance Bot v4.4beta, over the table, in vertical position, not armed.
The FC is connected to the laptop with a wifi connection, with the MAVLink stream at 921600bps. As said, if MP is UDP connected when FC is already receiving packets from the simulator, it keeps “Getting Params…” forever:
The FC keeps bussing. MP not so much. BTW, I have tried on another very similar core i7, perhaps with faster graphics (less yellow traces flickering), on which I did a fresh MP install and beta upgrade (it was not installed). Distances radar window also crashes.
Have you prepared the Arduino, connected it to the FC, prepared the FC with required parameters (serials, prx’s…), connected MP to it, and gotten the distances radar windows with the yellow traces rotating? If so, do the yellow traces distances radar windows crash?
that happens because mission planner is trying to connect to the lidar and it wont get any parameters, you need to reselect the flight controller from the drop down.
Ok, here is the thing, your GCS should receive DISTANCE_SENSOR messages. In your case OBSTACLE_DISTANCE messages are meant for the FC, you should set the serial port options “do not forward” to keep it in the FC.
The error you encountered is a concurrency error, the incoming messages are too fast, and in a rare case the data object is cleaned up while it is drawn. I’m testing a quick fix for it. But this does not change the above.
I don’t see your point. Doing this connection succeeds, but then I cannot connect to the streams with lidar data:
This is the expected outcome. Lidar data should not go to the GCS. It is a sensor connected to the FC, and FC process it.
1 Like
You are deluding yourself into thinking you’ve achieved success while you have the ear of a developer experienced with this protocol. You’d do well to listen to his input.
While the sensor itself may be capable of 0.8° resolution, the FC cannot ingest that. Use your intermediate hardware to put the obstacle data into a form that’s useful by the FC.
Anyway, I put up a PR for fixing the MP issues… Proximity: Fix Proximity UI concurrency issue by EosBandi · Pull Request #3222 · ArduPilot/MissionPlanner · GitHub
1 Like
BTW, I did a fast test on a MacOS M1 with Sonoma. The same happens (MP osxlatest, something like 1.3.8702.35058):
If having the yellow traces radar window (spiral rotates), how can I expand it (in this case to 8.5m)? ‘+’ and ‘-’ keys (as others and combinations) cause a bong.
Also, on the MAVLink inspector all 72 distances appear (not like 56+2/3 as in the MP windows version):
but I can’t resize or move that window.
It happens that my initial intention was to try these lidars on a balance bot (now I think to start first with a simple rover, skid steer type, similar to this, without or with the doll), so I took one, and it seems the worst case.
I tried with another Pixhawk1 alone (data and supply on its USB connector) with Copter beta version, serials 4/5, left it and MP bussing a whole night with 72 distances and SCAN_STEPS=1 (5º/sample, biggest spiral) and MP didn’t crash.
I flashed on it the Rover beta version, but with FRAME_CLASS=1, and forcing everything:
DISTANCE_INTERVAL=4 (four times faster than Delta2G):
Back to the 0.25º/sample (maintaining 72 distances):
SCAN_STEPS=20
Faster baudrates for both simulated lidars:
SERIAL4_BAUD=SERIAL5_BAUD=1500 (above: frame occupies one third of the 4ms interval)
MP kept bussing (1.3.80 build 1.3.8693.15776). It has never hung. Here and here are two long 4K captures.
Unfortunately, as had happened before, graphics are not fast enough and the yellow traces appear occasionally:
BTW, the Pixhawk1 STM32F427 was just a bit warm, perhaps around 40ºC.
So success on Copter and Rover/Rover; failure on Rover/Balance Bot. Does this vehicle frame dependancy make sense?
Here is a similar Delta2G simulation capture in 4K for one lidar, including the red proximity circles, which also hangs:
