Revert rascal model to prevent crash on arming

[Jaeyoung-Lim]

Problem Description
When trying to fly the Rascal model with PX4 SITL, the vehicle would crash immediately after takeoff

Turns out this was because the motor attached on Auterion/FlightGear-Rascal@d0d1db1 was way to powerful
@RomanBapst FYI (5 years old commit...)

Fixes PX4/PX4-Autopilot#24466
@simfinite

Solution
Revert model to use previous gas powered engine (for now)

[simfinite]

@Jaeyoung-Lim thanks for looking into this!

I am having troubles to reproduce the fix, i.e. the issue still persists on my end. Also, it seems the engine specified in Zenoah_G-26A.xml is also an electric engine with even more power:

<?xml version="1.0"?>
<!-- Zenoah G-26A -->
<!-- 2.96 hp engine -->
<!-- one horsepower equals 745.69987 Watts -->

<electric_engine name="electric_1mw">
  <power unit="WATTS">  2207.27 </power>
</electric_engine>

Reducing the power, also does not help. I tried with a tenth of this power, but the plane still rolls on its back and crashes the moment it is armed. If I reduce to 50W, the plane starts spinning/going in circles on the ground when arming.

[Jaeyoung-Lim]

@simfinite hmm...I see have you checked flying manually?

[Jaeyoung-Lim]

@kaklik any chance you can share insights on how we can fix this?

[simfinite]

@simfinite hmm...I see have you checked flying manually?

Good idea, I just tried that. I can arm in manual mode, but as soon as I give some throttle, the plane starts to rotate wildly and crashes.

[simfinite]

I did some more testing. The behavior is not 100% reproducible, sometimes the aircraft "jumps" into the air quickly rotating, sometimes it just rolls over. Either way, I cannot get it flying in PX4 SITL.
Here is an example: https://clip.place/w/axvEjfFDzMhF3Qagq6ymVA

I also tried flying the Rascal model in FlightGear and I can also see a little quirk when first applying throttle, but it will work afterwards. As @Jaeyoung-Lim suggested in another thread, this seems to be related to ground reactions.

Can anyone confirm to have similar problems or is this just on my end?

[Jaeyoung-Lim]

@simfinite
I realized that the setup works without any problems in PX4 v1.13.3

I am guessing it might be something related to the control allocation configuration.

What is confusing for me is that it seems to fly okay after the vehicle is airborne, so it is definitely not just the channel numbering or a sign error.

[simfinite]

@simfinite I realized that the setup works without any problems in PX4 v1.13.3

Confirmed. I can takeoff via commander takeoff. Not an elegant takeoff, it turns 90° CW before lifting off, but it continues to fly ok once airborne.

[Jaeyoung-Lim]

@simfinite Yes, same with me as well. I had some look into flight logs comparing the two versions, but I couldnt find anything meaningful.

I was wondering if anyway it doesnt make much sense if the vehicle turns to the reaction of your throttle. So maybe we either we an aircraft that is too light OR the rotors are too heavy?

[sfuhrer]

Did you check that the mapping is correct?
mixer for 1.13
now, with CA
It seems to be correct for all other planes in SITL, and it was all the same mixer back then, so I would be surprised if it's wrong just on that one here..

Otherwise try to disable all actuators beside the motor and see if it accelerates forward, and then one by one add more actuators again.

[Jaeyoung-Lim]

@sfuhrer Mapping is correct (You can fly the plane once in the air).

I am wondering if the throttle is more aggressive with recent versions of PX4. It seems to be worse in auto takeoff compared to manual takeoff. The spin seems to be a reaction force spinning the vehicle as immediate torque is applied to the props.

[simfinite]

On the forum, there are suggestions this might be a bug with electric motor simulation on JSBSim side:
https://discuss.px4.io/t/state-of-jsbsim-sitl-for-fixed-wing-rascal-model/43654/5

If I find some time, I will test a few more combinations of PX4 and JSBSim to get further insights. I have the feeling it's changes on both sides leading to the faulty behavior to occur and we may have to pin it down more precisely.

[raghu-srm]

Hey Guyz..,
I facing the exact problem as @simfinite described (in the video https://clip.place/w/axvEjfFDzMhF3Qagq6ymVA )
I have tried with both Zenoah G-26A and electric_engine_1050W., It not helped.,

Did we have any workaround ?

[simfinite]

@raghu-srm did you try the Hacker A60-5XS engine as suggested by Scavenger over here https://discuss.px4.io/t/state-of-jsbsim-sitl-for-fixed-wing-rascal-model/43654/3 ?

It seems the issue occurs only for newer JSBSim versions although we haven't exactly tracked it down yet.

[Jaeyoung-Lim]

@simfinite Could we include the change suggested by @scavenger here?

[raghu-srm]

@simfinite thanks man., it is working now., eventhough it sill have wierd takeoff phase, else working good.,

Flight Log: https://logs.px4.io/plot_app?log=2c88c867-c821-40ae-85e7-36bc9d1f9cb9

[Jaeyoung-Lim]

@raghu-srm Could you make this into a PR to this repo?

[raghu-srm]

Yeah sure., Will do it.,

[kaklik]

@kaklik any chance you can share insights on how we can fix this?

My insight into the problem is not entirely complete, as it seems to me that this PR actually touches on a mixture of several issues. However, we have repeatedly encountered very similar difficulties with ground interactions in FlightGear during development of TF-Simulator.

In our case, we were using the YASim engine, for which I once developed a modification to the ground-gear interaction algorithm. That patch was initially accepted into FlightGear, but later removed again because it caused problems when there were discontinuities in the scenery.

In general, though, I have little doubt that JSBSim suffers from the same kind of fundamental problem; it is really a dilemma of how to properly handle object–ground interactions in a flight simulator.

[raghu-srm]

@Jaeyoung-Lim I have created a pull request for the submodule models/Rascal:
🔗 PR: https://github.com/ThunderFly-aerospace/FlightGear-Rascal/pull/2

Once this PR is merged, we can update the submodule reference in the pr-revert-model branch and then create a follow-up PR accordingly.