my little plan to sneak that into the build didn’t work unfortunately, so no point testing. It will need to be a compile time option, with a big caveat: this flow sensor needs to be the only device on the SPI bus (so if your FC has one SPI bus with multiple chip selects for the IMU and external, don’t use it as you’ll probably crash).
I’ll work on putting a hook into OpticalFlow.cpp so that if PIXARTFLOW_SPI is defined, it will build for it. I’ll need to add instructions to the wiki as well.
Cool Thanks @anbello ,
I will compare with my own test code tonight, and update here.
Thinking out loud for a moment; What about using an arrduino to emulate a PX4FLOW on I2C like a did for the TFMINI How to make the TFMINI rangefinder talk I2C? This way I am pretty sure that the EKF integration would be optimal…
With this type of board this is about the same footprint as the CX-OF
The driver still needs to call it. The Skyviper F412 implementation is representative.
The key thing is that we have no means to configure the spi bus at runtime, so which is why the hwdef needs changing.
arducopter.apj (845.8 KB)
This is an fmu-v3 build with the pixartflow enabled on external SPI. Testing welcome please. It will only work for Pixhawk (and probably the mRo X2.1?), but not Cube, because the extra IMU on the Cube consumes that SPI bus (which is why there isn’t an external SPI port on the Cube carrier). I don’t have an fmu-v4 but will build a firmware so others can test. It turns out Revo-mini has an SPI port too, if that’s of interest to anyone.
Remember that you need a rangefinder as well, not just the flow sensor.
I’m still trying to decide the best way to push this, as it isn’t really desirable to consume the external SPI with a specific device. For fmu-v5 there is another problem, as the exposed SPI shares a timer for DMA with pwm 5 & 6, so you lose two DShot outputs if you enable the SPI (which is why its disabled by default).
The end state of all that is that at the moment I think it makes sense to have the hooks in OpticalFlow.cpp so that if the hwdef.dat defines the pixartflow, it will build for it, but not change the hwdef files in master: at least not until/unless the external SPI assignments get parameterised.
This should work for Pixracer. Apart from adding in the defines for the device, SPI4 has been set up on the wifi port GPIO pins as below. The UART remains intact, so whilst the esp8266 that comes with the pixracer won’t fit if you have other cables in the connector, you could run a lead to it and it should still work. As above, I don’t have a pixracer, so this is untested.
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.
Hi James,
I wanted to ask… how to you read on write codes on the pixracer? Ive done the first two steps of your previous post.
And, i just wanted to say that I am very thankful for your time and help
It’s in the wiki, but once you’ve made the changes to the hwdef, from the top ArduPilot directory: “./waf configure —board fmuv4”, then “./waf copter —upload”, with the board connected on USB.
The dashes are double dashes (this forum doesn’t display them well).
Would uploading the .apj file above via missionplanner (load custom firmware) suffice? Or must I make changes. As i cannot open the .apj file, but i can click on the file via mission planner (load custom firmware)