Andy: Overflows Pixhawk1, so it can’t be immediately brought into 4.6. Andrew: We’ll need to ifdef it or scrounge up some space. Peter: Remove DShot-on-IOMCU support from Pixhawk1 to make space? Andr: Okay, then let’s have a PR dropping the IOMCU-DShot in Pixhawk1 <1M flash and then we bring this one in.
Let’s drop ICE and EFI on minimized feature builds. That’s going to affect the least number of people.
UTC0709
Andr: Didn’t test yet, sorry.
UTC0710
Andr: It would be better if we pulled up to 5V, for better signal integrity. Andy: I flew with internal pullup to 3V3 and external to 5V and it still flew fine.
People already have issues without it. Andr: TBS needs to test it.
UTC0712
Andy: We disabled this one by accident.
The old config affects the pin definitions.
Merged!
UTC0714
Andy: There’s a new Lua applet for this. Andr: WikiNeeded.
Merged!
UTC0717
Peter: Depends on a PR on the MAVLink repo. Andr: That PR needs to match the upstream MAVLink PR.
The ArduPilot/ardupilot PR itself looks alright.
UTC0724
Ankur: It is meant to integrate autogenerated code from Simulink with ArduPilot
We would like to be able to write apps not only for controllers, but also for any kind of code (sensors, read measurements, etc). Sid: They are asking for their own library within AP, which they can maintain. Andr: How is CI going to be working on our end? Sid: They have hand-written a “dummy” binary that has the same API as Simulink and will be probing/using the code under test. Andr: Is this meant to be for experiments only or for production as well? Ankur: From our PX4 experience, people don’t use it for production. Andr: What is the license of the Simulink-genereted code? Ankur: It’s your code, you do what you want with it. I’ll double check and get an official response. Sid: I was told the same thing. Andr: How about the other vehicles? This is Copter only. Ankur: There are more PRs to come. Andr: Why are there so many thin wrappers around AP’s methods? Arun: We can better prepare for abstractions towards other vehicles. Andr: I don’t think abstracting to othe vehicles will be possible, even with this interface. Sid: Is the naming the reason you need those additional wrappers? Ankur: The Simulink blocks invoke the glue code, and that was a cleaner implementation. Andr: You could just as well do this by invoking the ArduPilot libraries.
But more to the point, we don’t like having APIs specific for particular vendors.
It’s also impossible with this implementation to disable the custom controller. Both controllers will be running simulteneously, even logging. Ankur: Some of our clients want to write controllers that complement the existing ones, not override them. Andr: If you want to augment the standard controller, you could call it purposely from your own controller.
Also, your current implementation isn’t thread-safe, w.r.t. Andy’s fast-task controllers. It will compete for control on the ouptut pins.
The course of action is to get Pete Hall involved, he is the one who knows our custom controller mechanics best. Sid: I’ll make this call happen. Andr: Ideally we’d prefer if you could fit on the existing custom controller, or even extend it. But at the least we want a solution that can be test-flown safely.
UTC0804
Merged! Blame Peter for all future bugs
UTC0807
UTC0808
Merged!
Peter: Are we happy to install Docker in our Custom Build Server? Andr: Yes, go ahead. Let’s make sure Shiv has the right user rights.
