@iampete I look forward to testing this out and using it. This is a tool I would use frequently.
@kikislater Not sure why you guys are going all EMO over this, it is a GSoC project, it adds to the overall Ardupilot landscape weather or not you use it. There are plenty of features and tools related to Ardupilot that are never touched again. If you want it in GNU Octave, NumPy, or R do it yourself, don’t criticize someone else’s project because it isn’t what you want. R does not have the back end to do this easily.
Citing a 11 year old document with regards to any software as to what it is good at and or for is a colossal joke. Every company I have worked and consulted for uses Matlab, not an opinion a fact.
Great topic and I’d be interested to help testing, if that would be useful.
When you say, we can “use MATLAB as a physics backend for SITL” does that include Simulink? By looking at the code, it looks like it takes a handle for a physics function that is in Matlab which of course could call a Simulink model but that can create overhead.
What information from the autopilot can Matlab access? For example, can Matlab get any Mavlink message desired like outputs of the EKF, raw sensor output, etc?
I’m a bit new to Simulink so any testing and feedback would be great.
In this case MATLAB is only acting as the physics of the vehicle. There some library’s that can be used to allow MATLAB to act as a GCS communicating over MAVLink.
Does this connection by chance work with multiple vehicles? So in the same Simulink could I have multiple multiple UDP connection blocks pointing to the same ArduPilot SITL engine? Or different SITL engines? Thanks.
Should work fine, you will have to increment the USP ports, in AP you can do that with -I 1 for instance 1 ect. By default its instance 0. In matlab you will have either add a similar instance argument to the function or just hard code and save as a different file name. If you add a instance argument it would make a nice improvement, a PR would be great!.
