thank you for your reply
yes that’s what it’s like, but in the PX4flow wiki you dont use any range finder yet, despite this you have retrieved not null data
So we will have to add a range finder for the data of the Px4flow
opt_m_y and the
ground_distance provided by the Range finder will be visible in APM planner ???
thank you for your reply
Please read wiki carefully
‘‘Although the sensor may be supplied with a built-in Maxbotix LZ-EZ4 sonar to measure height, this has not been reliable enough over a range of surfaces in testing, so its readings are not used. It is recommended to purchase a PX4Flow device without the sonar…’’
Rangefinder distance signal will be showned under sonar
yes I already read this article cent faith I know that I have to use an external telemeter to use the px4flow, I already buy a lidarlite v3
but i try to get the data opt_m_x & opt_m_y, in order to calibrate the sensor as indicate on http://ardupilot.org/copter/docs/common-px4flow-overview.html#calibrating-the-sensor, it’s is why I asked you
is it normal that opt_m_x & opt_m_y change randomly as you can see in the screenshot???
thank you in advance
Are they really random ?
If you move up-down-up-down and left-right-left-right, are the x & y signals change accordingly ?
It would be much easier if you use Mission Planner because it is eaier to give support with common references.
hello @ppoirier ,as you said, I will add the lidar OcPoc and see if I can receive the data of PX4flow on APM planner
which is strange, as you can see in this photo, I just launched arducopter, and the PX4flow sensor is fixed in its position (vertical position facing the ceiling) but even so the data you see in the photo changes
is this change normal despite the fact that the sensor is frozen in this position ???
As I wrote before ;
Are they really random ?
If you SLIDE front-back-front and left-right-left-right, are the x & y signals change accordingly ?
they’re not really random when I slide fore-back-forward-and-left-right-left-right, the x and y signals change accordingly
but in order to maintain the position the x & y signals must be null
in my case (see screenshot) despite the sensor is freeze this place, you can see x and y which vary (y, passes from 20 then 45 then 108 then 144 then 37 … it’s normal ???
Well Alex, I never really tried working with raw signal, what I can tell you is on Mission Planner you can read the movements looking at opt_m_x & opt_m_y . I think you should install Mission Planner so we can have common ground, and then I can help.
I have already installed APM planner but then and following the steps
I connect that PX4flow sensor as indicated in the wiki I can get on
the APM HUB data IMU (IMU integrated OcPoc), and I could not see
opt_m_x, opt_m_y and an opt_qua, and it is for that I debugged with a
I will connect this time the two sensors, PX4flow and lidar at the
same time (I think the problem comes from the fact that it takes a
thank you so much @ppoirier
you are absolutely right
using the PX4flow on my OcPoc Zynq mini, I set the pramétre as indicated in the wiki (I flashed the PX4flow with QGC)
I add lidar lite v3 with parameter RNGFND_TYPE = 15
but, when running APMplanner I have two problems:
1-The PX4flow data is displayed all nulls,
2-Lidar (sonarrange and sonarvoltage) do not appear on the HUB,
so I add some printf to debug the code
I find that it detects well the sensor and they start to provide data
after a few seconds (30 sec) the lidar disconnects
can you help me please
This is probably cause but an insufficient power supply to the Lidar.
We recommand to allways feed the LIDAR with a dedicated UBEC (3-5Amps) and on my setups I add an additional 200-600uF Capacitor to filter output 5Vcc
As for the other issues please use Mission Planner, its the only way I can really help
forr now, I do not have UBEC (3-5Amps)
by plugging these two sensors to the OcPoc which is powered via USB
even if the data are null in status but in mavlink inspector I receive data opt_m_x, opt_m_y, sometimes and other times the data becomes null again (I think it’s because of insufficient power)
in your opinion, this data is correct ???
But how do you use this data opt_m_x & opt_m_y for for automatic position keeping ???
As I wrote above dir you tested:
yes, if I slide back and forth left-right-left-right, the opt_m_x & opt_m_y signals change accordingly
how do you use this data opt_m_x & opt_m_y for for automatic position keeping ???
Cool then get back to the wiki, enable OF in EKF , proceed with calibration and test flight
What about rangefinder, is it stable now ?
I do not know if because of the insufficient power supply (two sensors connect to the OcPoc) and that the OcPoc is powered via USB,
I can not go to the calibration step, because the data opt_m_x & opt_m_y, do not display continuously over time, sometimes one of the two goes to zero, sometimes both, every second,
see the following screenshots
I will try to feed the OcPoc with a battery (according to their site, if you connect several sensors to the ocpoc, it is advisable to use a battery)
- and as for the Lidar (I tentatively try to feed it with a GPIO pin of a Raspberry pi3 (5v and the GND)) but I still can not get lidar data on APMplanner
- and if I connect it directly to the OcPoc via the cable i2c, on a terminal I always see that after a moment of operation (30 seconds ~ 40 seconds) the Lidar disconnects and displays a message that I add to the code here (PX4Flow don't work)
Try adding pullup resistors (2k) between sda-vcc and sck-vcc, it might resolve the problem
for lidar or optical flow ?
On each I2C bus , if they are on different bus, you need to add pull ups on both.
Do you have the schematic of the OcPoc ? We could check if they have implemented pullups on board.
you are right,
firstly there was an error in the datasheet by following them, there were 2 cables reversed (SDA, SCL) using an oscilloscope I fixed the problem
then there is also the current that is insufficient, I drive the Lidar with 5 flight, it walks without bug (there is 10 cm more in each measurement, adjusting RNGFND_OFFSET I solved the problem)
and for i2c buses I think they are pullup ports because I get reasonable data