yemai/bizhang_-obav
1
0
Fork 0
mirror of https://gitee.com/xiaohuolufeihua/bizhang_-obav.git synced 2026-05-21 09:22:18 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
e2337a34eb1bb59e4befc1e197cb8a7359e35041
bizhang_-obav/msg/system_power.msg

22 lines
831 B
Plaintext
Raw Normal View History

add timestamp field to uORB msgs; sync timestamp whenever possible
2018-08-07 01:30:05 +01: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 21:28:59 +01: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 12:22:22 -10:00
uint8 v3v3_valid # Sensor 3V3 rail voltage was read.
uORB: Moved subsystem_info to generated topics
2015-05-26 22:47:08 -07: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 12:22:22 -10:00
uint8 brick_valid # brick bits power is good when bit 1
Fixed typo usb_vaild -> usb_valid
2017-09-29 09:21:13 -10:00
uint8 usb_valid # USB is valid when 1
uORB: Moved subsystem_info to generated topics
2015-05-26 22:47:08 -07: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 21:28:59 +01: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 09:18:05 +01: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 13:59:43 +01: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 12:22:22 -10: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 07:14:00 -10:00
uint8 BRICK4_VALID_MASK=8
Reference in New Issue Copy Permalink