Have you confirmed that battery voltage monitoring is working?
EDIT: I didnt ask for a .bin log because you dont have an SDCARD if I am correct
So you’d need to see battery voltage reading correctly on the screen while connected to MissionPlanner via USB cable
Yes. And to do the test, I set the BATT_LOW_VOLT = 22.2 and the BATT_FS_LOW = 1 which is land. Hover the copter until the battery voltage dropped to 22.2. And yes after 10 seconds, the copter landed. So the battery monitoring is working as expected. It’s only the LED indicator that does not indicate when the battery voltage drops below the threshold of 22.2V. I can also see the battery voltage in Mission Planner.
This FC does not have an SD card but it can store log files. I’m attaching one here if it will help.
2022-11-01 16-38-38.bin (777.7 KB)
Here’s the battery voltage from the Log.
Yes, I couldnt see anything really wrong. I’ll think about it more, try to rig up the LEDs on another aircraft here maybe.
Thanks Shawn. I am really scratching my head on this. I think I’ve set all the required parameters. I hope you can find an answer to this issue.
I dont think so - are the LED strips working like a normal flight controller integrated LED? (except for the voltage)
https://ardupilot.org/copter/docs/common-leds-pixhawk.html#rgb-leds
Yes, the LED’s indicates when the emergency switch is ON/OFF and when the motors are Armed/Disarmed. Its the other indicators like low voltage, GPS Lock etc that does not work.
Can somebody confirm if Copter-4.3.0-beta4 release supports a Lidar configured to measure vertical distance.
I installed one and I can see the vertical distance in mission planner but when I switch to Alt-Hold, the copter does not climb when I put my palm below the sensor. Here’s a video of the lidar bench test. The hieght measured by the lidar is the yellow font at the bottom left of Mission Planner.
Hi @Carlou,
I’m pretty sure that suface tracking still works fine in Copter-4.3.0. If possible could you provide an onboard log with the problem? I tried to look at the video but it’s just not providing as much detail as an onboard log would.
Hi @ Macky
Attached with are the Log and my parameter settings uploaded in Google drive because the log size has exceeded the allowable size of this site.
Log
https://drive.google.com/file/d/1Nl3A5ZPmI0ASiZze6B3UGhvcTrQuH2vF/view?usp=sharing
My Parameter settings
https://drive.google.com/file/d/1k5qE_8fYzlPQmnFRBCrdKJ9gYB5I3Jm7/view?usp=sharing
I think this is the log that shows the desired altitude is not tracking with the rangefinder altitude. Or did I interpret it incorrect? Looks like the Lidar is telling the controller that this is my desired altitude but the actual altitude of the controller is erratic (up/down).
This log shows that the controller is tracking with the Barometer and not the Lidar. Or am I expecting too much? What the WIKI say is if the vertical distance is within the Lidar range, it should use the Lidar, otherwise it will use the BARO.
Thanks again for your assistance.
Regards,
Carl
I think I found the problem. I have set MOT_HOVER_LEARN = 2 and it has determined that the MOT_THST_HOVER = 0.3 which is far from ThO. I decided to turn off MOT_HOVER_LEARN and set MOT_THST_HOVER = 0.2. This time Alt-Hold is better. But I am not able to set MOT_THST_HOVER lower than 0.2 to align with ThO. Is there a way to set MOT_THST_HOVER lower than 0.2 to align it with ThO?
Please ignore this error. I found what is the root cause. The message that is suppose to be displayed is Mode change to AUTOTUNE failed: initialisation failed. But it was broken down into two lines and only the second line was displayed in the HUD which meslead me thinking that the HUD is prompting me something about the LED. I think the request must be: Can you fix the display of message to the HUD so that it shows everything and not only a portion of the message. Quite very confusing.
OK, so I think you’ve resolved the issues you were seeing but a few extra points in any case:
Thanks Mackay. That message regarding the autotune initialisation failed got me for how many days.
I have an operational question if you may. When I plug in the battery, It takes too much time to wait for the motor to Arm. So I thougth it might be the GPS so I went and untick it in the ARMING_CHECK parameter. But it did not really solve the problem. Is there a way to vew all the checks that the flight controller is doing before allowing the motors to Arm? I found the following Arming Checks in trhe WIKI:
The bold once can be easily checked. The rest, I don’t know where to look. Can you point out how to investyigate those? When GPS is included in teh ARMING_CHECK, what do we need to look at. I read somewhere that having a 3DFix and the number of SATS is not enough. What is the value of HDOP so that the motors can be armed? Are there other GPS parameters being validated?
Regards,
Carlou
Hi @Carlou,
I suspect you’re right that it is the GPS, or more precisely it is taking time for the EKF to calculate the vehicle’s position. This can take time if the position from the GPS is not very accurate for some reason (perhaps there is radio equipment on the drone that is producing EMI in the 1.5GHz range?) or the values from the accelerometer, gyro or barometer are moving around too much. This can be because of a bad accelerometer calibration or perhaps the board needs to heat up. Also be careful not to move the drone while it is doing the gyro calibration – you should see the LEDs flashing red-green-blue.
In general I don’t think that turning off arming checks is a good idea and it probably won’t help. There are a lot of arming checks but they’re also there for a reason. Each one has been added normally after someone crashed their vehicle. It’s best to know about any problems while the vehicle is on the ground. Safety first!
How long is it taking by the way?
Hi @Macky,
Its weekend today in Sydney and its time to go to the flying site and run AutoTune after figuring out all the problems. Wow after the AutoTune, the drone flies better. I should say that this is my first drone and I am starting to love it. Regarding the time it takes to arm the motor, it varies from 3 min to 10 mins. I know the other fliers are already piss waiting for me to finish so they can take their turn. Next week, I will read the WIKI about trying to mitigate those sources of EMI’s. Here’s one of my flight. Apology for the video quality.
https://www.youtube.com/watch?v=RXdW7jbJMXo
The number of SATS detected and HDOP is very good in the area where we fly. And at the end when the battery failsafe triggrers, the return to launch is most of the time perfect or a meter away from the take off point. No complain about that. The Break flight mode is very nice as well. Next week, I may be trying missions.
Again thanks a lot for your help. My regret that I did not by a flight controller with an SD Card so I can run LUA Scripts.
Regards,
Carlou
The normal time it takes from battery plug in to all checks pass is 40 seconds.
There is something wrong with your copter. Do not disable any arming checks. Fix the issues instead
Hi @Lucas,
Yes I want to fix the issue but I don’t know where to start. Any suggestions to look for the root cause would be appreciated.
Regards,
Carlou
Start your own thread with the latest .bin log and detailed description of the issue and details of your copter hardware.
that some new machine
