tools: Add CircuitStatus and Hardpoint Panels

[makcuk]

Adds a new integration and debugging panel for smart PDUs. It allows sending DroneCAN hardpoint commands to toggle switched power rails and monitors real-time circuit status telemetry (voltage, current, power, and error states).

Example of operation

Tested against UglyDrone PDU-12S

[joshanne]

I have a handful of questions:

1. Do you have a reference to the hardware youre referring to? "UglyDrone PDU-12S"?
2. What's the relationship between the Relay/Hardpoint and the Circuit Status? Really seems like the Circuit Status and Relay/Hardpoint functions should be two separate panels.
   • Is the relay/hardpoint intended to switch circuits on/off?
   • Could you have Circuit Status without using hardpoint functionality?
3. There is no method with which to grow the table of Circuit Status' if more than 10 are presented by the vehicle.
   • It might be worth keeping the table inside a scrollable element (either QTableWidget, or QScrollArea with QFrame of your existing logic).
     • I personally have components in Air Vehicles that monitor the Power Rails of a number of individual components, and would very quickly exceed 10.
4. The "Last Sent Message" viewer isn't providing overly much added value, i'd be happy to reclaim that space.

[makcuk]

Thank you for reviewing and directions

I have a handful of questions:

1. Do you have a reference to the hardware youre referring to? "UglyDrone PDU-12S"?

Yes, it is a smart PDU with a switched outputs and three DC-DC power rails, here is a product link
https://uglydrone.com/products/uglydrone-pdu-12s.html

2. What's the relationship between the Relay/Hardpoint and the Circuit Status? Really seems like the Circuit Status and Relay/Hardpoint functions should be two separate panels.

PDU outputs switches are accepting hard point commands, that simplify missions in ardupilot for example, when for a some part of the mission one can turn off equipment which isn't required or use some switched channel(s) as a real hard point - turn off electromagnet release for example

• Is the relay/hardpoint intended to switch circuits on/off?
  Yes
• Could you have Circuit Status without using hardpoint functionality?

Of course, grouped on one panel just because it is grouped In one particular device and it is convincing to monitor rails manipulating with hardpoints.

3. There is no method with which to grow the table of Circuit Status' if more than 10 are presented by the vehicle.

I split panels to separate HardPoints from CircuitStatus, also made CircuitStatus dynamic – received updates will be added to scrollable table and sorted by id, so it should handle more than 10

• It might be worth keeping the table inside a scrollable element (either QTableWidget, or QScrollArea with QFrame of your existing logic).

  • I personally have components in Air Vehicles that monitor the Power Rails of a number of individual components, and would very quickly exceed 10.

4. The "Last Sent Message" viewer isn't providing overly much added value, i'd be happy to reclaim that space.

Kept last message as one line for hardpoints, found this useful during debugging.

[joshanne]

Functionally happy with the changes, but the flag processing appears broken.

The scrolling table works nicely, thanks for implementing that.

[joshanne]

These flag checks return an issue for me.

I get the following error:

Traceback (most recent call last):
...
  File "~/dev/dronecan_gui_tool/panels/circuit_status_panel.py", line 116, in _on_circuit_status
    if flags & dronecan.uavcan.equipment.power.CircuitStatus.ERROR_FLAG_OVERVOLTAGE:
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'CompoundType' object has no attribute 'ERROR_FLAG_OVERVOLTAGE'

I can either fix the issue by replacing dronecan.uavcan.equipment.power.CircuitStatus with msg as it is extracted at the start of the message handler, or instantiate the object with dronecan.uavcan.equipment.power.CircuitStatus().

This is because the constants are attached to the instances of the messages, rather than the type of the definition itself.

Just cursory look at the gui_tool project, the preferred method would be to use msg.ERROR_FLAG_xxx format.

        if flags & msg.ERROR_FLAG_OVERVOLTAGE:
            errs.append('OVER_V')
        if flags & msg.ERROR_FLAG_UNDERVOLTAGE:
            errs.append('UNDER_V')
        if flags & msg.ERROR_FLAG_OVERCURRENT:
            errs.append('OVER_C')
        if flags & msg.ERROR_FLAG_UNDERCURRENT:
            errs.append('UNDER_C')

If you open the interactive console, you should be able to do the following and see the different behaviour:

print(dronecan.uavcan.equipment.power.CircuitStatus.ERROR_FLAG_OVERVOLTAGE)
print(dronecan.uavcan.equipment.power.CircuitStatus().ERROR_FLAG_OVERVOLTAGE)

[makcuk]

Fixed flags and squashed commits, thank you

[joshanne]

Also, could we squash the commits, or at the very least clean up the merge commit?

[joshanne]

Thanks for that - can confirm that the CircuitStatus Monitor Panel is showing the correct voltages and currents.

In this case, I published my own messages where voltage=circuit_id/10 and current=(circuit_id/10)+5)

Here, circuits 21, 22, 23 and 24 are just checking the flags display correctly.

Happy to approve and merge this as is now.

[joshanne]

Merge on CI Pass

[joshanne]

Thanks @makcuk merged.