Pixhawk 6c - Issue Tracking

[ryanjAA]

This is a Pixhawk 6c Issue Tracker

Tested on various versions of Main

• The i2c port doesn't pickup any devices (when running i2cdetect). This is because it is setup as the internal i2c port, meaning starting XXXXXX -X start doesn't work. Starting as internal -I does. Tested the internal start with ms4525do -I start and lightware_laser_i2c -I start. Also, I plugged the same external hardware into a Pixhawk 4 and the devices show up so it is not i2c hardware, cabling, etc. - Note: The gps i2c port is working

Could mark this i2c port as external ( https://github.com/PX4/PX4-Autopilot/blob/main/boards/px4/fmu-v6c/src/i2c.cpp#L39 thanks @vincentpoont2 ) but I don’t think keeping it as internal is ideal since a startup script needs to be added manually for each sensor or each sensor driver amended.

Reason why it is marked as internal was pin limitations on the MCU. I2C port is connected with the internal IMU, I2C1---GPS1, I2C2---GPS2, I2C4---internal IMU. (Thanks @vincentpoont2).

--- Almost fixed with https://github.com/PX4/PX4-Autopilot/pull/19949 this makes devices show up when enabled via their respective drivers but currently is breaking airspeed use (not calibration, just use - no airspeed shows up and hardware tested against main and works).

• Getting a "Manual Control Unavailable" message even though I have RC input working (over SBUS).

• Not getting RC RSSI (stuck at ~40%)

~~• FMU and IO are printed incorrectly on the cases (they are backwards). At first I thought it was at the software level that everything is reversed but IO should be aux and FMU should be main. They are currently backwards. This should be looked at a little more (and on the schematic) but labeling swap makes the most sense.~~

I’m wrong on this one. It’s correct. Main on this board is where aux is on pixhawk 4.

~~Other issues like incorrect disarmed value spooling up the motor, etc I will omit for the time being as it most likely is related to the Main and AUX reversal.~~

Lastly, this PR doesn't boot. https://github.com/PX4/PX4-Autopilot/pull/19871/

[memoryunreal]

I tried this method (https://github.com/PX4/PX4-Autopilot/blob/main/boards/px4/fmu-v6c/src/i2c.cpp#L39 thanks @vincentpoont2 ) to set as external, but the px4flow (plug-in i2c) still cannot work. Also the start -I instead of start -X has been tried. Optical flow / px4flow cannot show in the sensor status (qgroundcontrol). Is there any solution to use px4flow on the pixhawk6c? Thanks!

[ecmnet]

MS5611 not started at boot. Need to start it via MS5611 start -X. This might be related to the latest change regarding I2C. @davids5

https://github.com/PX4/PX4-Autopilot/pull/19949

[ecmnet]

Telem1-3 not working: https://github.com/PX4/PX4-Autopilot/issues/20118

[ryanjAA]

it looks to me that external i2c may at the board level be shared with internal for some components. Will take a look on this since that is where the confusion starts.

Possibly on this board we have to autostart internal and external for everything (when enabling) so it can figure out where things are by not figuring it out.

[julianoes]

Regarding the I2C bus, this is coming up: https://github.com/PX4/PX4-Autopilot/pull/20200. It should enable external devices while still having internal baro and mag working, and marked as internal during calibration and in sensors_status_mag and sensors_status_baro.

If someone can test an external device with this PR, that would be great!

[julianoes]

@ryanjAA what sort of SBUS receiver are you using to test SBUS? I think I have a FrSky SBUS one that I could test next week.

[ryanjAA]

I was using a Dragonlink and x8r. The DL can be set to ppm and sbus as needed.

[ryanjAA]

Regarding the I2C bus, this is coming up: #20200. It should enable external devices while still having internal baro and mag working, and marked as internal during calibration and in sensors_status_mag and sensors_status_baro.

If someone can test an external device with this PR, that would be great!

Will test this.

[julianoes]

Ok, I can reproduce the SBUS issue using FrSky X4R. PPM works but SBUS does not on that pin. I haven't tried RSSI.

[ryanjAA]

OK - the x4r puts out CPPM (I had to look) but I had SBUS working from an X8R which is sbus - not RSSI though. Did you have it set to auto or manually in the params (that's a relatively new thing, used to only be auto).

Also, do you by chance have an X4RSB (see below)? I'll get a ppm unit plugged in as well and see.

[julianoes]

Nevermind, my FrSky works with SBUS! I just had to use the correct pin, silly me!

[julianoes]

I just checked RSSI, and I can see it show up and change correctly looking at listener px4io_status.

[julianoes]

@ryanjAA I would argue with that data, and #20200 merged we should be able to close this soon.

[ryanjAA]

This is good news. Far from where we started not long ago :)

Agreed.

[tubeme]

I can confirm there is problem with using I2C and SBUS RC in at the same time.

I tried the old X6R FrSky and the new TD R10 as well it is consistent.

Everything works perfectly, until I attach the Airspeed 5525 to the I2C, then the SBUS IN stops working

Any Ideas?

[ryanjAA]

Ok. That’s a strange one. I don’t have a 5525. 4525 I can test.

Maybe it is power related? I say that because I’ve seen several logs that show low avionics voltage sometimes on the 6c.

[ryanjAA]

Here’s one where the baro drops to -2000m

https://review.px4.io/plot_app?log=75c51333-d471-46d5-a183-0c81e0e65657

[ryanjAA]

Then a new power module and no warning and then another flight and the power warning again. Here:

https://review.px4.io/plot_app?log=8c350207-d52c-45a3-9f55-6da9522c4be1

[ryanjAA]

I think it might be helpful if we could get someone to post they’re having consistent successful flights with them.

@julianoes are you flying with yours?

[vincentpoont2]

Here’s one where the baro drops to -2000m

https://review.px4.io/plot_app?log=75c51333-d471-46d5-a183-0c81e0e65657

@julianoes Can you take a look at this?

[julianoes]

Definitely looks like one bad sample was read and logged. Not sure if this was incorrect by the

I can also see that the error count reported by sensor_baro.error_count is quite high which doesn't seem quite normal.

@ryanjAA did you have any other devices connected to the external I2C on this vehicle?

It could be that it was just a bit which was misread from the wire, maybe due to electrical disturbance. It could also be a bug in software though, I need to check

I looked into the driver of the ms5611 and while it has a CRC check for the PROM coefficients, it doesn't seem to have a CRC check for the pressure and temperature, so there is not much we can do against that sort of invalid data. I suppose we could try to ignore measurements that are clearly out of range but it won't get rid of all outliers necessarily as you could have spikes that are not "as bad". Anyway, it looks like the EKF didn't explode because of it, right?

I can try to reproduce this next week and I'll also look into the reported "comm errors".

If it is because of another device (or wiring) connected to the external one then we know that this problem should disappear with the next hardware revision which doesn't expose the I2C of the baro and mag to external connectors/sensors.

[ryanjAA]

Thanks @julianoes - there would be an airspeed (ms4525) and compass (in the holybro gps) on i2c. Slightly concerning was the low voltage issue as well.

It's an aircraft that has been flown many many times so seeing a disturbance is something I would have expected before as well which isn't the case.

Correct that EKF didn't go nuts and handled it correctly, the concern was why and what happens if it happens more (aka would EKF not be happy eventually). In some of the logs it is totally fine, so that is not great either. It isn't consistent.

[julianoes]

@ryanjAA so the airspeed was connected to the external I2C but the compass presumably wasn't as it is connected to the GPS connector. And how long is the wire to the airspeed? And does it cross other electronics or even power electronics?

In some of the logs it is totally fine, so that is not great either. It isn't consistent.

It looks like it just happens very infrequent, right?

[vincentpoont2]

I can confirm there is problem with using I2C and SBUS RC in at the same time.

I tried the old X6R FrSky and the new TD R10 as well it is consistent.

Everything works perfectly, until I attach the Airspeed 5525 to the I2C, then the SBUS IN stops working

Any Ideas?

I can't reproduce this issue using Pixhawk 6C & 1.13.1 stable. I connect the MS4525 airspeed meter through I2C, choose the standard Plane airframe, and the airspeed meter can be calibrated. At the same time, the X4RS sbus receiver of FRSKY is connected. When the joystick is moved, the QGC page will show that it will move with it.

How can I reproduce your issue? Are you using 1.13.1 stable?

[ryanjAA]

Richard will post some info on the setup.

[autonomical]

Hi everyone. I'm a general RC fixed wing nitro/electric aeromodeller with a keen amateur interest in FC. My fixed wing FC set up is as follows - plane is Volantex Raptor/Ranger 2m wingspan pusher prop glider. FC is 6C with M8N compass/GPS, Holybro I2C airspeed sensor, PM07v2.3 power board, 60ampESC with 5A BEC for PM07 PWM power rail. I use 4S LiPos. Tx is RadiomasterTX16S running EdgeTx, Rx is SBUS Turnigy iA6c. PX4 firmware is a Master release from about 3 weeks ago and a QGC daily (Windows) from around same time.

I was getting baro and low voltage errors but they seem to have decreased since changing from PM07V2.2 to PM07V2.3 and upgrading BEC to 5A...updating Master firmware might also have helped. My hardware setup might also be implicated however - the M8N compass/GPS unit is plugged into GPS1 on 6C. The airspeed I2C lead is 15cm long and runs from airspeed sensor board to I2C socket on 6C. The airspeed lead is fed through a hole in top of fuselage (see photo link) together with PM07 power lead to 6C and a lead connecting I/O PWM out on 6C and FMU PWN In on PM07...those three wires are pretty squashed together through that hole. When airspeed sensor board is inside fuselage during flight it is close to top of PM07 board.

Last flight I was able to autotune during a 5-10 minute stabilised/hold which was progress. Hold circle was very accurate and stable.

Another issue I am grappling with is aileron trims 'jumping' to a non-level roll position when I switch on Tx from manual to stabilised mode...I am about to adjust servo linkages to level ailerons in stabilised mode and then switch to manual mode and trim as much as necessary then do a 'copy trims to subtrims' on my Tx to recover trim centers as it were..Ryan is also going to look at params file for me - aileron issue short movie here http://www.richardjcox.org/temp/IMG_8043.MOV

[DronecodeBot]

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/pixhawk-6c-flight-tests/28977/1

[ryanjAA]

All confirmed working.