Matek Systems Optical Flow Lidar Sensor 3901-L0X Module Support INAV for 210mm 220mm 240mm 250mm 4/5/6 inch Carbon Fiber FPV Racing Drone Quad Quadcopter Frame

The product works awesome, however note that this is designed for interfacing with commercial flight controllers and if you're looking to use this in a DIY project its very difficult to tease out how to interface with this thing since zero information is provided. I searched for hours trying to find something and eventually resorted to reading the iNAV code to see how they manage to interface with these.Here's what you need to know:Unit sends telemetry on the UART at 115200 baud w/ 3.3V logic. There is no need to request telemetry, packets are sent periodically all by themselves. No unit configuration or setup is needed either.Packet format is "MSPv2", MultiWii Serial Protocol v2.The optical flow data and the lidar range are sent in separate packets. Lidar packets come at maybe 20 or 30Hz, flow packets at maybe 5Hz or so... total WAG, I didn't measure.Packet format is pretty simple, all bytes are little endian:$XD0YYZZ...C"$XD0" is the packet header and is fixed. Technically the "D" indicates the direction for a request vs response but it can be ignored. "0" is the packet "type" but best I can tell its undefined in the MSP spec and is always "0""YY" is a two byte uint16 defining the function. In this case the lidar packets are coded with function = 1 and the optical flow sends with function = 2."ZZ" is the a uint16 containing the size of the payload. Lidar sends 5 bytes, optical flow sends 9."..." is the payload itself:For the Lidar packets the payload format is XYYYY where "X" is a uint8 for the "quality" of the data ("255" seems to mean error/no data, anything less then "255" seems good), and "YYYY" is a uint32 with the range data in millimeters. Note that the range of the lidar is only 2 meters, so in reality byte 1 ranges from 0-255, byte 2 ranges from 0 to 4, and bytes 3 and 4 are always zero and can be ignored.For the optical flow packets the payload format is XYYYYZZZZ. X is quality as above. YYYY and ZZZZ hold x-axis and y-axis *velocity*. I'm not sure about the units but it seems like millimeters per second. Byte values from 0 to 127 are positive velocities, whereas values from 255 to 128 are negative velocities."C" is a checksum.Here is a simple arduino function that will decode this data from the UART and store both range and velocity in variables. It assumes you have a #define OPFlow Serial and a OPFlow.begin(115200) elsewhere in your code.void pollFlow(){ byte payload[10]; //Holds serial data long cp[10]; //Cleans the payload data and corrects sign if (OPFlow.available()>0){ char newb=OPFlow.read(); if (newb=='$'){ //Checks to see if the start of a packet is in the buffer delay(2); //Wait for the packet to arrive OPFlow.read(); //Discard packet header OPFlow.read(); OPFlow.read(); byte func1 = OPFlow.read(); //Get packet function byte func2 = OPFlow.read(); byte size1 = OPFlow.read(); //Get payload size byte size2 = OPFlow.read(); for (int i=0; i<size1; i++){ //Read payload if (OPFlow.available()>0){ payload[i]=OPFlow.read(); } else { break; //In the event that we're confused about the packet, give up. } } if (func1==1){ //If function indicates Lidar... height=payload[1]+255*payload[2]; //Compute range, discard unneeded payload bytes } else { //If packet is optical flow for (int i=0; i<10; i++){ if (payload[i]>128){cp[i]=payload[i]-255;} else {cp[i]=payload[i];} //Covert byte to signed int } xm=cp[1]+255*cp[2]; //Convert and store velocity. Note only two bytes in use. ym=cp[5]+255*cp[6]; } } }}

I purchased this one but it is never working.

Easy to install, also powerful. I recommend using a smaller flight though

It does work, sort of, with iNAV, but the sonar and trig are non functional on the board while the optic flow performance, at least using iNAV is basically useless without sonar

This device only works with certain flight controllers and Inav. Does NOT work with Betaflight.