Updates for new COMPONENT_INFORMATION support #1408
Conversation
|
@olliw42 FYI changes to component_information |
| @@ -6672,13 +6681,11 @@ | |||
| <!-- This message is work-in-progress it can therefore change, and should NOT be used in stable production environments --> | |||
| <description>Information about a component. For camera components instead use CAMERA_INFORMATION, and for autopilots use AUTOPILOT_VERSION. Components including GCSes should consider supporting requests of this message via MAV_CMD_REQUEST_MESSAGE.</description> | |||
| <field type="uint32_t" name="time_boot_ms" units="ms">Timestamp (time since system boot).</field> | |||
| <field type="uint8_t[32]" name="vendor_name">Name of the component vendor</field> | |||
There was a problem hiding this comment.
@DonLakeFlyer @julianoes The theory is that there will be metadata to get the values of these fields.
- Removing these before said metadata exists may well break something more seriously than just "I need to update my messages".
- There is a question about what should be in metadata and what should be in the message itself. The theory is that the message should have stuff that everyone will need - getting the metadata should be a choice. [So for camera, the common settings are in message, and the extended are in metadata]. Is this stuff something that we should not force users to implement the whole mavftp etc infrastructure to get.
I'm to some extent playing devils advocate, but for next time perhaps add our new fields as extensions. Then remove the old fields and make the new fields non-extensions when we have a complete story
|
@hamishwillee thx for the FYI (I've seen it). IMHO this should win the gold medal for the greatest nonsense of the year. I can't believe it, what a nonsense. This could be achieved much easier by, e.g., simply reading the ftp dir without any need of all this cruft and overhead. It's sad to see a good idea turned into a terrible result. IMO. |
| @@ -6672,13 +6681,11 @@ | |||
| <!-- This message is work-in-progress it can therefore change, and should NOT be used in stable production environments --> | |||
There was a problem hiding this comment.
@DonLakeFlyer If using MAV_CMD_REQUEST_MESSAGE, what param maps to the metadata type you are after?
|
@olliw42 The authors obviously thought the "cruft" had purpose. This provides:
Yes you could have a folder for component metadata, perhaps hard coded and allow the vehicle to "see what is there". Is that what you were envisaging? Or to put it another way, if you want to educate, perhaps you should expand a bit on how your solution would allow us to do the same kinds of things (or why the kinds of things we want to do are unnecessary). |
Changes for #1346