RPLIDAR A1 (xv 11) and A2 reading data noise

Hello coders!! im reading realtime values from rplidar a1 and a2 but i get something wierd… they should give me angle from 0-359 degree… but give me 0-510 more less… and are no radians… any idea about what´s going on??.

And also any way to select DAT by values easily?? for example i´d like to limit that table dat in the picture until colum 1 value maximun 360… i can´t do by index row because values change and 360 could be on time on row 270 others 290 … :blush:

Thanks!
and then ciao the extra degree because show me a lot of noise in the visualization point and the blob track

by the way… @ben are you going to make and operator for this device?? could be nice :smiley:

what are you using to interface with the lidar?from what I know this lidar should be outputting hex data and there are some calculations needed to get the right data into touchdesigner.

I’m using a similar lidar but with a different protocol but I think the theory should be the same,did you calculated checksum before output the data of the lidar according to the lidar’s datasheet?if all were done according to the datasheet there should be no problem like this.

thanks for reply @kanelau

I´m using a arduino mega with many serial port, one of them is reading the lidar and other sending data to TD by serial as i said.

I did all the mathematic inside TD, and y see very clear the mesh and position os the scene or room… but with a lot of noise from that extra values.

I thought the values could be radiant or degree, not hex data. I will check it again when i get back office with the sensor next week.

But this is the toe and extra files if you or anybody want to have a look.

lidar_a1.zip (94.3 KB)

Regards

Javo

@lightnotes we’re doing this pretty much the same way but since I’ve been writing the lidar code ground up I’m not experiencing the noise issue,but I think I know what went wrong where the lidar scan passes the zero point(0 degree)and the calculations done were not right.

You should review your Arduino code and adding something like this should resolve this problem:

  if (CHECKSUM == ( PAC_DATA[8] + (PAC_DATA[9] << 8)))//this calculates the checksum
          {
            PT_ANGLE_S = (PAC_DATA[4] + ((PAC_DATA[5] >> 1) << 8)) / 64;//getting current packet start angle
            PT_ANGLE_E = (PAC_DATA[6] + ((PAC_DATA[7] >> 1) << 8)) / 64;//getting end angle
            if (PT_ANGLE_E < PT_ANGLE_S)//note this:with packet near zero a 360 shall be used to get the right data
            {
              if ((PT_ANGLE_S > 270) && (PT_ANGLE_E < 90))
              {
                ANGLE_INTERVAL = (360 + PT_ANGLE_E - PT_ANGLE_S) / (PT_REAL_SIZE - 1);
              }
            }
            else
            {
              ANGLE_INTERVAL = (PT_ANGLE_E - PT_ANGLE_S) / (PT_REAL_SIZE - 1);
            }

this should resolve the >360 issue

 if (PT_ANGLE > 360)
              {
                PT_ANGLE = PT_ANGLE - 360;
              }

the above code is based on my lidar so you may have to alter it a little bit to your lidar’s protocol but I hope you got the idea.

and for interfacing with TD I’m still working in progress but instead of using nodes I used python and a OpenCV function that directly translates polar coordinates to the regular xy ones,and feed into a DAT to SOP to get point cloud.this toe is still having some performance issue with large number of points but it do work.hope that inspires you.

the data i feed TD from arduino:

the point cloud result like this:

and the TD project:
lidar-td.toe (23.3 KB)

Thanks @kanelau i did´nt see you reply this post sorry for delay. But finally we develope our software or plataform to deal with all kind of sensor that we normaly use for interactive installations. Soo now it´s pretty easy to configure many device at the same time and send all clear data by osc/udp to any computer with TD

Regards
Javo