Closed jmachuca77 closed 4 years ago
Hi @jmachuca77 I took a brief look at your dataset and have a few problems.
extern const int N_SCAN = 8;
extern const int Horizon_SCAN = 6000;
extern const float ang_res_x = 0.06;
extern const float ang_res_y = 2.857;
extern const float ang_bottom = 17;
extern const int groundScanInd = 4;
labelMat.at<int>(i,j) = 1;
to skip segmentation completely.Ok, thanks I'll give that a try. I have not seen issues with the rate on the vehicle, maybe a problem with the bagfile or the recording... I'll check. About the spec, what I posted is from the lidar you found, but from the user manual
Sorry for the delay, I tried the modifications, however the results were very similar to what I have before. The forward movement seems ok, but as soon as I get to a turn it fails to register that correctly, what should be a 90 degree turn, seems more like a 45 deg turn.
This is with the setting for the lidar you posted on point 2 above and the suggested change on point 3
This is with my settings for the lidar and your suggested change on point 3 above.
seems like it initially does the turn correctly, but then drifts off by 45 deg.
seems like it initially does the turn correctly, but then drifts off by 45 deg.
Are you using IMU with it? If yes, have you tried to not use the IMU?
Hi @jmachuca77 Could you share with me a brief example of the Quanergy M8 Lidar bag files, please! At first, I think I am generating bag files wrong, could you guide me through the process to achieve a good bag file for this Lidar sensor.
Your help will help me a lot !
Hi I am trying to set up this package to work with the Quanergy M8, however I am not having good results with the standard setup. The Quanergy lidar has 8 beams at 10hz it has an angular resolution of 0.06deg, the lowest beam is at -18.25 deg and the highest beam at 3.2 deg. So I have the following settings:
When the package starts as long as its driving in a straight like it works ok, but as soon as it turns it gets lost. Im not sure if I have something setup wrong or if its something else. I am wondering if the problem is that the beams are not at equidistant angles. And if that is the problem is there a way to modify the code to cope with that?
You can find a couple of bag files on these links: rightCircuit.bag leftCircuit.bag
This is the launch file I am using:
and these are the mods I've made to the utility.h file:
Here are the relevant parts of the spec sheet: Timestamp The timestamp for each packet occurs when the last firing of the packet has been completed, that is, after the firing of beam 7.
Position The encoder position occurs when the first firing of the packet has been completed, that is, after the firing of beam 0.
Laser Firing The M8-PoE+ sensor spins at 10 Hz (at its default and recommended setting). The lasers fire at a constant rate of exactly 53,828 Hz. The lasers do not fire simultaneously, but in a sequence to avoid interference. The firing sequence is 0, 4, 2, 6, 1, 5, 3, 7, where 0 is the lowest downward-looking beam, and 7 is the highest upward-looking beam. There is no horizontal or vertical angle offset.
Beam Angles The pointcloud_generator_m8 source code specifies beam separation angles (Figure 18), from bottom angle to top, in radians, as follows:
The values in the code are designed for working with optics. In round numbers, the vertical field of view is 20 degrees, the theoretical value for beam spacing is 3 degrees, and the top beam is about +3 degrees. The laser firing position is shown in Figure 19.
7. Q: If I change the rotational speed of the M8-PoE+ sensor within the 5-20 Hz valid range, what happens to the laser fire timing? Does rotational speed affect heat production? A: Changing the frame rate does not affect laser fire timing, nor does it have a significant effect on heat production. The angular resolution will change as a result of the changed rotational speed under constant firing timing. The 10 Hz frame rate (recommended for most applications) corresponds to 0.06 degree angular resolution.