It looks like the vehicle was in Acro mode, that was intentional?
In any case, it does look like some kind of configuration error or a mechanical failure although it’s hard to be sure exactly what the issue is. Certainly the pitch forward is not commanded because the desired roll and pitch angles and rates are staying reasonable. The actual pitch rate and actual pitch angle separate from the desired though.
Today I installed version 3.6.0-rc5 on an OmnibusF4-V3 board and everything seems to work but the battery monitor. The board is equiped with a current sensor. How do I set up my Battery Monitor so my flight data show battery voltage and current?
I’ve created an issue and I expect we will fix the defaulting of these pins in a follow up release candidate.
EDIT: these changes were already included in -rc5 so it’s not clear why @Jan_Willem had to set them manually. Jan, you were definitely using -rc5? Is it possible you had changed those parameters before?
I just upgraded from 3.4.4 to 3.6 rc5 and after configuring it, when I connect the battery one motor start while the safety switch led is blinking. Safety switch bottom need new param for work in 3.6?
Auto-Answer: Reflashing again and work
But, i have a new problem testing motors…
Using Pixhawk 2.4.8 (PX4-v2) firmware 3.6.0-rc5 hexa, when i do motor test, only work 4 motors of 6. Parameter FRAME_CLASS=2 and FRAME_TYPE=1, need modify more params or downgrade 3.4.4 and flash again?
I’m running Arducopter V3.6.0-rc5 on an OmnibusF4Pro-V3 board and logging doesn’t seem to work.
With several uSD cards differing in capacity and speed I get the same message: PreArm: Logging Failed.
I’m only able to arm when I disable the arm_check for logging and set my loggin_backend to zero.
Is this a known issue, or did someone succesfully log on this board?
This release (actually latest master) has taken care of my apsync logging issues, thanks for all the work on this. I have been able to do a fair amount of testing with all three of my multirotors and have found no issues so far. All are black cubes running EKF3 and all three IMU’s as well as apsync companion computers, they all fly extremely well. I loaded latest master on my 350 quad and did the entire set up from scratch including a fresh auto tune, flew perfectly.
Thanks to all the developers working on chibiOS integration, looks like a great way to go.
Re the MatekF722 board support. I think this has been asked before but the issue with that board is that it has very little flash space (512K)… too small to fit autonomous flight modes so the user would be stuck with just stabilize, AltHold, etc without some more shrinkage work done on AP. You’re actually the second person to ask this so I might ping Matek and say there is some interest in an F7 board with more flash. My guess is they’re already working on it.
Awesome, thx so much for doing that. I think f722 design is one of best on the market, pity i did not realize it has such a small flash. I run it with betaflight now in 32/16 kHz mode, it is a best fc i had so far.
It is a pity f7 boards are so scarcely represented.
Ps: i see the Omnibus F7 also has 512kb flash - and it is the only f7 fc supported?
on a bit of a different topic - is it possible in 3.6 to make 4 lidars supported by default, not 2? i think it is just a simple definition change somewhere? it just would make sense to get all 4 directions covered for object avoidance - to cover front/rear and top/bottom, sides are not critical and will be in reality covered fine with front/rear modules.
Mateksys replied that they are indeed working on an f7 version of the F405-Wing board and a GPS/compass module to go with it.
We support a number of the f7 Pixhawk family of boards like the Pixhack V5 and I hear Hex has one or two new Cubes coming with the F7 in it. I think Holybro’s KakuteF7 is also supported now although we don’t seem to have a flight controller page for it.
Thank you and sorry for late reply. I was fighting with my quad to figure out what is going on and being as noob as I am, it is a bit overwhelming.
I did fly this quad with PX4 fw, however when change to ArduPilot, I had an issue where motor test didn’t work but I did check order and direction of motors.
I have found one broken soldering on one of my motors so I’m not sure if that has anything to do with my flip flop.
Still having issues with the above on this new build , I must be missing something with configuration of Throttle endpoints or something.
Last I was told Autotune stopped after seeing slight YAW on channel 4 maybe due to incorrect midpoint…
I have ESC’s set as this
Radio is set MIN 1001 -> 1999 MAX 1500 Center
The ESC calibration page of Mission planner I have set
BLHeli_32 ESC in OneShot125
Pixhawk 2.1 cube
I’ve attached a telemetry log of a very short flight trying to Autotune for PITCH only however, again, it did not seem to start and switched back to AltHold.
Tell me what Im missing or why Autotune does not engage?2018-7-15-sfrjames.tlog (690.2 KB)
To try and determine if this is a regular setup issue vs a Copter-3.6 issue, could could you try using Copter-3.5.7 instead? If that works then we know it’s a change in Copter-3.6. If it doesn’t then we can be more sure that it’s a configuration issue.
The reason I’m keen to separate the issue from a regular support issue is that with so many users, if we mix in regular support with the Copter-3.6 beta testing it makes the task of getting the new version out much much larger and it will take longer as well.
Re the KakuteF7, I think support has just been added for the KakuteF7 but only the bleeding edge “latest” version of ArduPilot has it. I’m basing this on someone in the AP/ChibiOS gitter channel talking about it and finding this directory.
I suspect we will create a wiki page for it soon and maybe the next release candidate will include support for this board. In all honesty, the ChibiOS stuff is moving so fast even I’m having a hard time keeping up so I’ll check with @tridge.