fmu-v5: Updated board config to RC01 of FMUv5 Spec #7219
Conversation
|
@davids5 I have a couple of questions:
|
|
@simonegu Answers are inlined above |
|
@davids5 a couple of questions:
Do we simply forget the
How should they get configured? As a standard input
Should it be configured as a standard output? |
|
@simonegu - Just to close the loop. Please refer to the FMUv5 Pinchart
See Tab "RC00 to RC01" for the changes
See "All pinouts" for the signal type and usage.
(GPIO_OUTPUT|GPIO_PUSHPULL|GPIO_SPEED_50MHz|GPIO_OUTPUT_CLEAR|PORTH|PIN15) |
simonegu
force-pushed
the
fmuv5_update_board_config
branch
2 times, most recently
from
9bb6c6c to
e7d7f32
Compare
simonegu
force-pushed
the
fmuv5_update_board_config
branch
2 times, most recently
from
bad6719 to
04627b7
Compare
davids5
force-pushed
the
fmuv5_update_board_config
branch
from
04627b7 to
f956fea
Compare
|
rebased on master f82e85f |
davids5
force-pushed
the
fmuv5_update_board_config
branch
2 times, most recently
from
ca3ae61 to
878817c
Compare
|
SD CARD:There were a series of cascading failures. The newly added SPI5 failed to init, so it skipped the SD CARD Init. Once that was fixed, the root cause was not not turning on the SD Card Power. The polarity changed on test hw to match spec (active high). master had active low and worked by default. It never invoked the SD_CARD_POWER_CTRL(true) |
davids5
force-pushed
the
fmuv5_update_board_config
branch
from
878817c to
62085f9
Compare
|
@dagar - would you please have a look at commits: 083979c..62085f9 once this comes into master we would want to continue the Power and Battery refactoring we discussed. (Adding per Brick params etc) @klopezal This implement:
|
davids5
changed the title
|
@PX4TestFlights - Please bench test on all variants of HW with different FMU versions and platforms. Please focus on battery indication. Testing Low voltage behaviour (QGC, Lights, sounds) is consistent with master. Use 1 and 2 bricks on FMUv4Pro. With 1 Brick try it plugged into both power 1 and 2. |
| ctrl.control[actuator_controls_s::INDEX_THROTTLE], | ||
| _armed, &_battery_status[b]); | ||
| int instance; | ||
| orb_publish_auto(ORB_ID(battery_status), &_battery_pub[b], &_battery_status[b], &instance, ORB_PRIO_DEFAULT); |
There was a problem hiding this comment.
This will publish to multiple instances. Will there be a common place for voting, so that e.g. commander always uses the selected one? Or will it need to subscribe to all instances?
There was a problem hiding this comment.
See 88ead15 for how it works. It is a interim bridge.
There was a problem hiding this comment.
Ah, I should have looked at it more closely, thanks!
|
@simonegu - first post has been updated. |
| orb_publish_auto(ORB_ID(battery_status), &_battery_pub, &_battery_status, &instance, ORB_PRIO_DEFAULT); | ||
| /* Consider the brick connected if there is a voltage */ | ||
|
|
||
| bool connected = bat_voltage_v[b] > 1.5f; |
There was a problem hiding this comment.
Do we actually need connected? What if it just wasn't published if not connected?
There was a problem hiding this comment.
I think that's a great fundamental question for most hardware in the system. FMUv5 establishes the notion of being able to determine if a piece of hardware is expected to be in the system.
a) is present in functioning correctly.
b) expected to be there but is not.
battery(ies) can be connected to the system and Vbat >= Vconnected (SW) and Vbat < Vvalid (HW). This allows us to log that fact. I would like to have a param per/brick for Vconnected
But you tell me if it make sense.
|
couple flights running on pixracer (V4) proper firmware flash, led/buzzer activity |
|
indoor hover test on pixhawk mini (V3) calibrated voltage scaling; seconds after take-off, low battery warning kicked in despite battery being nearly full |
|
@santiago3dr - Do you have FMUV1 and FMUV4PRO, Snapdragon, and aerofc HW you can just check battery readings on? |
Since Hardware flow control has not been enabled this typo survived.
The LTC4417 provides a valid signal for USB. This change configures the GIOP and provides 1) True logic macro to read the pin and the IOCTL defines to read it from the FMU. The macro will return true when the signal is active (low on the LTC4417). The IOCTL will read be the actual pin state.
The V4 HW replaced the LTC4417 provided valid signal for USB. with an active high, version. This commit configures the GIOP and provides 1) a MACRO to read the pin and the IOCTL defines to read it from the FMU. The macro result true logic: true when the signal is high. The IOCTL read would be the actual pin state.
The LTC4417 provides a valid signals for brick1, brick 2 and USB This change configures the GIOP and provides 1) a MACRO to read the pin and 2) the IOCTL defines to read it from the FMU. The macro's result is true logic: It is true when the signal is active. (Active low on the the LTC4417). The IOCTL read would be the actual pin state.
As done on fmuV4 on resets invoked from system (not boot) insure we establish a low output state (discharge the pins) on PWM pins before they become inputs as a result of the pending reset. We also delay the reset by 400 MS to insure the 3.1 Ms pulse is not too close to the last PWM pulse.
Added comments to ADC defines with Pin numbers.
Added the GPIO_HW_{REV:VER}_DRIVE signals
Define the GPIO_nPOWER_IN_{A:C] and assign them to
BRICK1, BRICK2 and USB Valid.
Regroupped power signals and defined true logic Power Control macros
in the arch agnostic form.
Defined the same IOCTL defines for FMU GPIO IOCTL
Use the power Control macros on board_app_initialize
Dispite what the ref manaul says. Some HW needs the added pull down to insure the pin reads low when not plugged in to USB.
The PX4IO is an population option on some varients. To have 1) FMU only control 2) IO Only control 3) FMU fall back control These pins need to come up as inputs, until the configuration is determined.
system_source - This battery status is for the brick that is
supplying VDD_5V_IN
priority - Zero based, This battery status is for the brick
that is connected to the Power controller's
N-1 priority input. V1..VN. 0 would normally be
Brick1, 1 for Brick2 etc
Battery now assigns connected from the api in the
updateBatteryStatus, as well as system_source and priority
FMUv4Pro and FMUv5 Spec added multi brick support FMUv5 added SCALED_VDD_3V3_SENSORS This change provides legacy (FMUv2) defaults for Power Bricks and Sensor rail volatage source.
This change implements the publishing of batery_status messages for each brick on the system, using multi-pub. Backward compatiblity is achived by always publishing the batery_status of the bick that has been selected by the HW Power Controller (PC) on instance 0. The batery_status.system_source will be true in one and only one batery_status publication when a valid bit is set in system_power.brick_valid. However, if USB is connected, and both brikcs are not providing voltages to the PC that are in the Under/Over Voltage Window (set in HW) the system_source may be false in all publications.
voltage3V3_v - the sensor 3.3V voltage rail
v3v3_valid - the value of voltage3V3_v may be 0. This
field is a 1 when the HW provides voltage3V3_v
brick_valid - is now a bit mask. A 1 in the postion inticate the
Power controler HW has a valid supply voltage
present (in V window) on that priority
(channel V1..Vn).
The mapping is formed by 1<<battery_status.msg.priority
or using the manifest constanst BRICKn_VALID_MASK
usb_vaild - is now indicated from the Power controler HW or
the usb_connected if Power controler is
not present.
brick_valid == 0 and usb_vaild = 1 implies the FMU is powered
from USB only
brick_valid != 0 and usb_vaild = 1 implies the FMU is powered
from the higest priority brick, providing a 1 bit in brick_valid
and from USB
Removed unused headers and placed the __BEGIN_DECLS where it belonged
BOARD_HAS_LTC44XX_VALIDS - 0 -> No LTC44xx IC, N is the number of
Power Bricks connected to the LTC44xx
For a LTC4417 this would be 2 as the
third prioriy is used for USB
BOARD_HAS_USB_VALID - If defied as 1 imples that infact
the USB has a priority connection
on the LTC44XX
BOARD_HAS_NBAT_V - the number of battery voltage sensing chennels
on the ADC
BOARD_HAS_NBAT_I - the number of battery current sensing chennels
on the ADC
A super simple (non FMUv5 compliant) board with no LTC44xx and just one battery
that have no current sense:
BOARD_HAS_LTC44XX_VALIDS = 0
BOARD_HAS_USB_VALID = 0
BOARD_HAS_NBAT_V = 1
BOARD_HAS_NBAT_0 = 0
A fully FMUv5 compliant design would use:
BOARD_HAS_LTC44XX_VALIDS = 2
BOARD_HAS_USB_VALID = 1
BOARD_HAS_NBAT_V = 2
BOARD_HAS_NBAT_0 = 2
These setting properly condition the ADC channles and all the Power
module valid sensing logic in the ADC module.
Both PX4Test and Beat noted if only Brick to was connected battery_status Intance 0 voltage was 0V for Brick2 The priority selection logic is run prior to the subscription creation and only updated the priority on a change. Before the subscriotions were created. _battery_pub_intance0ndx is suposed track the location in the _battery_pub array that is instance 0. It is then used to associate (move) instance 0 with (to) the lowest brick (highest priority in HW) brick that is selected in HW. The Bug was that before the subscriptions are created, _battery_pub_intance0ndx set to 1. And then and never updated. The fix was to only run the priority selection logic once the subscriptions are created.
davids5
force-pushed
the
fmuv5_update_board_config
branch
from
010a1a0 to
addae02
Compare
|
Done |
|
Jenkins test this please. |
|
@dagar looks like Jenkins became flaky recently. I will have an eye on it. |
N.B. HW that is not compatible with the FMUv5 RC01 specification: I.E HW at RC00 or test HW will no longer function when this is merged. FYI: @sirPerna
@davids5 I started updating the
board_config.hforfmu-v5, please have a look.@simonegu, this is ready, or should I say ready enough. There is more to do, but it is solid base line.
Thank you for doing the RC01 update!