Is this the same as the RPM filter in Betaflight, which depends on bidirectional Dshot in BlHeli_32, or something else? Is there a write up about the feature?
Sorry @Anthony_Short I should have put in a bit more color. It uses BLHeli telemetry, but only over UART currently. Bi-dir dshot will be supported when we support bi-dir dhot
I flew 4.0rc2 with an Y6 and Navio2 today.
There are still two problems so far:
Navio Led turn Green at early startup then turn Off and stay Off…
Oneshot125 is not working: PWM out stay in the 1000-2000 range even if Oneshot125 mode (2) is selected.
I tested Stabilize, AltHold, Loiter, Save waypoint, Auto mode (did the pattern twice in Auto), RTL.
Here is the .bin log
Compiled version from the Ardupilot firmware link http://firmware.ardupilot.org/Copter/ doesn’t run on Emlid 2019-02-27 image. Some resources are missing. Compiled version on Navio2 Raspberry is fine.
working fine here on pixracer 4.0.0rc2 + X4R.
Do you have an X series receiver to test with? I read about r9slims having issues with the s.port.
Ok, thanks for checking. Yes I have X-receiver, though it will be not very easy to connect to my copter.
I will flash 3.6 first to check if this is a hardware problem with my r9.
AC 4.0 RC2 Working great with my Cube Orange. Thanks Randy.
A similar configuration to @steampunk:
- Cube Black
- Here2 X 2
- Arducopter4.0 rc2
- gps_type = 9 (uavcan)
- gps_type2 = 9 (uavcan)
- gps_auto_switch = 2 (blend)
After arming attempt (Auto/PosHold) - getting “PreArm: GPS HDOP 655.3 (needs 2.5)”
No HDOP Indication in any configuration of the GPS_AUTO_SWITCH, nor with a single GPS.
Log link Attached
HDOP doesn’t get sent over CAN.
It seems that AP_GPS_UAVCAN::handle_fix_msg is not using the pdop field form the fix message. And the Auxilary message that is handled by AP_GPS_UAVCAN::handle_aux_msg is not sent by Here2.
The simple fix is to use the pdop field from fix message for both vdop and hdop.
good suggestion, thanks. Fix is here:
i ran into a compasses calibration issue - maybe affecting prior releases as well (cant tell).
FC cube black. AC 4.0.0-rc2
my primary (here2) is setup with orientation 0 (yaw 0 deg)
my secondary (BN-880) is setup with orientation 7 (yaw 315)
when i save the config it is all reflected in params as expected (i intentionally have second mag off)
however when i perform on board calibration (using left stick UP-RIGHT or with usb cable via MP - same results) the configuration of the primary changes to ORIENT 7:
i actually flew a mission with this bad config (as i did not spot it initially). copter held the course and completed the 7 km mission but it was rotating 360 every now and then.
I managed to resolve the post-calibration misconfig by physically disconnecting SDA and SCL cables from the second GPS. I have not tested this solution on a mission yet.
Do you have logs for the calibrations you did?
no i don’t. i did however run this multiple times (10?) each time with the same result.
Today, I decided to make a flight in a mountainous town of my country, located at an altitude of 1,100 meters above sea level.
When the drone was flying at the height of 1,200 meters, I started to raise it a little and while I saw the multirotor go up, my taranis x9d plus, showed a height 1,200 meters fixed, without changes, so I decided to decrease the accelerator slowly and reading It still showed 1,200 meters, so when it approached the ground and being at a height of 5 meters, the drone lost power crashing and bouncing up to about 10 meters and then the system activated the landing mode, crashing with the ground again and bouncing about 10 meters, so I decided to lower the throttle and take it with my hands.
I’m not sure if the barometer of my Pixracer is defective, but take a look at the flight log, it could do me good, please,
Some considerable damage, I can still fly again,
It doesn’t look defective me - it and the EKF had a reasonable idea of your altitude:
But I don’t understand why you lost power - clearly this was controlled by the FC as RCOUT 1&2 go to minimum in the period you are talking about:
Sorry for the slow response. Copter-4.0.0 will (by default) try to fix a compass’s orientation if it thinks it’s incorrect. It is somewhat documented here on the onboard compass calibration wiki page. I wouldn’t say it’s well documented though… in any case, Copter-4.0’s automatic compass orientation code can be disabled by changing the COMPASS_AUTO_ROT parameter. So fore example setting it to “0” will mean the orientation is not checked or modified as part of the compass calibration.
Thanks very much for testing Copter-4.0.0. Looks like a nice flying location.
As @andyp1per says the baro appears to be healthy. It’s possible that there is an issue with Motor3 which is hitting it’s limit a few times (see blue line below).
In the graph above we can also see the vehicle has a hard time maintaining control as it’s descending from about 70m but this is when the pilot’s throttle is low so the vehicle is descending quickly (probably though it’s own propeller wash) so I think we expect the attitude control to be difficult. The vehicle does seem able to maintain it’s attitude… it just has to work very hard.
Re the bounce, I think the vehicle just didn’t have enough power to slow it’s descent. Below is a graph of the desired climb rate (in red) and the actual climb rate (in green) with the scale on the left. We can see that it was asked to descend at 4m/s (PILOT_SPEED_UP = 500) which is quite fast. I think the pilot tries to reduce the speed of the descent as it gets closer to the ground but we can see the motors maxing out (motor 3 in yellow goes to max). At this point it just doesn’t have enough power.
A few unrelated things that I saw in the logs, these are not critical but FYI:
- it looks like the FS_THR_VALUE is set to 1000 which is the same as RC3_MIN. This theoretically means that the failsafe could trigger if the throttle is brought down to it’s lowest value in flight. This would be caught by the pre-arm checks but I guess the parameter check has been removed. I suspect you’re aware of this issue but thought I should bring it up anyway.
- the GPS_SAVE_CFG has been set to 0. Normally it’s best to let ArduPilot configure the GPS so that it gets all the data it needs and nothing else. The GPS quality drops a couple of times especially during the Land but it is probably an environmental issue (i.e. heavy tree cover or something) that you can’t do much about.
Thank you very much for taking the time to analyze my flight log, that is very important to me, it was very clear what they explained here, I will do some hardware revisions and verify the parameters in my configuration.
With regard to the GPS_SAVE_CFG parameter set to a non-zero value, I have obtained poor results, since this changes the default configuration of the GPS modules, decreasing performance and increasing the satellite reception time.
flying in open places I have no problems with my GPS, but in that particular place there are many tall trees that cause poor reception.
thanks @rmackay9 , very helpful. will try it out. to conclude though, we may have some issues with the orientation detection code (or my beitian is really bad)? thanks again.