The opticalflow wiki is pretty self explanatory, we just have to insist on the fact that signal must be adjusted to equivalent level
@ppoirier thanks for your answer on gitter.
The calibration procedure is on the PX4FLOW wiki but not on the CX-OF one, maybe is better to replicate it or to put a link.
Anyway I will do the calibration and I will report my results.
Are you able to see OF values in Mavlink Inspector on MP?
Do you know if it is possible to fly in FlowHold without lidar indoor?
Sorry for so much questions.
I dont see OF on Mavlink Inspector, I know it has been change quite recently and it has a double star “**”" , so I guess it is note readeable by Ground Station atm , maybe someone could be using dronekit python to intercept message …if really necessary (and if generated by FC)
As for different flight modes and rangefinder I still have to complete components integration before tests
I think flowhold should work indoors without a lidar.
I actually think it should be possible to fly the cheerson without calibrating it… It may not be perfect but I think it will work.
@rmackay9 calibration deserves 3 purposes:
1- It confirm that you have consistent OF signal
2- It shows if sensor is correctly aligned with IMU
3- It is part of a good system check and tuning
Do you think we will get some form of realtime signal reading on Mission Planner like we used to with the PX4Flow?
As for the MavLink OPTICAL_FLOW message, did you tested it? And if yes; How?
I tried with FlowHold indoor and I saw an enough stable horizontal pos but an unstable vertical pos and, as I already said on the other thread, I see recurrent messages:
[MAV 001:1] EKF2 IMU0 has stopped aiding
[MAV 001:1] EKF2 IMU0 is using optical flow
both with EK2_GPS_TYPE = 3 and with EK2_GPS_TYPE = 0
Whereas in an outdoor test flight with EK2_GPS_TYPE = 0 when I switch to FlowHold fro Loiter I see a strange behaviour described here:
I saw this link mentioned above:
Will it be possible to connect the CX-OF with I2C?
Adding more and more sensors and the UART are an “expensive” resource.
OK , I finally had some time to run test on my Q33O Powered by PIXRACER
- Upddated to chibios 3.6.4
- Installed the sensor , add a 3.5 volt regulator, connected to serial
- Calibrated sensor (as described above)
- Used EKF3 (the existing PX4FLOW was using this and I wanted to compare)
- Connected to Mission Planned - set the EKF Home and di the ''walk test"
- Confirmed that vehicle was moving on screen as on real
- Switched to loiter and did the flight test
here is a picture of the setup:
TOP Benewake TF2 running as Lightware I2C emulation on I2C
Here is the flight test
(look at the end the drift between the initial walk and the actual flight test on the map)
@ppoirier, txs for the test. So it looks like it’s working which is great. It’s hard to see the scale of the drift is from the video… perhaps a few meters?
@rmackay9 Lol …You made me realize that the video does not really demonstrate OpticalFlow !!
Here is a more convincing sequence, basically stability in centimetric , 10-30cm depends on the perturbing airflow moving around the enclosed garage:
@ppoirier, OK so that was the vehicle trying to hold position with no pilot input? Not bad… it gives us an indication of what level of performance people should expect.
@sevet, re the crazyflie flow sensor, I suspect it will work but it hasn’t been tested yet. One thing to note though is that as far asI know it doesn’t use I2C but rather SPI. Only the original Pixhawk1 board has the SPI port exposed I think.
@rmackay9 to my knowledge other board with SPI port exposed are: Pixracer (needs change in hwdef.dat to use esp8266 port as SPI), RevoMini (needs change in hwdef.dat to use OPLink port as SPI) and Omnibus F4 (this has SPI port but I don’t see relevant config in hwdef.dat for it)
True, but the pixhawk 4 does have a port labeled SPI (witch is why i expected it to have an external SPI port) but it doesn’t work, even when you remove some of the # in the sourcecode it doesn’t have a CS pin. (or at least not one that I could find in hw.def)
@rmackay9 working on a new build of Mini Quad (180 Size) with a MatekF405 + TFMINI + Cheerson OF
Bad optflow health
Edit: This problem is related to MatekF405 as I can make it work with a PixHawk. I will investigate on the chibios gitter and report back.
There’s an issue in the Copter-3.6 issues list which sounds like what you’ve found:
- mateksys F405 UART2/3 same? see Gino Nencioni Copter-3.6.0-rc12 available for beta testing
I was not sure if this issue was real or not so I haven’t pushed it but I’ll bring it up on next Tuesday’s dev call
Randy, please note that i can use the range finder on any ports at different speeds, but I cannot connect the OpticalFlow on any port either with or without rangefinder present. So for me the problem looks like a driver incompatibility (or inconsistency).
Question why do you set speed within the driver, shouldn’t it be through configuration ?
@ppoirier, OK, not sure what the issue is then - I guess it’s a lower level board specific issue.
I think forcing the baud rate to 19200 is OK in this case because it ensures the user doesn’t accidentally set the baud rate incorrectly and saves the user some time in the setup. If it’s necessary that it’s configurable then we can change the driver to use the parameter.
OK Thanks to @OXINARF ,
I forced the Cheerson Driver on ‘‘other boards’’
Please note that I had to use EKF3 for making it fly stable… EKF2 was diverging and spitting EKF stop aiding every 5 secs.
So here is the result on a 190 Size frame & Matek F405 (sorry for the rotation)
Here are some pics of the installation:
Thank you for that so roughly moving about 30/35cm did you manage to get a serial benewake TF mini working with it,many thank’s,Marty.