Hello @tridge
Thank you very much for all you and all developers effort to make this system better and better.
About this issue:
Could you please clarify, how this works?
My key question is how to callibrate this battery remaining percentage ??
The reason of my question is, I found “problem or issue” when using Cuav Nora PM lite using CAN , that is supllied by CUAV.
I did posting this issue some times ago. The problem was, Mission planner display the remaining battery percentage WRONGLY. Eventhought Voltage and current display are correct… Also battery consumed was correct (in MAH). This is very confusing. So the battery remaining percentage is much lower than it should be.
Thank you…
@tridge, I just received a support request for EKF’s not aligning and preventing arming on the beta 4 firmware. Maybe this is unrelated to the beta, but the log is attached here. I flew the aircraft without prearm issues just prior to this, so I’m not sure what the cause is. My flight was totally successful, although I did have to reassign the trigger and feedback servo_function parameters to -1 to get the camera working normally. That will be helpful for the release notes when 4.2 goes live.
Hello cool developer, it’s great to see you continue to develop.
Q_ENABLE = 1
Q_FRAME_CLASS = 1
Q_FRAME_TYPE = 16
Q_TILT_TYPE = 2
Q_TILT_MASK = 8:
Q_TAILSIT_ENABLE = 0
Q_TILT_YAW_ANGLE = 0
Function = 39 Please develop the tailtilt servo to respond to QSTABILIZE as well.
In QSTABILIZE mode, the tailtilt servo does not respond to the rudder stick.
Can you make the reaction visible on the Servo output screen when armed?
I think you may be right about a motor reversal. It looks like the left motor went into reverse at the same time that you got an ISR flood internal error. @andyp1per can you have a look at this?
The sequence seems to be:
two ESCs running normally with DShot150, on PWM(5) and PWM(6), both giving ESC DShot telemetry. ESCs setup as 3D, to allow for reverse thrust landing
ISR flood on pin 57, the camera feedback pin (on SERVO8)
both ESCs stop reporting telemetry for around 1.5s, battery sensor current draw remains steady during this time
2nd (right) ESC starts reporting telemetry again, then stops, then starts again
1st (left) ESC starts reporting telemetry sporadically, only giving data infrequently, and the aircraft starts to yaw left, ending up spinning at over 1000 degrees/second, which is remarkably fast for a plane of this size (I presume this is a believer?)
I don’t understand the relationship between the ISR flood and the ESC reversal. An ISR flood is an external event, triggering lots of pin toggles, causing us to shut down that interrupt source. Was there some other event that caused both the ISR flood and the motor reversal? Or did the flood somehow impact the ESC?
@Naterater is the aircraft undamaged enough to run ground tests? Do the ESCs/motors still work? Do they operate in the right direction?
Both motors and throttle appear to be commanded to maximum after the loss of telemetry. There is also significantly more vibration after this so it seems likely that was actually happening. Do we know why the motors were asked to go to maximum? There are also a bunch of radio failsafes before the ISR flood and internal error (the internal error is the ISR error it looks like?)
Reverse thrust (barely) used in landing here. Although different firmware and autopilot. I don’t have any automated landings of the plane that crashed, although because of the gentle spin, it actually did little damage. I’ll follow up.
unfortunately that is an old firmware. I was hoping to see what the RawRPM field did with reverse thrust, to see if it went negative. This old firmware doesn’t log RawRPM.
Can you do a bench test with some reverse thrust and get a log?
Also, can you try a test where the motors are setup the way way they are setup in the crash, then you disconnect the signal wire from the ESC so the DShot pulses stop. I’d like to know how long the motors keep running for after the pulses stop.
Hi, We are seeing very bad behavior in the flight controller and wonder if there is a fix? Basically we are seeing large ~5 deg pitch changes with large changes in Throttle in VTOL aircraft. I don’t think this problem is limited to Plane Beta 4.2.
Exemplifying this is a Convergence SITL model based on Plane Beta 4.2. Here we are seeing ± 5deg pitch changes with large changes ~ 70% in throttle. Here is the log file of our test, and a picture of the pitch (red), DesPitch (green), and throttle signals (blue):
In comparison, the stock mini Convergence, or any quadcopter that comes with Realflight 9.5 does not show any affects of throttle on pitch. Since the flight control algorithm is different. This indicates the effect is being created by the Ardupilot flight control algorithm.
I am developing a large RC controlled tricopter VTOL using Arduplane and we are seeing ~ 5 deg pitch changes with large changes in throttle, making the vehicle very hard to handle and has crashed many times. Here are two videos of the vehicle being tested. The first has PID (a lot more P than I) tuning, and the 2nd has IPD (a lot more I than P):
Here is a link to see the vehicle and details about its construction:
I have also developed a CAD model of the vehicle and have it flying in RealFlight 7.5, but it does not use a flight controller and flies very well. The reason is that the vehicle weighs 200 lbs and is the size of a large station wagon, which has high rotational inertia, and large stabilizing gyroscopic effects from the 32in props. The key point is that the pitch does not change with large throttle changes. Here is a link to see the vehicle flying in the simulator:
We are now considering taking out the flight controller because the vehicle is too hard to handle with Throttle causing Pitch changes.
