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.
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?
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…
1 Like
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.
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.
1 Like
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.
1 Like
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.
@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)?
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
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.
1 Like
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.
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.