I’m fighting an uphill battle with Navio2 (RPi) and Ubuntu 20.
Unable to calibrate Radio (an SBUS receiver) in PX4 1.10.1. The receiver is plugged into PPMSB and is paired with the transmitter. cat /sys/kernel/rcio/status/alive shows 1 and cat /sys/kernel/rcio/rcin/ch1 and cat /sys/kernel/rcio/rcin/ch2 do show changing values as I move the controller sticks, so the hardware connection and the SPI driver check out.
However, QGC reports “Detected 0 radio channels. To operate PX4, you need at least 5 channels.” when I attempt to calibrate the RC.
What could be the issue here? How can I troubleshoot this further to validate/fix the link between /sys and PX4?
Now I’m getting a pre-flight check issue with Battery settings:
Parameters are missing from firmware. You may be running a version of firmware QGC does not work correctly with or your firmware has a bug in it. Missing params: 1:BAT_V_CHARGED, 1:BAT_V_LOAD_DROP, 1:BAT_N_CELLS, 1:BAT_V_EMPTY
The usual suggestion of resetting firmware settings and reloading did not help. Judging from the code it looks like this may be due to the fact that Navio2 does not contain PX4IO (obviously) so src/lib/battery/battery.h, src/lib/battery/battery_params.c or equivalent may not be included.
How is this intended to resolve in general on such FMU-only platforms? How do I fix this?
So I’ve silenced the Battery settings issue by explicitly adding the following lines to posix-configs/rpi/px4.config:
param set BAT_N_CELLS 4
param set BAT_V_CHARGED 4.15
param set BAT_V_EMPTY 3.65
param set BAT_V_LOAD_DROP 0.30
Can one of the PX4 developers familiar with the PX4 + Navio2 code @bkueng@JulianOes comment whether this workaround is expected in Navio2’s case? That board provides a power supply module similar to Pixhawk’s so I half expected the power supply (“battery”) code/config for Navio2 to be orchestrated similarly. I understand the Emlid product is treated here as an experimental platform but it’s rather unclear why these smaller but nonetheless showstopping pieces are missing once a release PX4 is built. The coexistence of boards/emlid/navio2 and boards/px4/raspberrypi doesn’t help an outsider’s confusion (for Ubuntu 20 I built the latter) either.
Before this, getting the Navio2 hardware to work on Ubuntu 20 (mainly the SPI overlays) was the bigger hurdle, as I’ve described here.
Having said all this I’m grateful that you guys support the Navio2 product. I’m looking forward to flying this thing on PX4+Ubuntu 20 and building up from there.
I’d be happy to create a PR for the BAT_ parameters if it’s confirmed that the patch above is indeed the expected and currently missing piece.
The battery parameters got updated BAT_N_CELLS -> BAT1_N_CELLS. The old parameter should still be accessed though.
Do you have a battery estimation? -> listener battery_status
What’s the output of these:
I started this a few weeks ago when stable was still pointed to 1.10.1, so to minimize thrashing I’ll continue with this version until I get this airborne and then I can try upgrading.
Those were the params that QGC complained about, I’m assuming versioning is taken care of behind the scenes?
Adding those BAT_ params plus SDLOG_MODE cleared the QGC warnings.
Thanks @bkueng for the pointers. Took me a second to figure out how to run commands on this platform, having come from Pixhawk and nsh. Turned out battery_status start was not in px4*.config . After I had added that I began receiving BATTERY_STATUS mavlink messages and battery indicator in QGC. navio_adc was already in the configs.
I can now arm the copter, but the motors just beep meekly and randomly (different than the power up chime). Sounds like a PWM out issue, hopefully this is the last hurdle
The actuator_output values were -1 throughout the log when viewed in pyFlightAnalysis. I adjusted PWM_MIN and PWM_MAX to the values that are known to work in fmu-v5 on a similar airframe and the motors spun for half a second after arming, but then they stopped, and the copter disarmed. The log still contains -1 for relevant actuator values, I’ll chalk that up to an instrumentation error.
Only PWM_DISARMED, PWM_MAX and PWM_MIN are set and present in the firmware after build. I suspect some other necessary PWM_ param values are needed for pwm_out and the copter to work reliably @bkueng ? What else is required?
Also, why the duplication boards/px4/raspberrypi and boards/emlid/navio2? I understand the desire to match you’ve done with boards/holybro/pix32v5 and boards/holybro/durandal-v1, but those holybros are manufacturer supported boards, and emlid continues to oppose and divert from PX4, so I think you should pick and flaunt boards/px4/raspberrypi.
Or perhaps utilize some form of “contains” hierarchy to reduce duplication if you want two entry points to what essentially looks like an identical build.
I tried v1.11, both boards/emlid/navio2 and boards/px4/raspberrypi (with mods). With the same hardware setup and underlying Ubuntu 20, v1.11 is more unstable than v1.10.1. Here’s a list of issues that I saw:
Preflight keeps failing with Fail: Gyros inconsistent - Check Cal. Re-calibrating doesn’t solve it, the issue comes back again later. There were a bunch of timeouts for sensors throughout - nothing like that happens with 1.10.1. That’s a clear blocker.
The battery indicator incorrectly shows 100%
The RC indicator in QGC does not light up
Same exact issue with pwm_out and motors as 1.10.1 above, they spin immediately after arming and stop after 1/2 second. Perhaps that means it’s a config issue and not a code issue.
A lot of small (debug) crud in the log and QGC warning flashes
I’ve opened PX4/Firmware issues for the 1.11.0 bugs above.
That’s intriguing, could you provide more detail on the intentional differences? Are you saying that one of the reasons is that boards/emlid is intended for building on Raspberry Pi OS and boards/px4 for other Linux distros like Ubuntu?
From my monologue above at least one action item is needed, regardless if it’s 1.11.0 or 1.10.1: boards/px4/raspberrypi needs the RC, ADC and LED code copied over from boards/emlid/navio2, let me know if you concur.
Here’s the log for the motor spin immediately after arm and disarm 1/2 second later: https://logs.px4.io/plot_app?log=0fdb1c03-47f2-4e9e-b5e4-670ccf63661e Definitely more neurotic behavior from the navio2 version than fmu-v5 if it’s indeed failsafe kicking in - I’d say it should not go all the way to the motors if it’s a condition that is detectable beforehand.
Yes it’s the drivers (e.g. navio_sysfs_rc_in vs rpi_rc_in) and bus configurations (I2C, SPI), that is specific to navio2, whereas px4/raspberrypi is more generic. I’m sure all of this could be done a bit nicer.
Looks like something is wrong with the outputs indeed, either driver or configuration. I’d have a closer look at what the driver is writing.
Ok. I think at the beginning I had started building boards/emlid/navio2 and ran into some issues, so I switched to boards/px4/rasppberrypi and that worked better. This leads me to believe that they are close to being identical, sans the changes above, at least in 1.10.1 . If I have time, I may go back and try building the former to see how well it works for the intended navio2 platform.
Pretty solid “feeler” test flight. The log file might be corrupt because it was still being written after landing and at the time of power disconnect - maybe the timed post-landing auto disarm didn’t kick in because of a missing default param.
