Integration of Pixracer with Optical Flow PMW 3901

[rmackay9]

@anbello,

I think I’ve seen the jumps in altitude as well and because you vehicle is also showing this symptom I suspect there is a small bug in FlowHold’s altitude control. I haven’t found the time to investigate it yet though. I suspect that it is not an issue with the estimation (i.e. EKF) but instead an issue in the flight mode but at this point it’s a guess.

I also found the reporting issue and tracked it down to a problem in mission planner (fixed in beta MP) and also a problem in the flight code (fixed in master). If the flight code that I posted above was used then it likely still has the flight code issue but if you feel like loading master (Ctrl-Q from MP’s install firmware screen) then I suspect this reporting issue will go away.

The EKF2 IMU0 has stopped aiding is not good. I wouldn’t expect to see that if there was a lidar attached…

[anbello]

Thanks a lot Randy
The firmware I tested was build from master (commit cb3b0bd - 4 days ago)
I will try latest master and beta MP, I was testing with APM Planner 2.

The EKF2 IMU0 has stopped aiding is not good. I wouldn’t expect to see that if there was a lidar attached…

I was testing without a lidar, I don’t have one yet. I understood that for FLOWHOLD mode the lidar were not necessary, maybe I am wrong.

[rmackay9]

Andrea,

FlowHold doesn’t require a lidar through some magical learning of altitude. What concerns me is that the EKF is still attempting to use the optical flow even though a lidar isn’t present.

I wonder if maybe EK2_GPS_TYPE has been set to 3 to force the EKF to only use the optical flow sensor and not use the GPS? Our cx-of wiki page does suggest this parameter should be set if the EKF should use the optical flow instead of GPS… but without a lidar the EKF can’t really use the optical flow sensor so the param should be left at it’s default of “0”. This is perhaps too confusing so perhaps we should clarify this on the wiki and/or change the EKF so the user can’t get it wrong.

[anbello]

The last test was with EK2_GPS_TYPE = 3, anyway was an indoor test flight.
Before I tested with EK2_GPS_TYPE = 0, but always indoor and the altitude problems seems to me even worse.
I thought that with EK2_GPS_TYPE = 3 and FLOWHOLD mode for the altitude were used the baro for altitude, but maybe it has too much error.

[anbello]

@rmackay9 I did other test.

Even with MissionPlanner-1.3.62 (11 December) and latest master I have all 0 on status and mavlink inspector for the optical flow data even if it works because I see OF data on dataflash logs.

I see the recurrent mesages
[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

Both test were done indoor.
Now I have this question: is it possible to fly in FLOWHOLD mode indoor (without GPS)?

[apm_fkw]

Hello James, I am very happy to get your explanation. I am a high school student and just started learning ardupilot. According to your introduction, I have modified the hdw.dat file and have successfully uploaded it into the pixracer. However, it is displayed in the mission planer: bad optflow health. I don’t know what caused it. Although I have already seen the datasheet, I still suspect that I have used CJMCU3901 incorrectly. This breakboard has 9 pins, which are 3V3 GND MOS CLK MIS CS RST MOT VRE. Can anyone tell me how to connect the 9 pins on this distribution board? thank you all.@rmackay9 @james_pattison @anbello

[rmackay9]

@anbello,

Sorry for the slow response. I’m unsure of the specific errors you’re seeing but in general it is possible to fly indoors with FlowHold without a GPS. In fact, FlowHold doesn’t ever try to use the GPS.

[rmackay9]

@apm_fkw,

I have also received one of these CJMCU3901 optical flow sensors so I hope to try it with a pixhawk perhaps as soon as next week. I’m afraid I’m don’t know enough about the hwdef changes to say whether they should work or not. I also don’t know how the pins could be connected on a pixracer I’m afraid.

… so I will definitely document the setup for a Pixhawk1 board with an exposed spi port but I’m likely not going to be able to help with the pixracer for now at least. Maybe another developer will be able to help… I’m just not knowledgeable enough in the low level hwdef area of the code.

[james_pattison]

The fmuv3 fw above works, and @ucaszzw has got fmuv4 going (he’s away for a couple of days but will put an update here when he’s back.
The thing to note is that at the moment it requires a custom hwdef. It isn’t a compile or runtime option.

[sergbokh]

FYI, Pixracer’s SPI pinout I’ve posted here

[anbello]

Don’t worry Randy, I know you are busy, for me this is only an hobby, i can wait.

[ucaszzw]

I just returned to the lab and have been on a business trip last week. I have tested it on fmuv3 and fmuv4 using the sensor CJMCU3901.
Many people are particularly concerned about fmuv4 because it does not have an external spi port.
Thank you very much @james_pattison, his ideas are correct https ：//github.com/ArduPilot/ardupilot/pull/9754/files . In fact, I just made a small modification at line176, the program is changed to: SPIDEV pixartflow SPI4 DEVID2 FLOW_CS MODE3 2MHZ 2MHZ, because I saw the skyviper part of the program, you need to adjust the mode to MODE3. I have tested it on Copter 3.6.4 and it works fine. However, in the 3.7.0-dev version, it cannot be used directly, because this version has made some changes to the optical flow part. I plan to look at this part of the source code these days and modify it according to the 3.7.0 version.
@james_pattison,@sergbokh,@rmackay9,@vierfuffzig,@anbello Thank you for your attention and guidance！If I have other progress, I will send it to the forum as soon as possible.

[apm_fkw]

I want to ask questions that have been bothering me for a long time.
@james_pattison,@sergbokh,@rmackay9,@vierfuffzig,@anbello，@ucaszzw

1. What is the meaning of the parameters opt_m_x, opt_x, and opt_qua in the status bar of MISSION PLANER? Why are they only refreshed once? Where can I find an explanation?
2. In the log, what do the parameters OF.flowX, OF.bodyX, IMU.gyrX mean?
   thank you. Jack

[fs007]

I want to ask questions that have been bothering me for a long time.

1. What is the meaning of the parameters opt_m_x, opt_x, and opt_qua in the status bar of MISSION PLANER? Why are they only refreshed once? Where can I find an explanation?
2. In the log, what do the parameters OF.flowX, OF.bodyX, IMU.gyrX mean?
   thank you. Jack

Optical Flow parameters change permanently in the status bar of mission planner.

Opt_qua is a value (0…255) that stands for the quality of the sensors output. IMU.GyrX should be clear: Output of gyrosensor in x-direction.

I don’t know an answer to your other questions, but would be very interested to get one. No word about all these parameters in the wiki.

[ucaszzw]

I am trying to use the optical flow sensor pmw3901 on pixracer. I have recently encountered a problem. Can anyone tell the possible cause of the error?
Why not use the Cheerson CX-OF optical flow sensor? Many people recommend me to use the Cheerson CX-OF optical flow sensor. Indeed, ardupilot has already supported this sensor. However, there is a problem with the supply of Cheerson CX-OF optical flow sensor. This is a product launched by a Chinese manufacturer. I have contacted this manufacturer through many channels. I finally learned that this manufacturer is on the verge of bankruptcy. I have not been able to get this optical flow sensor in China.I think this sensor may be difficult to obtain in the future.
In fact, I have tried the optical flow sensor pmw3901 on pixracer and have had some successful cases. @james_pattison gives a lot of guidance on this issue.In order to use pmw3901 on the pixracer, he made two changes:

1. https://github.com/ArduPilot/ardupilot/pull/9753 - this adds a check for whether the board has HAL_HAVE_PIXARTFLOW_SPI defined, and if it does, builds in the driver.
2. https://github.com/ArduPilot/ardupilot/pull/9754 - this disables GPIO and adds in the SPI pin assignments on the wifi port, adds the device to the SPIDEV table and adds the HAL_HAVE_PIXARTFLOW_SPI define. Those changes are commented out, so that this doesn’t effect standard builds.

In the actual test, I made a small modification. The mode of pmw3901 is mode 3. Therefore, I changed the parameters in the spi device table of https://github.com/ArduPilot/ardupilot/pull/9754 to: SPIDEV pixartflow SPI4 DEVID2 FLOW_CS MODE3 2MHZ 2MHZ.

On January 8th, I modified the version of Copter 3.6.4 according to the above method and successfully obtained the data on the pixracer. However, I modified the version of Copter 3.7.0-DEV in the same way and showed it on the MP: bad optflow health. Now, the problem I am having is that I downloaded the latest version of Copter 3.6.4 and used this method to make changes, also showing: bad optflow health. I don’t know if the recent update conflicts with this modification method @rmackay9 ? I also experimented on Copter 3.6.5 and Copter 3.7.0-DEV, and still can’t run pmw3901.
I think that James Pattison’s modification is feasible. I don’t know if I need to make some other changes. Can anyone give me some help?

[fs007]

@ucaszzw
SPI is never a good choice for an external bus,
maybe you should think about something like this (an arduino attached to the PMW3901, connected to the pixhawk via uart)

[ppoirier]

Interesting setup, what lens have you installed and what specific gain you expect of it?

Interfacing with an Arduino adds delay in signal process, have you successfully implemented it with ArduPilot?

[ucaszzw]

Thank you for your suggestion. It is a good method to use the serial port. At the same time, I can find many other optical flow modules using serial communication in China.
I just think it’s a viable way to configure the spi port by modifying the hwd file. I have also succeeded in the actual operation, I am only particularly interested in knowing why I have failed in recent attempts.

[james_pattison]

I can’t test it at the moment, as I’m temporarily without hardware.