My current issue is the PWM signal on Pixhawk port is not the same on test run of motors on the ground. What are the options to fix it? Which part of ardupilot software to look for to investigate this behavior?
I built my custom drone and perform 3 test launches. On the 2nd launch I lost control of the drone and it hit the ground from 1.5 meters. On the 3rd launch 1 motor from 4 gives lower revolutions per minute (RPM) which wasn’t the issue on the 1st and 2nd launches. Investigating the issue shown:
it gives lower RPM rather than others and stops a few earlier rather than others motors
voltage from PDB on ESC is the same on all 4 motors
switching engines across ESCs makes a different engine works slowly → it is not the issue with motor itself
switching signal wire from one port to another on Pixhawk fix an issue on “bad” motors and creates the issue on normal one → it is not an issue with pixhawk itself
This initial investigation shown the issue is in hardware or\and software part of ArduPilot. The next investigation steps shown:
the oscilloscope everywhere MAIN OUT signal pins shows 3.3 volts at peak and 1.6 volts as an average
length of “logical one” varies from 1.8 ms to 1.2 ms: when throttle is applied, the length of the logical one of the PWM is extended, and the logical minus - refers to narrows - this is clearly noticeable on the first motor, not bad on the fourth, but on the second and third the changes are ambiguous
SERVOx parameters in the mission planner show good default values
I switched the motors to the next four channels – the situation is similar: outputs 1 and 4 give a PWM of 1.5 ms, and 2 and 3 give a PWM of 1 ms. Now the problematic motors is 1 motors instead of 2nd (by the way, they are both CCV motors)
Altogether it gives me an idea unlikely it is a hardware issue: damage all 8 pins where 4 of them wasn’t in use during flight has minor probability. From software part the accel and compass could suffer after a crash, however re-calibration didn’t solve the issue.
Now I need to go deeper into software and understand how mixer (?) behave when adjusting thurst power on different motors.
MissionPlaner should have an option to export logs, but I haven’t found the option to do it yet.
I will appreciate your assistance in tracking down and solving this issue.
Most of you posted is irrelevant. Use Mission Planners Motor Test feature to test motors for proper order and direction. Only using this tool can you determine if they are spinning the same at the same throttle input.
Thanks, Dave! I will check it, but the RPM decrease in one motor is noticeable even to the naked eye. The main cause behind starting investigate this is drone failed to rise up vertically on the 3rd launch, it is skewed to the one of the axis. It happens because of the less thurst on this axis.
Just finished motors tests. They are all working, but it is not give me necessary information I was looking for.
I attached the screen shoort: I am running it on Linux, so may be a part of UI Dave was refered to is hidden.
Dave, could you please elaborate what do imply by asking ti use test motors feature first? I want to emphasize that FC gives less thurst on the one of the motors which it doesn’t allow to get it up vertically – it wasn’t an issue on the first two test launches.
LLMs (with possible exception of models specially trained on expert knowledge database) are known to provide inaccurate or outright dangerous troubleshooting steps. We can’t help you without seeing the .bin log files from your vehicle, preferably showing both the successful flight and the one with problem.
If you are using PWM ESCs they likely need to be calibrated as described on the wiki or in AMC process documentation.
I am experiencing issues to get logs from the FC right now. I will come back when I try it from WIndows machine or get sd card adapter to extract it directly from SD card.
Regarding ESC calibration – I think I already done it. I can not say confidently, because all process of assembling and configuring drone was scattered across a few months due my workload on different project and time of delivery of new components from China. The main argument for this is all motors are starting at the same time when I rise gas stick.
Another interesting observation is I did again motor check right now and do not observe the issue of low RPM (earlier this morning I didn’t notice it due lack of time)! However, when I use radio transmitter I still see this issue. Which give me a reason to think something might not correct at the pult settings itself!
Testing with the transmitter will produce the result you are witnessing. It’s not an “issue”, it’s expected behavior. When you used Motor Test did you confirm the Motor Order and Direction were correct for the Frame Type you have chosen?
Yes, motors order and direction were correct. It wasn’t an issue at all – it was setup right before the 1st trial flight and on the all three trial flights it behaved right.
May I ask you to elaborate the topic with transmitter? I don’t think I witnessed this behavior on the first two flights.
If the motors are turning at the same speed with the same throttle % using Motor Test then it’s likely a configuration problem if the craft wants to flip on take-off. Usually this is due to the wrong motor order or direction. And this is usually because of a misunderstanding on what motors should run when the A-D buttons are pressed in Motor Test.
For example if you are using Quad-X Frame type and class:
I just have got logs from FC, but there are 500 bin files under the same date 01-10-1980 and 1.8gb of tlog file. It would be difficult to find one with the 2nd trial flight. So I just run the motors over RC transmitter and extract the last log file.
It is still 10 mb zip archive which I pud of gdrive.
Thank you for drawing attention to this. Indeed it is subtle topic and thanks to ArduPilot team to make it clear over wiki.
However, I did a good job at beginning to follow all must have preparations described in the wiki and the frame and motors (and props order, and MAIN OUT pins order!) are setup correctly.
I just want to draw attention to on the first two trial flights all motors works correctly and only on 3rd trial flight one of the motors has started misbehave. And floating across pins! e.g. 2 and 6 ports on MAIN OUT.
How are you performing this test? On the bench? If so it’s meaningless.
In any case there is nothing to see in this log. No throttle outputs and no motor outputs.
Disable LOG_REPLAY no reason to enable that.
Disable LOD_DISARMED No wonder you have 500 logs. If it arms you don’t need this.
Set the LOG_BITMASK back to default.
Yes, it was on the bench with unmounted props. I don’t have a connection with ground station yet except over USB. Do you need a log with this test when it is on the bench? I still could reproduce the issue even on the bench.
Done. I disabled this two options. Anything yet should be disabled?
This is meaningless. I don’t need to keep repeating this. It’s operating in open loop when the craft is not flying (no feedback from sensors) so the motor outputs can be rather random.
Set the LOG_BITMASK back to default (180222), not checking every box.
Re-run accelerometer calibration and make another take-off attempt.
Not really. After a proper accelerometer calibration make sure the vehicle is level in Mission Planners HUD when the craft is level on the bench. If not, perform a “Calibrate Level” (middle button) while it is level and confirm it’s now level in the HUD.
Perform a radio calibration again and make sure the transmitter trims are centered and then never touch them again for any reason.
Another reason for installing a GPS module is relying solely on the FC’s internal compass is a bad idea. They are prone to interference. In many cases these are disabled and only the external compass used.
And, don’t enable a feature in the parameters unless you know what it’s doing. Checking all the boxes for a parameter is almost never the right thing to do.
However, after initial calibration a while ago it was skewed despite on flat horizontal surface – seems the positions of the controller itself is not on fully horizontal surface. At that time I adjusted this 2 degrees of skew programmatically.
Radio calibration was done previously and has not been touched since then. Trims are centered.
Thanks for details regarding internal compass, I didn’t know about that. I did my best to cope with EMI, but there is no way to check\measure its impact until key signal are passing.
I did my 5th flight an hour ago which ended up with burn-out motor. Anyway for our aim check ESC logs from it should be good enough for investigation.
Update: Here is the video of the last flight. (burn-out motor part is cut off, flight on the minimum power to avoid lost of the control due lack of experience in flights)
Post a link to one (1) .bin log file. No one is going to go thru a folder of files looking for one relative to the issue at hand.
And only had to watch a few seconds of that video (I normally ignore them) to see that you should be giving it more aggressive throttle to get it off the ground. Then hover at 1-2m. Post a link to that log.
And while I don’t suppose you understand what this graph shows it’s evidence of the problem using the Flight Controllers internal compass:
Excuse me for delay in response, only today I have been able to return to this project. May I ask how do you get this plot? I can’t visualize the data:
Got the data. They appears only when subset of params are set. Still I see use use sqrt formula from this params. It would be interesting to know how did you able to input such formula in the log viewer?
I have been learning how to read this plot for a half an hour. Let me just double confirm with you my understanding to make sure we are on the same page.
The sqrt from sum of quads you used gives us length of the vector of magnetic field. In normal condition for my place it should be near 50 nano tesla, although I am near Kursk’s Magnetic anomaly which gives its impact on the magnetic field. However, without turned on motors gauge shows correct orientation. The lack of dimensions on the plot gives comparison to this 50 nano tesla meaningless. Although, this plots still could give some valuable info.
ChatGpt suggest if the plot of the vector acts as a sinus plot, it is clear signal of the inference. In the similar way when one projection on the axis varies from another by twice as large, it is also signal of the inference. In my plot MAG_Z is between -11 to 1120 when another two varies on 500 points between two extreme positions.
The conclusion is inference. The internal compass is prone to magnetic fields cause by PDB and ESCs and there is no way to put them further away from each other. It could be a cause of different thurst on the motors and unstable flight. The solution is to buy external compass and\or
GPS + gyroscopic stabilization (EKF without a strict compass dependency);
In the ArduPilot settings, you can enable “yaw fusion” with priority for GPS and gyro, reducing the influence of the magnetometer.
