Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v1.10.0-rc quadcopter doesn't take off in HITL/jMAVsim #13471

Closed
langrind opened this issue Nov 14, 2019 · 4 comments
Closed

v1.10.0-rc quadcopter doesn't take off in HITL/jMAVsim #13471

langrind opened this issue Nov 14, 2019 · 4 comments
Labels
bug Sim: HITL hardware in the loop simulation

Comments

@langrind
Copy link
Contributor

langrind commented Nov 14, 2019

Describe the bug
Set up HITL simulation with jMAVsim on Ubuntu 18.04, Pixhawk 4 with v1.10.0-rc, locally built px4_fmu-v5-multicopter.

To Reproduce
Steps to reproduce the behavior:

  1. Follow the recipe from px4 website
  2. Using Manual/Stabilized mode, arm vehicle and apply throttle
  3. Vehicle does not take off
  4. Mavlink shell (listener command) shows actuator_outputs_1 with valid values and actuator_outputs_0 with 0 values

Expected behavior
SERVO_OUTPUT_RAW or HIL_ACTUATOR_CONTROLS should follow actuator_outputs_1 and the vehicle should take off in simulation

Log Files and Screenshots
Flight Review Link

Add screenshots to help explain your problem.

Drone:

  • Pixhawk4 running in HITL Quad Mode
  • Photo of the IMU / autopilot setup if possible.
    IMG_8020
@julianoes julianoes added Sim: HITL hardware in the loop simulation bug labels Nov 15, 2019
@julianoes
Copy link
Contributor

That's not good but thanks for the detailed report!

@langrind
Copy link
Contributor Author

Originally I stated : "MAVLink inspector in QGC shows no HIL_ACTUATOR_CONTROLS, and SERVO_OUTPUT_RAW values are all 0".

But this is misleading. The MAVLink Inspector in QGC can only show the messages forwarded by jMAVSim. What's more interesting is:

  1. Once the problem is happening, kill the simulator
  2. Connect QGC to the Pixhawk via USB
  3. Use the MAVLink inspector

This shows:

  • HIL_ACTUATOR_CONTROLS is generated by the Pixhawk, but it is all zeros
  • SERVO_OUTPUT_RAW flips back and forth between all-zeros sometimes and correct (or at least sensible) values other times

It seems to me that the publication of uOrbs actuator_outputs instance 0 and instance 1 is confusing the mavlink module's generation of HIL_ACTUATOR_CONTROLS and SERVO_OUTPUT_RAW.

listener actuator_outputs

TOPIC: actuator_outputs 2 instances

Instance 0:
 actuator_outputs_s
	timestamp: 712451977  (0.010010 seconds ago)
	noutputs: 8
	output: [0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000]

Instance 1:
 actuator_outputs_s
	timestamp: 712226919  (0.236525 seconds ago)
	noutputs: 12
	output: [1358.0000, 1408.0000, 1515.0000, 1323.0000, 1500.0000, 1500.0000, 900.0000, 900.0000, 1500.0000, 1500.0000, 1500.0000, 1500.0000, 0.0000, 0.0000, 0.0000, 0.0000]

If only instance 0 was published, and it had the correct values, I bet it would work.

Also, I tested a Pixhawk 2.1 (Cube) running px4_fmu-v3_default, and the behavior was 100% identical.

@langrind
Copy link
Contributor Author

This change causes the HIL_ACTUATOR_CONTROLS mavlink message to have non-zero values, and now the drone takes off in jMAVSim and I can fly around Zurich crashing into virtual trees:

langrind@nik:~/Firmware$ git diff
diff --git a/src/modules/mavlink/mavlink_messages.cpp b/src/modules/mavlink/mavlink_messages.cpp
index 61a55b8b22..4e258c6165 100644
--- a/src/modules/mavlink/mavlink_messages.cpp
+++ b/src/modules/mavlink/mavlink_messages.cpp
@@ -3065,7 +3065,7 @@ private:
 protected:
        explicit MavlinkStreamHILActuatorControls(Mavlink *mavlink) : MavlinkStream(mavlink),
                _status_sub(_mavlink->add_orb_subscription(ORB_ID(vehicle_status))),
-               _act_sub(_mavlink->add_orb_subscription(ORB_ID(actuator_outputs))),
+              _act_sub(_mavlink->add_orb_subscription(ORB_ID(actuator_outputs), 1)),
                _act_time(0)

I wonder if this is the correct fix?

langrind added a commit to langrind/Firmware that referenced this issue Nov 16, 2019
…3471.

When running in HITL mode, pwm_out_sim publishes actuator_outputs.

px4io unconditionally publishes the uOrb actuator_outputs. When HITL
is configured, the px4io copy of the uOrb has all zeros.

The result is that there are two publications, one valid, and one
all-zeros. This causes the HIL_ACTUATOR_CONTROLS mavlink message
to be incorrect (all-zeros) and the SERVO_OUTPUTS_RAW mavlink
message to be inconsistent, as it takes the data from one or the
other uOrb randomly each cycle.

The fix is to let px4io know that HITL is in effect when it is
started, and modify px4io to suppress publication in this case.

This is a bigger more complicated fix than I would like, but I
think it is conceptually correct.
langrind added a commit to langrind/Firmware that referenced this issue Nov 16, 2019
…3471.

When running in HITL mode, pwm_out_sim publishes actuator_outputs.

px4io unconditionally publishes the uOrb actuator_outputs. When HITL
is configured, the px4io copy of the uOrb has all zeros.

The result is that there are two publications, one valid, and one
all-zeros. This causes the HIL_ACTUATOR_CONTROLS mavlink message
to be incorrect (all-zeros) and the SERVO_OUTPUTS_RAW mavlink
message to be inconsistent, as it takes the data from one or the
other uOrb randomly each cycle.

The fix is to let px4io know that HITL is in effect when it is
started, and modify px4io to suppress publication in this case.

This is a bigger more complicated fix than I would like, but I
think it is conceptually correct.

Signed-off-by: Nik Langrind <langrind@gmail.com>
@langrind
Copy link
Contributor Author

#13488 is my proposed fix

langrind added a commit to langrind/Firmware that referenced this issue Nov 20, 2019
…3471.

When running in HITL mode, pwm_out_sim publishes actuator_outputs.

px4io unconditionally publishes the uOrb actuator_outputs. When HITL
is configured, the px4io copy of the uOrb has all zeros.

The result is that there are two publications, one valid, and one
all-zeros. This causes the HIL_ACTUATOR_CONTROLS mavlink message
to be incorrect (all-zeros) and the SERVO_OUTPUTS_RAW mavlink
message to be inconsistent, as it takes the data from one or the
other uOrb randomly each cycle.

The fix is to let px4io know that HITL is in effect when it is
started, and modify px4io to suppress publication in this case.

This is a bigger more complicated fix than I would like, but I
think it is conceptually correct.

Signed-off-by: Nik Langrind <langrind@gmail.com>
bkueng pushed a commit that referenced this issue Nov 20, 2019
When running in HITL mode, pwm_out_sim publishes actuator_outputs.

px4io unconditionally publishes the uOrb actuator_outputs. When HITL
is configured, the px4io copy of the uOrb has all zeros.

The result is that there are two publications, one valid, and one
all-zeros. This causes the HIL_ACTUATOR_CONTROLS mavlink message
to be incorrect (all-zeros) and the SERVO_OUTPUTS_RAW mavlink
message to be inconsistent, as it takes the data from one or the
other uOrb randomly each cycle.

The fix is to let px4io know that HITL is in effect when it is
started, and modify px4io to suppress publication in this case.

This is a bigger more complicated fix than I would like, but I
think it is conceptually correct.

Signed-off-by: Nik Langrind <langrind@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Sim: HITL hardware in the loop simulation
Projects
None yet
Development

No branches or pull requests

2 participants