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

20 lines
734 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
float32 voltage3v3_v # Sensor 3V3 rail voltage
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 v3v3_valid # Sensor 3V3 rail voltage was read.
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
uint8 hipower_5v_oc # hi power peripheral overcurrent 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 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