2. Rewrite and rebase pca9685 driver
3. Try to fix issue when push the stick of channel 3 to the maxmum position, 0uswill be output to channel 1, should be maxmum pwm signal
4. Fix the code style
Both 8 channels PPM encoder and 8 channels revicer are required.
Before launch px4, ppmdeocde programe should be launched.
To download ppmdecode programe,
visit https://github.com/crossa/raspberry-pi-px4firmware.
Pxfmini and navio are not popular autopilot hardware in china,
I can handly to purchase it.
So that I use raspberry pi to build autopilot separately.
This dirver help us to decode ppm single to pwm and pushlish it
This change first pushes out the _reset_wait by 100 Ms.
which is about 3 time longer then the code take to execute.
Then it does the reset of the accel, gyro and mag and
the ends the wait by setting _reset_wait to now+10 us.
The MPU9250 and MPU6500 buth support 1 Mhz and 20 Mhz. Buy upping the clocc we will get the maximum clock rate the driver
supports that is <= 20 Mhz. This will boost the FMUv4Pro SPI speed to 11.25 Mhz (it was half that)
Insure a 0.0 voltage initial condition on VDD_3V3_SENSORS
By starting the GPIO_VDD_3V3_SENSORS_EN, low and deferring
the GPIO init of the slave selects and drdy signals until
board_app_initialize. We get ~ 180 ms of power off time
with 0.00 voltage applied to the sensors.
This commit fixed a bug were the mag was orphened on a reset.
That resulted in MAG timeouts on reset or test operations and
left the mag in a broken state.
We want to setup the mag interface with retries and report
failurs.
Move retry logic to contol point, instead of hiding re-reading
the ID in ak8963_check_id.
Allow it to fail once to overcome a read of 0 on firt read.
after 2 failure report error to console and reset the
mpu9250's I2C master (SPI to I2C bridge)
The same retry logic is used on the ak8963_read_adjustments
with a reset of the I2C master module after 5 fails. If it
fails fter 10 retires. Disabel the mad and report the failure
on the console, stating it is disabled.
On initialization, if after 3 retries to re-init the mpu9250 from
the checked registers values, it fails. Ensure thath the fact the
driver is exitting is logged to console.
Check that the mpu9250's configured registers match the settings
written to them. Attempt to fix any that do not up to 3 times.
printing erros to the console on mismatches and returning
faliure if after 3 attempts the any of the values are
still wrong.
Given the original poster's comment that "It happens very consistently for us." I suspect the motor spin observed in https://github.com/PX4/Firmware/issues/7457 is not caused by the original issue of slow decay on the PWM pins at reset, but the post reset pulse of 3.1 Ms arriving in a window that the ESC considers it valid.
The results from testing, indicated that the if the PWM pins were clamped low for > 300 Ms, prior to reset the motors did not spin. This would delay the the post reset pulse of 3.1 Ms out by > 300 Ms.
This change delays the reset and therefore the pulse by at least 400 Ms.
problem: previously when connecting power to Power 1, commander refused
to arm (no power source error), and when connecting to Power 2, arming
works, but power consumption was not measured (& shown in QGC).
Swapping Brick1 with Brick2 makes sure both works when connecting to
power 1.
Ideally we will have support for both power sources (including fail-over)
crossa