common: add motor_info message #1695
Conversation
- Also Splits ESC and Motor Failures to better organize them. Signed-off-by: Claudio Micheli <claudio@auterion.com>
|
@julianoes @auturgy you know more about motors than me - would you like to add your comments first? I will look at this tomorrow. |
|
I've made a couple of suggestions. Biggest comment is that this should go into development.xml until implemented. |
| <description>Motor information for lower rate streaming. Recommended streaming rate 1Hz.</description> | ||
| <field type="uint8_t" name="index" instance="true">Index of the first Motor in this message. minValue = 0, maxValue = 60, increment = 4.</field> | ||
| <field type="uint64_t" name="time_usec" units="us">Timestamp (UNIX Epoch time or time since system boot). The receiving end can infer timestamp format (since 1.1.1970 or since system boot) by checking for the magnitude the number.</field> | ||
| <field type="uint16_t" name="counter">Counter of data packets received.</field> |
| <field type="uint8_t" name="index" instance="true">Index of the first Motor in this message. minValue = 0, maxValue = 60, increment = 4.</field> | ||
| <field type="uint64_t" name="time_usec" units="us">Timestamp (UNIX Epoch time or time since system boot). The receiving end can infer timestamp format (since 1.1.1970 or since system boot) by checking for the magnitude the number.</field> | ||
| <field type="uint16_t" name="counter">Counter of data packets received.</field> | ||
| <field type="uint8_t" name="count">Total number of Motors in all messages of this type. Message fields with an index higher than this should be ignored because they contain invalid data.</field> |
There was a problem hiding this comment.
Would it be better to make this "Count of motors in this message"? The reason you have something like this is so that you can identify the end point of a partially filled array.
If this is count of all motors, then to work out whether values in these arrays are valid you need to compare count and index etc. Is there some other reason to keep max count?
|
@auturgy YOur suggestions aren't showning up. @cmic0 I assume you understand the workflow. We can't merge a PR into common.xml until there is working implementation. At that point the changes merge without wip tags (and you would also do the "removals" from the ESC fault enum, and remove its WIP tagging). |
|
@cmic0 Please see my note above ^^^ - how are you progressing towards an implementation? |
|
@hamishwillee sorry for the delay in here - i finally got back to this topic, will have an implementation for PX4 ready soon |
|
This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions. |
As per discussion in #1663, this PR introduces a new Mavlink message to handle Motor information in a different message than
ESC_INFO.@hamishwillee @auturgy