600 class quad with AUAV-X2 (and baro static port) running INAV on 1.4.1rc4: http://logs.uaventure.com/view/AmKfSBm8WYM9PVQYH7GugN
ALTCTL was solid, no glitches observed
POSCTL and RTL worked well also
Iāve just pushed another update to the beta branch which improves the LPE performance. More flight testing with LPE would be appreciated.
The last open issue we have are better defaults for position control gains.
Hello,
Today when I try to load beta firmware in QGC 3.0 to my Pixhawk the upload goes well but after reboot I have the red led blink and QGC said āYour vehicle is not responding.[ā¦]ā.
āMasterā firmware do the same.
ānuttx-px4fmu-v2-default.px4ā from the 1.4.1rc4 zip has same problem.
But when I load the stable firmware by the same way it works.
Does I miss something ?
I have formated my sdcard in Fat16.
No issue here at all with upgrading an existing system. What sort of peripherals do you have connected?
The official release is now available:
We are targeting a 1.4.2 release with a number of minor improvements for all things that are proposed PRs but were not flight tested yet.
Congratulation for 1.4.1 release !
I have leaved only GPS + power module + Telemetry + buzzer + safety switch. I2C and telem2 disconnected.
Upload of 1.4.1 bring to rapid flashing red and no connection with QGC 3.0.
Upload of 1.3.4, via GQC, work, after px4 reboot QGC ask for calibrating sensor.
OK, I have connected the serial console and here is what is happening:
sercon: Registering CDC/ACM serial driver
sercon: Successfully registered the CDC/ACM serial driver
WARN [param] selected parameter default file /fs/mtd_params
rgbled on I2C bus 2 at 0x55 (bus: 100 KHz, max: 100 KHz)
WARN [px4io] CRCs match
INFO [dataman] Power on restart, data manager file ā/fs/microsd/datamanā size is 103090 bytes
MS5611_SPI on SPI bus 1 at 3 (20000 KHz)
WARN [bst] no devices found
INFO [ver] match: PX4FMU_V2
WARN [hmc5883] no device on bus 2
read_reg failWARN [lis3mdl] no device on bus 2
WARN [hmc5883] no device on bus 1
ERROR [mpu6000] no device on this bus
MPU6000 on SPI bus 1 at 4 (1000 KHz)
L3GD20 on SPI bus 1 at 1 (11000 KHz)
LSM303D on SPI bus 1 at 2 (11000 KHz)
ERROR [meas_airspeed] no MS4525 airspeed sensor connected
ERROR [ets_airspeed] no ETS airspeed sensor connected
ERROR [ets_airspeed] no ETS airspeed sensor connected
nsh: sf1xx: command not found
INFO [px4io] default PWM output device
INFO [mavlink] mode: Normal, data rate: 1200 B/s on /dev/ttyS1 @ 57600B
INFO [mavlink] mode: OSD, data rate: 1000 B/s on /dev/ttyS2 @ 57600B
INFO [ver] match: PX4FMU_V2
px4flow [172:100]
WARN [px4flow] scanning I2C buses for deviceā¦
INFO [mavlink] mode: Config, data rate: 800000 B/s on /dev/ttyACM0 @ 57600B
INFO [init] Mixer: /etc/mixers/IO_pass.main.mix on /dev/pwm_output0
> nsh: ekf_att_pos_estimator: command not found
NuttShell (NSH)
nsh> WARN [commander] Not ready to fly: Sensors not set up correctly
I assume you use a FMUv2 Type FC. I had the very same Issue with an AUAV-X2 on 1.3.x Firmware when you choose EKF you need a Build that includes EKF. Connect to the Console and set the Parameter SYS_MC_EST_GROUP back to 0. This should let your FC startup completely.
@Andreas_Hoffmann Good thinking, in this case its the EKF1 which is missing. Today all three options (INAV, LPE, EKF2) are present in the same binary.
Are you using the rover config? That was the only location where that filter was still present anywhere. I just fixed that on stable. Please feel free to flash via QGC again. Iāve not cut a new release since it will not affect a lot of people.
Yes I have once selected Rover to be sure to clean parameters, like we do with Arducopter. Not a good idea for PX4 
How to be sure to clean the Pixhawk ? Loading Arducopter then PX4 ?
@Benoit_C if you really want to reset all parameters to defaults then in QGC go to parameters and under tools youāll see an option to reset all to default. Then select your airframe/rover and restart.
1 Like
Ahah, sometimes itās too easy to imagine. Thank you, now the upgrade work.
Just tried to upload the running firmware-version, but I get the reply:
Firmware not suitable for this board (board_type=9, board_id=11)
Found board 9,0 bootloader rev 4 on 7devserial/by-id/usb-3D_Robotics_PX4_BL_FMU_v2.x-if00
What does this mean?
=> I have used the wrong version for compilation
Wrong: px4fmu-v4_default
Right: px4fmu_v2_default
Sorry @LorenzMeier, I didnāt see this thread. I found a problem while testing the firmware, and turned it into a seperate thread: Huge Accelerometer errors with new firmware
The px4fmu_v2_default is allready running on by board.
The sensors are calibrated, the RC is calibrated.
Now I want to start, but I am not able to arm the pixhawk.
6 Satellites are found
The position is shown in my HoTT Mx-16 ( GPS and HTT-Telemetry works)
I got two beeps pressing the armed button once, tree beeps (da, dit, dit), pressing it the second time - is there a listing for the meaning of theese beeps?
I got the message āReject altitude controlā in QGC - What does it mean?
So
@LorenzMeier Iāve had a test flight today with stable branch (EKF2 estimator) and found some strange issues:
- Yaw oscillations in flight logs.
- High vibration on Z axis in flight logs.
But i havenāt seen them in flight.
logs:
http://logs.uaventure.com/view/KJ5YJ4vUVHmPbUrraakSmL
flight video:
Copter config: pixhawk, 6x, 2.3kg takeoff weight
Thanks! The yaw oscillation is not an oscillation, it is the wrap around PI. You were flying the north-south direction, where this is expected.
The vibration on the other hand is real. We are just filtering the plotted value less.
So I would say your flight looks good.
This is the first flight of a small quad with Pixracer and PX4 v1.4.1
The log is here:
http://logs.uaventure.com/view/mi8QcXZAVXiyzcVKaUApWm
Everything is with default settings and there was a lot of wind
Does this mean that the yaw behaves different if you flight north-south instead of north-east?
No it only means that the logged yaw will āoscillateā between plus/minus pi since your zero reference is north. So a rotation of e.g only two degrees around south direction will show up in the logs as a rotation from +179 deg to -179 deg.
Thanks Carl. That makes more sense now.