Arkflow and Z drop

Unfortunately because of an NDA, I can’t show the joystick but what we’re really trying to achieve here is a pwm signal of 1500-1515 at RC3 center stick, correct?

@RT22,

Txs for the log. The RCIN.C3 value is 1515 which is close enough.

The PILOT_THR_BHV parameter won’t have any effect on the PWM from the throttle.

Yes, the PWM should be in these ranges depending upon the throttle position.

throttle pulled low: pwm = 1000 ~ 1100
throttle centered: pwm = 1480 ~ 1520
throttle high: pwm = 1900 ~ 2000

OK, if you can’t show us a video that’s fine but you should be able to reproduce yourself what I’ve shown in the video. If the throttle stick movements match the green lines in MP like I’ve shown then it should be fine.

Also to be clear, the joystick “driver” is built into the Ground station. The ground station is responsible for reading in the values from the joystick using some Windows driver and it then converts that to a PWM value and sends it to AP. So the joystick configuration is held within the GCS. If you’re changing between MP, QGC, etc… that’ll affect what is sent to AP. Just because it works on MP or works on QGC, that doesn’t mean it will work on the closed source GCS you’ve got.

So I think the best we can do here is show it works with MP or QGC and then if the custom GCS doesn’t work then you’ll have to bring it up with whomever developed it.

Thank you. I think we’re ready for another test flight when the props come in. Maybe I’ll find some other ones laying around tomorrow…

So to summarize, if this works, it was fixed by 1: Unchecking center stick as zero in QGC and 2: Adjusting RC3_TRIM in MP?

@RT22,

Yes, if the joystick is connected to the QGC ground station then it is important that QGC’s “Full down stick is zero throttle” is checked.

Yes, the ArduPilot flight code parameter, RC3_TRIM, should be set to about 1500. It’s not immediately clear which ground stations use this parameter as part of their joystick drive code but probably MP and maybe QGC.

If the joystick doesn’t work with the closed source GCS, you’ll have to bring that up with those developers.

1 Like

If you want to validate if these changes fixes your issue, before receiving your new props, there is a way. Yes, it’s rudimentary, but it works! I’ve done it multiple times when debugging custom flight modes.

1- Put drone on ground
2- Turn on transmitter and drone.
3- Wait for drone to be ready to arm. Switch to Loiter or AltHold.
4- Arm drone (WITHOUT PROPS)
5- Bring throttle stick to center. there will probably be a bump in RPM.
6- With a colleague, one of you increase the throttle stick from 50% (center) to 60 or 70%. At the same time, the other one of you lifts up the drone slowly.
7- Try not to block the ArkFlow measurements while doing this.
8- Bring throttle back to center (50%), and stop rising the drone, keep it at a steady altitude.
9- Lower the throttle to 40% and descend then drone until touchdown
10- Disarm.

Coordination between the both of you is important. Then in the logs, you should be able to see the desired altitude increase at the same time as the actual altitude, and both should remain steady when you were “hovering”, and then both should decrease at the same time before touchdown. I like using PSCD.PD and PSCD.TPD, which are the logged position and target position for the “Down” direction of the Position Controller (PSC). You can also look at PSCD.VD and DVD (velocity and desired velocity).
NOTE: In PSCD, negative values means “going up”. The reference frame is flipped compared to CTUN. So you can probably keep using CTUN if you’re more comfortable with that.

It’s normal that the desired altitude and actual altitude diverge, since it is hard to manually lift the drone at the velocity commanded by your throttle inputs of 60% and 40%. You might get a “Thrust loss” warning, but that’s okay.

Other note: Don’t take too long to do this test. Some motors don’t enjoy turning no-load for long durations, I’ve had a few heat up (they obviously don’t receive any airflow). Keep the whole test under 1 minute. 20-30 seconds should be perfect.

I did that with my companion computer.

Alright, the props wouldn’t arrive until Monday and I couldn’t wait.

So I threw on some 18.5" KDE props and attempted Loiter mode again and…

It holds position! Quite well I must say.

Special thanks to rmackay9, bobzwik, and Jai.Gay for catching something I was missing entirely.

3 Likes

@RT22,

Great stuff and thanks for the feedback!

1 Like