Integration of Pixracer with Optical Flow PMW 3901

It can’t be done without compiling and flashing the modified firmware.

You need to copy the .apj you compiled over to your Windows file system then flash it as a custom firmware.

Save your params before flashing so you can reupload them after if needed.

Regards,

James

@anbello, @ppoirier,

I’ve just received the Cheerson CX-OF sensor and I’m planning to write a serial driver for it shortly. I don’t see any information on what input voltage the sensor expects… I guess 5V will be OK?

I tested with 3.3V and seems to me to have red to do so, but I don’t remember where.

@anbello, @ppoirier,

I’ve started working on a driver and you can see the code so far here. The driver runs without crashing but it’s definitely not correct (yet) but I thought I’d get the skeleton out there in case anyone wants to pitch in on it’s development.

So the way it should work is roughly:

  • connect the device to one of the serial port on the fligth controller
  • set the appropriate SERIALx_PROTOCOL = 18 (for “optical flow”)
  • set FLOW_ENABLE = 1

By the way, I see from @anbello’s code above that the packets are:

0: 0xFE (header)
1: ??
2: x-high byte
3: x-low byte
4: y-high byte
5: y-low byte
6: ??
7: ??
8: 0xAA (footer)

You don’t happen to know what the other bytes hold? maybe a quality number?

2 Likes

@rmackay9 the only things I know about the sensor I learned reading this
https://github.com/iNavFlight/inav/blob/master/src/main/io/opflow_cxof.c#L50
6: motionT
7: squal

In this line

The index of buf should be 5 and 4

It is for sure an error due to copy and paste

1 Like

@rmackay9 great start Randy, mine is held by postal strike (Ohh Canada…).

I presume this new driver will be processed like the PX4FLOW within the EKF and that we can compensate for the delay using the existing @Param: FLOW_DELAY

1 Like

@anbello, @ppoirier,

Thanks for the help! Here’s a potential wiring diagram for a Pixhawk1. I haven’t got one for the pixracer yet. Obviously using the switch’s VCC pin is a bit suspect but for now this will work because I don’t have a 3.3V regulator handy.

2 Likes

Just to confirm that CX-OF is a 3.3V device, the datasheet of PMW3901:
http://www.pixart.com.tw/upload/POT0189-PMW3901MB-TXQT-DS-R1.10-200617%20(NonNDA)_20170720181537_20170802183402.pdf

Moreover with a tester I see that VDD on the board is connected to VDDIO on PMW3901 and VDDIO: 1.8V - 3.6V

1 Like

The driver seems to be working now and I’ve raised a PR to add it to master. Other developers will review it now which may lead to some changes.

If anyone wants to give it a try I’ve put a binary for a Pixhawk-family of boards here. This is based on latest master (i.e. Copter-3.7.0-dev) so definitely use at your own risk although it is probably fine and I hope to give it a test fly in the next few days.

All feedback welcome and thanks for the help!

3 Likes

Thanks @rmackay9 I will do some testing asap, but not before week end.

I went ahead and tested it on my ancient Iris and it worked!

3 Likes

Great work!!!

To what height will it work?

Corrado

Corrado,

I haven’t tested it’s maximum altitude yet but I will soon and report back. I hope it works to about 40m which would make it the same as the older, larger and more expensive px4 sensor… but let’s see!

I did an altitude just now and it was holding position up to 40m and then I ran out of time because the battery failsafe triggered. I’ll repeat the test (probably tomorrow) but this time I’ll use Auto mode to make sure it’s done a bit more efficiently.

I felt 40m was about it’s limit but let’s see.

By the way, I found two issues today:

  • if both GPS and optical flow are used, if the vehicle completely loses GPS then the EKF failsafe triggers even though the EKF can maintain a position estimate with just the optical flow (issue here).
  • the lightware lw20 reports 655.35m when it gets a bad reading. This is similar to the issue we fixed with the Benewake lidar recently so I know what to do. (issue here)

Hi, could someone point me to a direction i can work on? I am facing some problems now, after flashing the customised firmware.

Hi, i am also facing the same issues. After i uploaded the custom firmware successfully, the pixracer cannot be connected to the mission planner although it has a com port. May i have some advice on this.

Thanks.

@Darren_Goh
If the firmware I linked above was loaded to the Pixracer it wouldn’t work because the firmware was means for the regular Pixhawk boards. I may include the CX-OF driver in Copter-3.6.4 which will probably start beta testing later this week. Failing that It’s possible to load “latest” from the mission planner’s firmware install screen after pressing Ctrl-Q. “latest” hasn’t gone through beta testing though so it’s possible that it has bugs.

@rmackay9 I tested CX-OF with my 280mm, 6inch props, quadcopter with Pixracer, it seems to work but I see some strangeness. Even if I have data relative to OF on dataflash log I see all 0 on Status and MAVLink Inspector (APM Planner 2); in Inspector OF data are not refreshed (0.0Hz); on Messages I see always:
[MAV 001:1] EKF2 IMU0 has stopped aiding
[MAV 001:1] EKF2 IMU0 is using optical flow
In a little indoor test flight in FLOWHOLD the quadcopter is quite stable with little jump in altitude, in ALTHLOD I don’t have those little jump.

dataflash log

1 Like

@rmackay9 sorry if I repeat myself but I would like to know if is normal that I see all 0 on Status and Mavlink Inspector on GCS and the messages
[MAV 001:1] EKF2 IMU0 has stopped aiding
[MAV 001:1] EKF2 IMU0 is using optical flow
continuously repeating.

The same for the jumps in altitude in FLOWHOLD visible in dataflash log attached above, are they normal?
If I set FLOW_ENABLE = 0 and fly in ALTHOLD I don’t see those jumps. Do the optical flow in some way influence the altitude estimation?