search

iNavFlight / inav-configurator

GNU General Public License v3.0
565 stars 303 forks source link

Arming Enabled while Connected to Configurator #1744

Closed joshfisk3 closed 5 months ago

joshfisk3 commented 1 year ago

While installing iNav 6 on a new flight controller arming with my transmitter and raising the throttle on my transmitter allowed the motor to spin even with the motor output toggle disabled in the outputs tab. I would assume that that is incorrect behavior.

MrD-RC commented 1 year ago

Can you provide more details. Such as your mixer set up.

joshfisk3 commented 1 year ago

of course, It was a f405 wmn with the airplane without a rudder and separate aileron controls preset loaded on the mixer. It might have been possible that I had toggled to enable and then toggle to disable the motor output but it was for sure toggled on do not allow motor output when I was able to arm and spin the motor with my tx. The f405 was freshly flashed with 6 alongside a full erase with no diff importing at all. If there is anything else I can provide let me know.

mmosca commented 1 year ago

do you have a diff?

packetpilot commented 5 months ago

This is also true on (both) my rover setups -- one is an F722 Wing and the other is an F722-WPX.

Both of them are presently using "standard" ESCs. Mixer is default rover (one motor, one servo for yaw).

sensei-hacker commented 5 months ago

This is also true on (both) my rover setups -- one is an F722 Wing and the other is an F722-WPX.

Both of them are presently using "standard" ESCs. Mixer is default rover (one motor, one servo for yaw).

Just to confirm, that's a true servo that controls the steering rack? No differential steering here like a bulldozer or skid steer loader would use?

Can you provide a diff, please?

packetpilot commented 5 months ago

Yes, on both my INAV 7 rovers, each presently has a standard ESC (one's a 2wd w/ a Castle mamba x, one's a 4x4 w/ a shoddyching MAX 10 SCT) and each has one Savox servo pushing a bellcrank at ~333~ 330Hz.

Here's my 2wd rover's diff -- it's the only one at hand at the moment.

# diff

# version
# INAV/MATEKF722SE 7.0.0 Dec  5 2023 / 10:39:38 (895a4f31)
# GCC-10.3.1 20210824 (release)

# start the command batch
batch start

# resources

# Timer overrides

# Outputs [servo]
servo 3 1100 2048 1510 100

# safehome

# features
feature -TX_PROF_SEL
feature -AIRMODE
feature GPS
feature REVERSIBLE_MOTORS
feature LED_STRIP
feature PWM_OUTPUT_ENABLE

# beeper

# blackbox
blackbox -NAV_ACC
blackbox NAV_POS
blackbox NAV_PID
blackbox MAG
blackbox ACC
blackbox ATTI
blackbox RC_DATA
blackbox RC_COMMAND
blackbox MOTORS
blackbox -GYRO_RAW
blackbox -PEAKS_R
blackbox -PEAKS_P
blackbox -PEAKS_Y

# Receiver: Channel map

# Ports
serial 0 262144 115200 115200 0 115200
serial 1 2 115200 230400 0 115200
serial 2 64 115200 115200 0 115200
serial 3 2048 115200 115200 0 250000
serial 5 1 115200 115200 0 115200

# LEDs
led 0 0,15::COE:11
led 1 1,15::COE:11
led 2 2,15::COE:11
led 3 3,15::COE:11
led 4 4,15::COE:11
led 5 5,15::COE:11
led 6 6,15::COE:11
led 7 7,15::COE:11
led 8 8,15::COE:11
led 9 9,15::COE:11

# LED color

# LED mode_color

# Modes [aux]
aux 0 0 0 1300 2100
aux 1 12 2 1300 2100
aux 2 28 3 1300 2100
aux 3 15 3 900 1200
aux 4 55 1 1300 2100
aux 5 47 4 925 1200

# Adjustments [adjrange]

# Receiver rxrange

# temp_sensor

# Mission Control Waypoints [wp]
#wp 0 invalid

# OSD [osd_layout]
osd_layout 0 0 23 0 H
osd_layout 0 1 12 0 H
osd_layout 0 4 8 6 V
osd_layout 0 7 25 12 V
osd_layout 0 9 1 2 H
osd_layout 0 11 13 1 V
osd_layout 0 12 0 0 V
osd_layout 0 13 26 1 V
osd_layout 0 15 1 0 H
osd_layout 0 28 23 11 H
osd_layout 0 40 25 6 V
osd_layout 0 41 0 7 V
osd_layout 0 42 0 6 V
osd_layout 0 43 0 0 V
osd_layout 0 54 13 0 V
osd_layout 0 99 15 2 V
osd_layout 0 100 12 9 H
osd_layout 0 101 12 12 V
osd_layout 0 102 5 12 V
osd_layout 0 103 19 12 V
osd_layout 0 105 1 12 V
osd_layout 0 110 25 7 V
osd_layout 0 125 25 0 V
osd_layout 0 129 10 10 H
osd_layout 0 145 14 3 H

# Programming: logic
logic 0 1 -1 7 7 0 3 15 0
logic 1 1 0 23 1 10 0 0 0

# Programming: global variables

# Programming: PID controllers

# master
set gyro_main_lpf_hz = 10
set gyro_zero_x = -57
set gyro_zero_y = -3
set gyro_zero_z = 3
set ins_gravity_cmss =  971.064
set acc_hardware = MPU6000
set acczero_x = 79
set acczero_y = 12
set acczero_z = 23
set accgain_y = 4074
set accgain_z = 4025
set align_mag = CW270FLIP
set mag_hardware = NONE
set baro_hardware = BMP280
set serialrx_provider = CRSF
set motor_pwm_protocol = STANDARD
set motor_poles = 4
set failsafe_procedure = DROP
set 3d_deadband_low = 1425
set 3d_deadband_high = 1510
set 3d_neutral = 1480
set servo_pwm_rate = 330
set applied_defaults = 1
set gps_provider = UBLOX7
set gps_ublox_use_galileo = ON
set deadband = 1
set yaw_deadband = 1
set nav_wp_radius = 30
set nav_wp_max_safe_distance = 1500
set nav_fw_wp_tracking_accuracy = 2
set nav_fw_wp_tracking_max_angle = 45
set nav_fw_wp_turn_smoothing = ON-CUT
set nav_fw_pitch2thr_smoothing = 1
set fw_min_throttle_down_pitch = 10
set nav_fw_pitch2thr_threshold = 5
set nav_fw_loiter_radius = 61
set nav_fw_control_smoothness = 8
set nav_fw_allow_manual_thr_increase = ON
set nav_fw_yaw_deadband = 5
set osd_video_system = NTSC
set osd_units = IMPERIAL
set osd_dist_alarm = 999
set osd_current_alarm = 51
set osd_gforce_alarm =  3.000
set osd_gforce_axis_alarm_min = -3.000
set osd_gforce_axis_alarm_max =  3.000
set osd_camera_fov_h = 150
set osd_camera_fov_v = 120
set osd_hud_wp_disp = 3
set i2c_speed = 800KHZ
set tz_offset = [redacted]
set tz_automatic_dst = [redacted]
set vtx_band = [redacted]
set vtx_channel = [redacted]
set vtx_low_power_disarm = ON

# mixer_profile
mixer_profile 1

set platform_type = ROVER
set model_preview_type = 31
set motorstop_on_low = ON

# Mixer: motor mixer

mmix reset

mmix 0  1.000  0.000  0.000  0.000

# Mixer: servo mixer
smix reset

smix 0 3 2 100 0 -1

# profile
profile 1

set fw_p_pitch = 0
set fw_i_pitch = 0
set fw_ff_pitch = 3
set fw_p_roll = 0
set fw_i_roll = 0
set fw_ff_roll = 0
set fw_p_yaw = 36
set fw_i_yaw = 40
set pidsum_limit_yaw = 500
set nav_fw_pos_hdg_p = 60
set rc_expo = 0
set rc_yaw_expo = 0
set manual_rc_expo = 0
set manual_rc_yaw_expo = 0

# battery_profile
battery_profile 1

set nav_fw_cruise_thr = 1624
set nav_fw_min_thr = 1550
set nav_fw_pitch2thr = 30

# save configuration
save

# end the command batch
batch end
packetpilot commented 5 months ago

I've since set up a couple other rover configs on a different FC than the two I'd been using before (this time an older F411-Wing), always w/ a single motor output (on the standard S1 pad), sometimes w/ a DSHOT-capable BL ESC and other times with a "standard" PWM ESC.

In all cases I've experienced thus far, arming is possible when connected to the configurator.

As I'd like to begin rover work on larger scale vehicles -- certainly capable of causing harm to humans' ankles and/or causing tib/fib fractures, and of course capable of trashing my workshop -- hopes are high that I won't need to do one of the following "safety workarounds" in order to have total peace-of-mind when popping a cable into the USB port, especially since some FCs (such as the F411-Wing) lack 4v5 (USB-sourced) Vcc to any UARTS, thus going hot with the "flight" pack for any peripherals to be powered on during configurator use.

Safety Workaround Options I can think of

(for "larger" potentially destructive vehicles, ranked from least to most inconvenient imho)

This may seem a bit overboard, but I once lost a fingertip to a sailplane prop. For now I can work with smaller & lighter vehicles but I have hopes of working on 1:6 and 1:7 scale projects rather soon.

I have zero experience with RC boats, but the thought of an air boat spinning a big prop or two scares me.

sensei-hacker commented 5 months ago

This may seem a bit overboard

That doesn't seem overboard to me That seems to me like basic common sense. The INAV docs, and Configurator itself, say several times to remove props when working on the bench. That's been a basic safety procedure since I started flying in 1982. I think the 0.49 Cox control line models had that as a big warning with this symbol ⚠️ and multiple exclamation marks.

The flight controller can't arm with Configurator open. Which doesn't necessarily mean a powered ESC can't power a motor.

In particular if you have an ESC set to bidirectional mode connected to a servo output, that can be an issue.

You listed several different options. If you want double EXTRA safety, the "weak link / strong link" approach is used in the most safety critical systems, like special weapons. This approach requires that for the system to activate, a small/ weak thing has to be in the active position and that is chained to a big / strong thing. So maybe the pinion is held in place by a strong piece. That in turn is held in place by something weak. Kinda like the small cotter pin that holds the heavy pin for a tow hitch. Gravity or a small spring makes the strong piece pop out unless the weak piece is holding it.

Activating it requires BOTH putting the heavy piece into position AND holding it there with the weak piece.

The idea there is if you drop it or there is some other strong force applied it, it will break the weak piece. On the other hand, small forces that could move the weak piece without breaking it won't be strong enough to engage the strong piece.

In this way, no matter if something collides with it, or random monkeys / four year old kids do random things, it won't go active.

packetpilot commented 5 months ago

I just read the opening comment from @joshfisk3 and I'll admit, I hadn't before. While my case isn't perfectly aligned with his, my case certainly aligns perfectly with the title of this issue.

That doesn't seem overboard to me That seems to me like basic common sense.

Certainly it is common sense in very many circumstances, but there's (at least) one case where I'd argue it isn't common sense at all: simply checking in the modes tab that the current radio in your hands (many of us use many radios) is toggling modes as expected.

I'll do my best to, at some point soon, demonstrate in some way that, at least on my read, this assertion is incorrect in certain circumstances, such as rovers with bidirectional motors:

The flight controller can't arm with Configurator open.

The basis for contesting your assertion is the all caps ARMED status at the bottom of the configurator UI.

In particular if you have an ESC set to bidirectional mode connected to a servo output, that can be an issue.

If you mean servo output in the context of the mixer, I've never done this. If you mean servo output in the context of the board, I suppose it's worth asking whether S1 (and S2, which I've never used in a rover context) is(/are) servo outputs: image

Your response is appreciated and certainly valid overall, although I do fear that it may present (to others including maintainers/stakeholdersas) as a basis for a "WONTFIX" outcome or a PEBCAK tag when, at least imho, it warrants attention. (not for me -- I know to expect this -- but with the MT12 recently launched, I'd wager some long-time users of inav will soon be doing their first rover project.)

sensei-hacker commented 5 months ago

@packetpilot

The basis for contesting your assertion is the all caps ARMED status at the bottom of the configurator UI.

Yep, you're right. I stand corrected.

MrD-RC commented 5 months ago

Are you using RC Throttle or Stabilised Throttle in the mixer?

RC Throttle is pure input from the transmitter. If you want any arming protection on this. You must do it on the transmitter. It will also not automatically adjust the throttle with navigation modes. You will need to control it manually.

Stabilised Throttle has input from INAV. Therefore it will obey the arming switch and automatically adjust the throttle in navigation modes.

I don’t see any issues with allowing the motors to arm, while connected to Configurator. Unless using RC Throttle (in which case, all safety considerations lay exclusively with the operator). You have to explicitly tell INAV to arm. A lot of the time, that request will be denied, due to not enough satellites or other safety tests failing. Meaning that to arm it will require a forced arm. Either way. The user is requesting that the craft arm. Before doing so, they should remove props, put the rover on blocks, or take whatever steps are necessary to ensure their craft is safe.

packetpilot commented 5 months ago

Are you using RC Throttle or Stabilised Throttle in the mixer?

[edited to add this missing line break] The mixer (at least in the configurator UI) does not make this clear, at least to me, since unlike the servo mixer, the motor mixer above it does not provide options for RC or Stabilised throttle.

I am assuming though it's the Stabilised variety, since I cannot produce any motor output unless the FC allows me to (armed, and in my cases, satellite threshold, which I sometimes leave at six, other times increase to eight).

I don’t see any issues with allowing the motors to arm, while connected to Configurator.

I could agree with your position if and only if such arming capability were consistent across all craft types (and, in my experience, it isn't). Should such a condition come across as unreasonable, I'd appreciate understanding how.

(By the way, big fan of your videos!)

packetpilot commented 5 months ago

If it'd make sense for me to open a distinct issue with a title such as "arming possible while connected to configurator on (bidirectional*) rovers/boats," I'd be glad to, just lmk. In my haste last week when searching prior to opening a new issue, I thought for sure the title meant it was a great match for my own scenario and, as I realized last night, the particulars described by the OP (👻) are not a match.

*I'm unsure if this applies only to bidirectional configurations or not, since all the rover configs I've done across my three wing FCs have involved bidirectional motors.

DzikuVx commented 5 months ago

Arming with Configurator connected is possible, always was possible and will be possible. The reason is quite simple: INAV allows MSP protocol to configure flight parameters during flight. This includes usages like position update, configuration updates as well as using MSP for telemetry. Basic safety precautions say that you have to be careful when battery connected and props installed. The fact that BF blocks arming when MSP connected does not mean INAV have to do it the same way. BF lacks some of the use cases INAV offers

MrD-RC commented 5 months ago

Are you using RC Throttle or Stabilised Throttle in the mixer?

The mixer (at least in the configurator UI) does not make this clear, at least to me, since unlike the servo mixer, the motor mixer above it does not provide options for RC or Stabilised throttle.

I am assuming though it's the Stabilised variety, since I cannot produce any motor output unless the FC allows me to (armed, and in my cases, satellite threshold, which I sometimes leave at six, other times increase to eight).

Sorry, I was thinking of using a servo output for the motor. In which case it would be in the servo mixer. I know some folks use this for rovers too.

If it’s using the motor mixer. It will definitely be tied to the arming switch. So I don’t see a problem at all. If you arm the craft, you should expect the motors to work.

I don’t see any issues with allowing the motors to arm, while connected to Configurator.

I could agree with your position if and only if such arming capability were consistent across all craft types (and, in my experience, it isn't). Should such a condition come across as unreasonable, I'd appreciate understanding how.

(By the way, big fan of your videos!)

There should be no difference in arming between craft types. You will need a switched arm mode. If not, it will not arm unless you make some specific changes in the CLI (there is a setting to automatically arm on throttle up). But these are not enabled by default, and should be used with caution.

Thanks for the support 👍🏻

packetpilot commented 5 months ago

Apologies for my confusion; I'd like to think, in a world where this issue hadn't already existed, I'd have read up to make sure what I was describing was not just a case of "works as designed" as an issue.

On Sat, Jan 27, 2024, 5:39 AM Darren Lines @.***> wrote:

Are you using RC Throttle or Stabilised Throttle in the mixer?

The mixer (at least in the configurator UI) does not make this clear, at least to me, since unlike the servo mixer, the motor mixer above it does not provide options for RC or Stabilised throttle.

I am assuming though it's the Stabilised variety, since I cannot produce any motor output unless the FC allows me to (armed, and in my cases, satellite threshold, which I sometimes leave at six, other times increase to eight).

Sorry, I was thinking of using a servo output for the motor. In which case it would be in the servo mixer. I know some folks use this for rovers too.

If it’s using the motor mixer. It will definitely be tied to the arming switch. So I don’t see a problem at all. If you arm the craft, you should expect the motors to work.

I don’t see any issues with allowing the motors to arm, while connected to Configurator.

I could agree with your position if and only if such arming capability were consistent across all craft types (and, in my experience, it isn't). Should such a condition come across as unreasonable, I'd appreciate understanding how.

(By the way, big fan of your videos!)

There should be no difference in arming between craft types. You will need a switched arm mode. If not, it will not arm unless you make some specific changes in the CLI (there is a setting to automatically arm on throttle up). But these are not enabled by default, and should be used with caution.

Thanks for the support 👍🏻

— Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav-configurator/issues/1744#issuecomment-1913110797, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALH4BWIPBVOWLBJM7W6GLDYQTKNBAVCNFSM6AAAAAAWIIH2Q2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGEYTANZZG4 . You are receiving this because you were mentioned.Message ID: @.***>