Andrew: It is non-intuitive to discern the port number from other things to count (e.g. MAVs or network ports). I don’t have a better suggestion for now. Peter: We could describe MAVLink ports as different serial port protocols (e.g MAVLink port 1, MAVLink port 2, etc). A: Network ports start at index 20 and CAN at 30. So we could be using those numbers. All of these ports are roughly treated notionally the same as traditional serial ports. Randy: Could we be creating the corresponding MAV parameters dynamically? Like we do with drivers. A: It is not currently directly supported. We do something like that for scripting, and that’s limited to float parameters.
As for the driver optional parameters, these are gated by a 0/1 parameter. We’d have to adapt that check.
P: I don’t like having a direct notional link between a MAVLink channel and a serial port. George: How about we have MAV* parameters that we use to assign the MAVLink channel to a physical port. A: That has the disadvantage that one has to correctly set both the channel and the port to poitn to each other. R: Or we make the one parameter as read-only. A: It would be nice to also do away with the limit of available MAVLink ports, which are now at a maximum of 7.
Another thing we could do is declare e.g. 48 MAVLink channels under the MAV* tree, but have unconfigured sub-tree pointers, which will get skipped when instantiating parameters.
UTC0739
A: My concern is the case where the fence checking code starts checking and then the user changes the fence. Andy: Yes, we might need a mutex in the fence code. P: get_loaded_fence_semaphore() exists, but that’s only for EEPROM (actually storage manager in general). A: So we probably already need to have an additional semaphore for the FTP thread, which can also change the fence data. P: No, because the fence code will look at data that is in memory, not directly from FTP. A: Ok, so we only need the security that changing the fence won’t throw the logic off.
UTC0751
P: We might have an issue with mode AltloiterQLand. A: We’ll need a few more autotests to ensure all suspect code still works.
UTC0801
A: Merged!
UTC0802
A: Looks good! Merged!
UTC0805
A: We got a test, and it showed that it’s still not 100% there.
When the plane flies too fast, the position controller might be giving up; the plane continues to fly VERY fast.
I don’t know why the vehicle accelerated and didn’t pitch up.
<Discussion on potential reasons, no concrete outcome yet.>