Skip to content

HardwareReport: show vehicle config and output pins#292

Open
edengilbertus wants to merge 1 commit intoArduPilot:mainfrom
edengilbertus:hardware-report-vehicle-config
Open

HardwareReport: show vehicle config and output pins#292
edengilbertus wants to merge 1 commit intoArduPilot:mainfrom
edengilbertus:hardware-report-vehicle-config

Conversation

@edengilbertus
Copy link
Contributor

@edengilbertus edengilbertus commented Feb 21, 2026

Display vehicle type frame class and also frame type from log parameters plus show how output pin assignments with SERVOx_FUNCTION mappings and DroneCAN ESC/Servo bitmask configuration.

Closes #242

Copy link
Member

@IamPete1 IamPete1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Param meta data should be loaded from auto generated param docs. We don't currently do it in this tool, but we do in FilterReview. You can generate with ./Tools/autotest/param_metadata/param_parse.py --format json then manually copy in the params you need so it loads faster.


let have_content = false

// Vehicle type from build_type (determined in load_log via get_version_and_board)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You spotted get_version_and_board but your not using it, instead your trying to guess from params. This is very fragile. Better to use it for the base vehicle type.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hey so the now passing build_type from

get_version_and_board()
into

load_vehicle_config()
the param based inference is only used as a fallback for .param files where no log messages are available.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I would vote to just remove the param based stuff, its likely to get broken, reading from a log is the main use case.

if (!(option_name in params)) {
continue
}
// Check if ESC output over CAN is enabled (bit 7)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only for hobywing ESC.

add_cell(output.func_name)
}

// Check for CAN servo outputs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about adding a column to the table for "DroneCAN servo" and "DroneCAN ESC", you could add a check mark or leave blank.

@edengilbertus edengilbertus force-pushed the hardware-report-vehicle-config branch from 0f7b939 to 403d35c Compare February 24, 2026 06:52
@IamPete1
Copy link
Member

This is what it look like now.

image

It would be nice to also convey which bus there outputting on, IE CAN 1 or 2. I wonder if doing a whole column for each output type is too much, maybe it would be better to just have a "output type" column which could have "DroneCAN ESC 0" or "DroneCAN Servo 0" in it for example. That would let us take into account the DroneCAN index offset stuff where the servo number does not match the DroneCAN index. What do you think?

@edengilbertus edengilbertus force-pushed the hardware-report-vehicle-config branch from 403d35c to f94f36f Compare March 1, 2026 11:26
@edengilbertus
Copy link
Contributor Author

hello so heres what has been done vehicle type now comes from get_version_and_board() build_type instead of guessing from params , removed HobyWing-specific bit 7 check :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

HardwareReport: show configuration of vehicle and output pins

2 participants