maybe someone can now tell me where I can shoot a second battery voltage?
I need a second battery indicator in the osd
maybe someone can now tell me where I can shoot a second battery voltage?
I need a second battery indicator in the osd
For example (current sensor is Allegro ACS758LCB-100B with voltage divider to 3,3 V):
BATT2_AMP_OFFSET,1.6668
BATT2_AMP_PERVLT,75.65
BATT2_ARM_MAH,0
BATT2_ARM_VOLT,0
BATT2_CAPACITY,5000
BATT2_CRT_MAH,0
BATT2_CRT_VOLT,0
BATT2_CURR_PIN,15
BATT2_FS_CRT_ACT,0
BATT2_FS_LOW_ACT,0
BATT2_FS_VOLTSRC,0
BATT2_LOW_MAH,0
BATT2_LOW_TIMER,10
BATT2_LOW_VOLT,0
BATT2_MONITOR,4
BATT2_SERIAL_NUM,-1
BATT2_VOLT_MULT,12.08911
BATT2_VOLT_PIN,4
Watch my video only in Russian language: https://www.youtube.com/watch?v=P6vDcpMvtCs
It looks like the maximum number of waypoints have been reduced with Plane 4.0 from the previously known 724. We just run into this as we upgraded our planes from 3.9 to the most recent one and uploaded the same mission what we flew 3 months ago. It gave an error now as it exceeded the max number. Anybody aware of the new limit of waypoints?
ahh, that will be the change for CAN DNA storage. It should be 656 waypoints now.
We intend to increase this again in the future using the ability to use the extra memory available on new boards, plus the ability to overflow to microSD. My apologies for not including this in the release notes.
Dear @tridge ! Thanks a lot for the quick response. I was looking at the code and started to wonder if getting rid of the rally/fence points would do us any good, but I would rather stick with the main branch. We highly hope you are able to utilize the new boards with Cortex®-M7 processor so you should have plenty of space to expand. In the meantime we will just upload the new waypoints in a holding pattern in air.
The key changes to existing behaviour to watch out for in this update
are:
ArduPilot has now switched to it’s own USB IDs for all boards. For most users this won’t cause any change, except they may notice the drop down list of devices in MissionPlanner will have the ArduPilot flight controllers labelled more usefully as “ArduPilot” instead of just “STM32”. If you hit issues on windows please try reinstalling the device drivers from this URL:
https://firmware.ardupilot.org/Tools/MissionPlanner/driver.msi
A bug fix in the format ArduPilot uses to store terrain data means that your flight controller will need to re-download the terrain data onto the sdcard via your GCS. If you fly without a GCS and you use terrain data then please re-download the terrain data you need by setting up a mission when you have internet access and allowing your flight controller to request terrain data from your GCS.
This release adds in the missing hook for the VTOL motor controller on a quadplane to compensate the VTOL gains using your pressure altitude. For most people this will not have a noticible effect, but some users that have tuned their aircraft for high locations may notice a tuning change.
The new compass ordering system in this release gives a lot more
flexibility and should preseve existing configurations and calibrations. If you hit issues then please have a look at the new compass ordering user interface in recent beta releases of MissionPlanner.
Many thanks to everyone who contributed to and tested this release!
Please report test flights here with logs, both good and bad flights.
Happy flying!
Any fix for tkoff mode ?
No changes in takeoff for beta1. I have added the change to ensure it is flying for more than 10s before starting the circle ready for beta2.
Are there any other takeoff mode issues I should know about?
Only a short but good 10 minute flight with Autostart + FBWA, everything worked perfectly (including the thermals ). There is the log file: Anmelden – MagentaCLOUD
Many thanks to Tridge and everyone who contributed.
Rolf
Thanks Rolf, much appreciated!
RTL_CLIMB_MIN is ignored if craft is in any quadmode, also if within RTL radius, where it should just got directly to QRTL?
…Just checking.
Nice feature BTW Andrews. Thank you.
right, it is fixed wing only and disabled by default anyway. It is for FPV pilots really.
Beta 4.06 on Matek F765 in a MiniTalon.
Flew a 15 mile loop which took 23 minutes. Used terrain following up and over a butte in cruz mode - no issues. Used the terrain tiles I downloaded with the python script. Calibrated and used a new airspeed sensor - worked good. Tossed the MT with auto takeoff followed with just a rally point while I got ready to fly manually in FBWA - all good. Downloaded log files and all looks great. Did get a RTL after I flew to low down a gully and RSSI dropped to zero. Circle followed by RTL kicked in and brought the MT back up to height and the MT turned to my rally point. Flew home with cruz and fbwa and all is good.
Thanks Don, much appreciated!
I have a issue with a PixHawk 2.4.8 board.
After I upload the ArduPlane V4.06beta1 the LED indicator (4 color LED) is not working anymore.
I reinstall the previous stable version but not change. It also doesn´t matter if I choose Pixhawk1 or FMUV3.
All functions on the board seems ok - just the LED is off. Connection to the mission planer is also working fine.
The board has a STM32F426VIT6 and a 32F100 CPU. So it is a ARM Cortex M4 with 2048kB RAM.
Would be nice to get the LED back working.
Thanks, Markus
Hi, would you recommed using BLHeli escs for a twin motor fixed wing with Arduplane? I didn’t find much information or experiences on this and if there are any disadvantages on using BLHEli escs instead of airplane ones.
Thanks!
They work well for me!
I’ve been using a T-Motor F45A 3-6S BLHeli_32 ESC for about 3 months now in a Mini-Talon - no issues and saves a lot of weight.