Feature SDK with a simple model-based simulation for functionality testing

[angel-ayala]

Most of the developing process even for the possible CI/CD workflows will require an offline validation of different components and the major bottleneck right now is the dependency on the real aircraft connection. I was recently developing custom GCS software and using software-in-the-loop (SITL) for testing, mostly with the Ardupilot firmware. Never had a real experience with PX4 but I'm aware that also has SITL capabilities, but as far as I know there is only for the flight controller and desktop based hardware, I did a little search and there was not much information regards to use SITL under android platform, but possibly embed the entire controller flight stack for either AP or PX4, can be an unnecessary code or processing overload. Although, more MAVLink compatible constraints the development will follow.

This can also be useful to move towards a generic API layer, using a custom made simulation for the application functionality as another SDK with its corresponding managers. I'm not sure how difficult this can be, but I think it worth to think about it.

[mjohenneken]

SITL in Ardupilot is afaik written in python https://github.com/ArduPilot/ardupilot/blob/master/Tools/autotest/sim_vehicle.py
I'm not sure how much native code this python script calls, but maybe it could be run using a android python executable through termux

The ressource heavy part is the physical simulation which could be offloaded to a desktop/laptop pc.

The ardupilot docs have this diagram, highlighting the very modular stucture of SITL that is based on Socket comms

What I'm wondering: At which layer do we insert this simulator. If its just for developing GCS hardware and integration tests, it would be enough to use SITL directly on as desktop "pretending" to be the DJI drone connected via WenuLink at a certain IP:port. For a "realistic" simulation we could build physical models in a simulator like gazebo and calibrate them with flights with the real drone.

DJI Mini3 Model for Flight Gear
DJI M100 Model for ??

If we want to use it for testing WenuLink code then the only realistic insertion point is to use a reimplementation of the DJI interfaces which sounds like a lot of work. For reliability and testing in might be enough to do unit- or integration testing.

[angel-ayala]

I been already used the sim_vehicle.py script and appears to be like a ROS launch file, which orchestrate the firmware compilation with the SITL features, execute the produced binary, and mavproxy to bridge the message communication, among other tools probably. So I'm not sure that executing python inside Android will be enough. Probably using the SITL in another machine such a desktop could be the easiest to do, developing something like mavproxy with the Manager classes.
Nevertheless, that does not seems to be efficient since both ArduPilot or PX4 firmware already has implemented the MAVLink messages, which is what WenuLink does.

So, what if instead we develop a "dumb" simulation, focused only in the quadcopter dynamics, and do some logs for other components such as the camera. So, If some camera photo or video recording is performed, the related Manager class, should only put some log like, "Photo taken" or "Start video recording". In such way, we could keep focused on the DJI SDK architecture more than switch to open source autopilot.

I mention this, because there is this repo of our team that uses webots and ardupilot SITL, and the simulation controller interacts with mavlink messages to move the actuators and send data from sensors. Basically, the webots simulation scene is dumb and acts only as a external positioning system, delivering local and global data for motion. I will try to draft some architecture to check if is feasible.

Of course is you have a more concrete idea to move forward with the firmware's SITL running in a desktop, we can go with that in future releases.

[mjohenneken]

yeah, agreed that the sim_vehicle.py is gonna be difficult to run on android with all its bells and whistles.

So you're suggesting all the DJI Interfaces are stub implementation and only the attitude control is simulated possbility by an external simulator ? What i would like to understand is: What do we benefit/need on top of the existing DJI simulator. Would it need a better, close to reality flight dynamics model?

[angel-ayala]

So you're suggesting all the DJI Interfaces are stub implementation and only the attitude control is simulated possbility by an external simulator ?

In such case the simulated attitude control will be comprised on the application instead of being external. The external simulation example was only regards to the ardupilot SITL.

What do we benefit/need on top of the existing DJI simulator. Would it need a better, close to reality flight dynamics model?

The major benefit here will be for development only, allowing to run integrations test without the DJI connection. In such way we could use test-driven approaches to check and ensure which feature is actually passing the test or which is not.

I was thinking in this because there were some changes which solved or added a certain behavior, and in other PR such behavior were messed up and no one was able to see that a bug was reintroduced after testing with the aircraft. In development stages, I always consider that the real aircraft testing is the last test to run, that will ensure that all the application functions are ok, but also such test are more expensive since consume battery time and therefore impacts the charge/discharge lifecycle.

So basically, the main idea for this is to enable a non-aircraft test situation to check non-SDK related issues such as UI or protocol communications (MAVLink, WebRTC). Maybe the title must be updated?