dark0707
/
px4-firmware
forked from Archive/PX4-Autopilot
1
0
Fork 0
Code Pull Requests Activity
px4-firmware/msg/SystemPower.msg

22 lines
851 B
Plaintext
Raw Normal View History

add timestamp field to uORB msgs; sync timestamp whenever possible
2018-08-06 21:30:05 -03:00
uint64 timestamp # time since system start (microseconds)
update msgs fields from camelCase to snake_case so rosidl_generate_interfaces() is able to generate code for ROS IDL files
2018-07-29 17:28:59 -03:00
float32 voltage5v_v # peripheral 5V rail voltage
adc: add support for multiple sensor voltage channels
2020-10-29 07:07:07 -03:00
float32[4] sensors3v3 # Sensors 3V3 rail voltage
uint8 sensors3v3_valid # Sensors 3V3 rail voltage was read (bitfield).
uORB: Moved subsystem_info to generated topics
2015-05-27 02:47:08 -03:00
uint8 usb_connected # USB is connected when 1
Added FMUv5 System Power related system_power.msg fields 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
2017-06-29 19:22:22 -03:00
uint8 brick_valid # brick bits power is good when bit 1
Fixed typo usb_vaild -> usb_valid
2017-09-29 16:21:13 -03:00
uint8 usb_valid # USB is valid when 1
uORB: Moved subsystem_info to generated topics
2015-05-27 02:47:08 -03:00
uint8 servo_valid # servo power is good when 1
update msgs fields from camelCase to snake_case so rosidl_generate_interfaces() is able to generate code for ROS IDL files
2018-07-29 17:28:59 -03:00
uint8 periph_5v_oc # peripheral overcurrent when 1
Clarification of coordinate systems for sensors_* and vehicle_* messages (#16339) Changed all 'NED' references to 'FRD'. Also cleaned up mixing of m/s/s and m/s^2 to use the latter. Corrected m/s/s to Pascals. Plus minor typos. Also made some minor cosmetic clean ups. Co-authored-by: Robin <robin@Robins-MacBook-Pro-Work.local> Co-authored-by: Mathieu Bresciani <brescianimathieu@gmail.com>
2020-12-15 04:18:05 -04:00
uint8 hipower_5v_oc # high power peripheral overcurrent when 1
system_power: add comp_5v_valid and can1_gps1_5v_valid And fill it in from the v5x GPIO expander.
2021-01-14 08:59:43 -04:00
uint8 comp_5v_valid # 5V to companion valid
uint8 can1_gps1_5v_valid # 5V for CAN1/GPS1 valid
Added FMUv5 System Power related system_power.msg fields 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
2017-06-29 19:22:22 -03:00
uint8 BRICK1_VALID_SHIFTS=0
uint8 BRICK1_VALID_MASK=1
uint8 BRICK2_VALID_SHIFTS=1
uint8 BRICK2_VALID_MASK=2
uint8 BRICK3_VALID_SHIFTS=2
uint8 BRICK3_VALID_MASK=4
uint8 BRICK4_VALID_SHIFTS=3
system_power:Add blank line per review
2017-07-10 14:14:00 -03:00
uint8 BRICK4_VALID_MASK=8