PX4
Serial port protocol mapping
Right now we map protocols to serial ports, we should instead map serial ports to protocols. It's very easy inadvertently to setup multiple protocols on a single port and cause conflicts. It's made worse by the new RC drivers, where a user must disable one parameter and enable the other.
MAV_0_CONFIG --> 300 (Radio Controller) RC_CRSF_PRT_CFG --> 300 (Radio Controller) RC_SBUS_PRT_CFG --> 300 (Radio Controller) SENS_EN_SF45_CFG --> 300 (Radio Controller) DSHOT_TEL_CFG --> 300 (Radio Controller)
We should instead do what Ardupilot does and map serial ports to protocols. For example:
- The current way could be made to work if the port deconfliction provided any kind of user feedback.
- RC is a dogs breakfast irrespective of this. All default RC on FMU ports should be disabled by default to avoid such conflicts.
That said, I agree that assigning a protocol to a port makes the deconfliction problem go away, at the cost that the list above can become very big - I mean for RC you either have to have the modules for every RC protocol, or add a second level of assignment for the particular RC you want to use. Ditto for the other things like Rangefinder where protocols are not identical across modules.
@bkueng Did the original work and might have an opinion.
The current way could be made to work if the port deconfliction provided any kind of user feedback.
Feedback only works if the user is using QGC and paying attention. (lol yeah right)
That said, I agree that assigning a protocol to a port makes the deconfliction problem go away, at the cost that the list above can become very big
I think a big list is fine, especially since the list would be the same for every serial port.
I mean for RC you either have to have the modules for every RC protocol, or add a second level of assignment for the particular RC you want to use
Right, if an RC protocol module isn't included in the build then assigning a serial port to that protocol would be a no-op. Most builds have all the RC protocols, I think they were split just to allow further reducing FLASH usage. But we could have a warning for the missing module case, which would still require a users attention but would occur much less frequently.
As far as a new design goes, we might need to introduce a serial_port_launcher module which can map serial port numbers to names (we could define in KConfig) and launch the appropriate drivers for each port. But yes I would love input from @bkueng 😃
A statustext or event warning when we have a misconfiguration would be a start.
I'm not sure changing the paradigm at this point would go down very well. It would be a pain to transition.
Feedback only works if the user is using QGC and paying attention. (lol yeah right)
If the vehicle won't take off with this misconfiguration I think they'll got to QGC pretty fast. In fact, if the vehicle is configured properly by default they'll have to go to QGC to enable to RC.
I think an event would be good too. Could be an arming restriction.
I actually had it this way at first and then was requested to change it.
I think a good UI in QGC based on firmware metadata would go a long way. And as a starting point a simple generated method called on param change that checks for conflicts and reports errors would also help.
I actually had it this way at first and then was requested to change it.
@bkueng do you think it's worth changing back?
I think a good UI in QGC based on firmware metadata would go a long way.
Agreed. Do you have any ideas on the best way to do it? Ideally we don't hard code param names since we could add a new serial driver down the road, QGC would need to know about the new parameter to include it during deconfliction.
@bkueng do you think it's worth changing back?
Probably not. It could also be done only on the UI side though.
Agreed. Do you have any ideas on the best way to do it? Ideally we don't hard code param names since we could add a new serial driver down the road, QGC would need to know about the new parameter to include it during deconfliction.
Yes I would do it like the actuators UI by defining a json file that tells QGC how to construct the UI and which parameters to use. The most challenging part is to define that json, which needs to be generic, extendible and covering all cases. And I would go one step further and make it a general peripheral configuration, including I2C, CAN, SPI and ethernet.
... and hopefully smart enough to cope with a misconfiguration done outside of the the UI.
This continues to be a pain point for new users. It will be some work to change the paradigm but I think it's worth it. It's just a matter of finding time to do it. I might have some time to tackle this over the next year.