arducopter-heli in sitl cann't takeoff?

as this photo shows:


it’s started by cmd “sim_vehicle.py -w -l 32.1291816,118.8849733,100,0 --model heli --frame heli --console --map”
any solutions?

Hello,

Yes, you should disable the interlock as stated in the heli documentation !

Hi, really thank you for responsing!
The problem is I cann’t find the heli document, it seems not been listed clearly in the website. I read most of the site “https://ardupilot.org/dev/docs/copter-sitl-mavproxy-tutorial.html”, still cannot find the special “heli” content.
Can you help and figure the url out? Thank you so much!

https://ardupilot.org/copter/docs/traditional-helicopters.html

Got it! It seems so clearly in the copter branch.
Huge thanks!

@addriumruss were you able to get it working? Heli’s require the motor interlock feature to provide a layer of safety. On an actual heli when the flight controller boots up, there is a RC receiver that provides the interlock channel information and the user should start with the interlock channel in the disabled position so the system is ready to arm. if you don’t have a controller connected then it boots with the interlock enabled so that the heli can’t be armed without the controller.

So for SITL you will have to set the interlock channel (RC channel 8) low to disable the interlock and allow arming. Then you will enable the interlock after arming in order to start the motor and rotors.

Regards,
Bill

@bnsgeyer Hi Bill, really appreciated for the tip!

During last week I didn’t find the exact way from outside to disable the interlock with the “traditional-helicopter-tuning.html” page. Finally I changed the code in ardupilot/ArduCopter/AP_State.cpp at line 87, from “ap.using_interlock = true;” to “ap.using_interlock = false;”. After recompile, it worked for sitl!

I read the “connecting and calibration” chapter in the webpage and still couldn’t find the way to disabel channel 8, much wonder about the cmd. I’m a freshman to APM and helicopter, maybe there are some conventional ways hiding from a freshman?

When executing ‘./simvehicle.py -v ArduCopter -f quad/heli…’, it seems that resolving motor interlock (rc 8 1100) is aditionally needed for heli, but I can’t make heli fly.

For SITL with heli, trying a mission, I get to the point that it arms during 10 seconds and then disarms:
msg1
(filtering MSG from generated .bin in logs directory)
after executing:
rc 8 1100;batreset;mode poshold;arm throttle on;rc 3 1500;takeoff 2;mode auto
(It seems that commands between semicolon work, since in 10 seconds may be there is no time for typing or recalling all those commands).

Console appears momentarily after arming:


and 10 seconds later

Note NAV_TAKEOFF: FAILED

On connected MP:

What am I missing?

Responding to myself: interlock channel high after arming, such as
mode acro;batreset;rc 8 1100;arm throttle on;takeoff 5;rc 8 1900;mode auto

@Webillo I think there is an issue currently with heli’s and auto takeoff. I have a PR in to fix that but I have got sidetracked with other things. Also did your mission start with a takeoff command?

The issue with the aircraft disarming after 10 seconds can be fixed by setting DISARM_DELAY to 0.

To perform an auto mission, you will need to takeoff in loiter and then switch to auto.

Let me know if it works

@Webillo In my experience, first I modified the code in ardupilot/ArduCopter/AP_State.cpp at line 87, from “ap.using_interlock = true;” to “ap.using_interlock = false;”. Then When setting the mission, the cmd type of first flypoint must be a TAKEOFF command. After uploading mission and set to auto mode with dronekit sdk, it flied successfully.

Thanks a lot for your work.

Thanks, good suggestion.

Running
./sim_vehicle.py -v ArduCopter -f heli --console
with initial mode STABILIZE and with an eye on the console, this sequence worked:
param set DISARM_DELAY 0
STABILIZE> rc 8 1100
STABILIZE> arm throttle
STABILIZE> rc 8 1500
STABILIZE> takeoff 5
STABILIZE> Take Off started
rc 3 1700
STABILIZE> mode auto
STABILIZE> mode circle
AUTO> AUTO> mode land
(auto interrupted and changed to circle for simplicity (possibly collective high))

Uploading the .bin log to the UAV Log Viewer gives this 4K video.
In spite of having generated it with
./sim_vehicle.py -v ArduCopter -f heli --console
the shape obtained is a drone


even on messages ‘heli’ can be found:
FMT, 8, 27, HELI, Qffff, TimeUS,DRRPM,ERRPM,Gov,Throt
MSG, 38481268, Frame: HELI

Trying
./sim_vehicle.py -v ArduPlane -f plane-vtail
gives


which is nice, but trying
./sim_vehicle.py -v Rover -f rover
gives

which is not so nice (not that much water or rain in the circuit).

Trying uploading to the UAV Log Viewer real .bin logs (not SITL):
helicopter


(again drone shape)
rover

(again boat shape, with not that much water or rain in the circuit).

So all happens as if the plotter program at the server interprets the vehicle type but not the vehicle frame type.

Now uploading to the UAV Log Viewer a real rover .tlog file (not SITL)


which, believe it or not, corresponds to a rover.

That corresponds to running a rover on the rooftop of a building (around 20m above ground), so unless because of that the plotter program running on the server interprets that it must be a plane, something very strange happens.

Could something be done?

@Webillo I’m sure something could be done but I’m not familiar with that the UAV log Viewer program. I would suggest posting to the ArduCopter thread. Maybe another user more familiar and capable of making the changes will see it and correct it.

Here.