It flies!

[GoFaster]

It happened very quickly, the battery alarm beeping only added to my mental confusion.
It's set to 3.7V/cell so I still had reserve electrons remaining.
I had just tested a couple of mission flights and took off in manual mode, got off the ground and mashed the throttle all the way. As best as I can tell, one or more of the motors clipped in response to my request for throttle and had no headroom left to correct. You can see in the beginning of the vid that it was a little windy.

If this is the case, perhaps throttle stick at full should provide less than MAX_MOTOR_PWM parameter (can't remember what the exact param name is) so there is a cushion for correction. I haven't looked at the code yet, but I am guessing that the attitude controller adds thrust to the low side? Perhaps in the case where the low side motor is at already max PWM, to reduce motor rpm on the high side as a self-preservation strategy?

Anyway, no apparent damage except when I stepped on it and broke the landing gear. The saw grass and bulrushes cushioned the impact but is so thick and tall than I didn't see it until I stood on it LOL.
I'm glad it veered to the right instead of backwards towards the parking area.
The gimbal stabilization is very fast!

[chschmid]

Morning Felix

I happy for you that the damage is assessable. To avoid low batt issues I am always using an external capacity tool.

cockpit_standalone.jpg (17.87 KiB) Viewed 11467 times

I use the Cockpit in all my planes and helis and it never failed so far.

Best
Christof

[Max]

Well, knowing your battery is low and actually doing something about it are two entirely different things...

Felix, I think you're right, the motor outputs are being increased up the maximum, with no decrease of the opposite motor(s) in case MOT_MAX is reached. At least that's how is looks in motors.c -> motorsCommands() which is called from control.c. Does seem a bit "oversimplified."

Also, probably unrelated to this issue, but I noticed that in motors.c it is scaling the output based on current vs. expected battery voltage, which is calculated based on determined battery cell count. I forget, did you resolve your cell count issue by adding the missing resistor?

-Max

[GoFaster]

@Christof, thanks for the suggestion. That is a nice piece of kit. My lipo alarm went off because the voltage sagged to the setpoint point of 3.7V/cell when I gave it full throttle just after liftoff.
Doing a more thorough inspection, it seems that one of the motor has bad bearings. I don't know if it was pre-existing or a result of the crash.
I will have to look at an earlier log of a PosHold hover in calm air to see if it that motor was already working harder.

@Max, yes I added the missing resistor and cell count is being detected correctly now. Pack voltage isn't accurate until it drops below 15V so I haven't bothered to perform the discharge curve calibration. At 15V the divider puts out 3.3V which is the ref/max value of the ADC input.

Grounded for the moment so I took the opportunity to do a couple of Calibsos. Running the calcs again to see if my strange yaw issues go away.
- Felix

[GoFaster]

I wonder if in the motor mixing table, setting throttle to less than 100% will accomplish that - leaving a cushion for roll/pitch/yaw corrections from the attitude controller.

[GoFaster]

Back in the air after the swamp plop. After a thorough inspection, I replaced one ESC that was running hotter than the others. Then I recalibrated all 4 ESC's simultaneously (1000us - 1950us). Also I took the opportunity to do another dynamic calibration and rerun the calcs. Slightly better MAE's (0.06x -> 0.05x). Uploaded the resulting params to the AQ.

After making sure the new params fly properly, I did some short mission tests in my yard.
When the waypoint POI is set to -0 or negative value (yaw orientation relative to course heading, whereas +0 or positive value means absolute compass orientation), I still get the yaw hunting when a waypoint is reached. (I'm still trying to get used to the plus and minus 0 )
See WP test 2 video from a few posts above which shows what happens when the waypoint is reached.

When the POI is set to a +0, there is no hunting. Same if for example, I set POI for WP1 to +90 and POI for WP2 to +270, the yaws to the compass directions are solid and purposeful.

Still trying to figure out why by looking at the logs and digging into the code.
Here is a log from one of my backyard test flight for reference.
The plots are of RC_CH5 (Man/PosHold/Mission select), MOTOR_YAW and IMU_MAG_X/Y/Z.
There are 3 mission flights in the log. Simple 2 waypoint mission. The values are 0.0 relative altitude, 5s loiter, 2.5ms speed. The only difference being the values of POI heading.
Each time, I am in PosHold then switch to Mission.

Mission 1:
WP1 POI heading 90.0 (absolute compass orientation).
WP2 POI heading 270.0
You can see that the two yaws are solid
(Each consecutive screenshot zooms into the boxed area)

Mission 2:
WP1 and WP2 POI heading set to -0.0 (relative to course heading)
There is lot of yaw hunting when it gets to each of the waypoints. At WP1, it eventually points to the correct direction before going on to WP2. Upon reaching WP2, it stays there and hunts around until I switch back to PosHold.

Mission 3:
WP1 POI sent to -270.0 (relative to course heading)
WP2 POI sent to -90.0
Same hunting behaviour.
No zoomed screenshots.

If it was mag noise, I would be thought that I'd get hunting behaviour for the absolute compass direction POI settings too.
I'd be grateful for any ideas.

- Felix

[bn999]

[GoFaster]

<face palm>

I forgot, without a fluxgate compass or something, it doesn't know the compass direction unless the copter is moving.
It is behaving as it should.

Perhaps a change so that upon reaching the WP; if loiter >0, a relative orientation should switch to absolute or PosHold state while the clock runs down - until the next leg is commenced?

[bn999]

It knows perfectly well what direction it is pointing while holding position. But think about the question: When you are hovering directly over your WP (which is your POI also) which heading should it hold?

Instead of changing it's behavior, you could add a second WP, the same as the first but with an absolute heading.

[GoFaster]

Edit:
So once it has arrived at a WP and in loiter, it's still in "trying to get to the WP" mode, making micro corrections with different course headings - hence the yawing to follow the relative bearing.

/Edit:

Sorry, what I trying to say that once it has arrived at a waypoint and if there is a loiter time, it should hold last heading.
Zeroing the loiter time and adding a WP on top of that with desired loiter and absolute heading would work. But the GCS should let us know the course bearing from the previous leg so I can easily determine the absolute bearing to enter.