I’m building a triple redundant system with PX4. To test the system I’m doing the Software In The Loop but I have to run 3 fight stack at the same simulator: jmavsim or gazebo. Just one of the PX4 will be on charge, the other two will be running but not sending the outputs to the simulator although they need to be ready to change with the PX4 on charge and take its place at any time if I detect a failure based on the estimator_status message. Is it possible to do some changes at the PX4 code allowing to accept data from Gazebo on the 3 fight stack but just one of them sending output values to Gazebo? Does the TCP protocol with gazebo allow me to connect the 3 flight stack and to change the PX4 flight stack which is sending the outputs in flight ? Thanks in advance!
Is it possible to do some changes at the PX4 code allowing to accept data from Gazebo on the 3 fight stack but just one of them sending output values to Gazebo? Does the TCP protocol with gazebo allow me to connect the 3 flight stack and to change the PX4 flight stack which is sending the outputs in flight ?
I think this really gets into how PX4 will need to evolve to fully support a triplex system with multiple consolidation planes. Where is the last selection (actuator outputs) going to occur?
If you take a look at ekf2 and multi-ekf support you can see some of this start to evolve in the upstream project. Each ekf2 instance is independent and oblivious of the others and then a new selector module consumes the output from all instances, selects the current primary, and propagates the best estimate to the rest of the system (vehicle_attitude, vehicle_local_position, vehicle_global_position). This will soon be extended to select across instances running on multiple PX4 systems/nodes over UAVCANv1.
I’m doing an extra module inside PX4 (a task running on background instead of PX4 workqueue) for the selection algorithm. It must receive information from the other PX4 stacks (probably through creating a server and using unix sockets) and subscribe the estimator_status.topic to make the decision . After the decision is made, the selection should be done before the Simulator receives the output values, but still inside PX4 because I want a descentralized system. I am accepting suggestions…
I already read the code at “ekf2” module as well as the “sensor” module where PX4 detects some hard faults on sensors too. I noticed ekf2 has a boolean flag for multi-ekf support, is it already working on SITL? So I could access to the estimator_selector_status.msg to get the “healthy” from different instances adding another redundancy level.
Yes multi-ekf is enabled by default in SITL and on most of the newer boards.
Hello again! After studying a bit further the multi-ekf support, I’m changing my strategy about fault detection. Instead of reading the topic estimator_status.msg I climbed to the upper level to read the estimator_selector_status.msg and to make the decision using the “healthy” of each instance as well as “instances_available”, “instance_changed_count”, “gyro_fault_detected”, “accel_fault_detected” or even “combined_test_ratio” and “relative_teste_ratio”. Do you think it’s reasonable to consider a PX4 system failure if I have less than 3 healthy instances from ekf? I am still trying to find the best way to relate this new data variables with my conclusion about PX4 status.