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.
1 Like
AC 4.0 RC2 Working great with my Cube Orange. Thanks Randy.
1 Like
@mlebret, thanks for the report on the Navio2 issues. I’ve added them to our Copter-4.0 issues list so they won’t be forgotten.
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.
1 Like
good suggestion, thanks. Fix is here:
1 Like
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)
COMPASS_ORIENT,0
COMPASS_ORIENT2,7
COMPASS_ORIENT3,0
COMPASS_USE,1
COMPASS_USE2,0
COMPASS_USE3,1
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:
COMPASS_ORIENT,7
COMPASS_ORIENT2,7
COMPASS_ORIENT3,0
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.
Hi,
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.
1 Like
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.
rmackay9, andyp1per,
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 again.
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.
Hi Winston,
were you using the passthru telemetry on your x9d or regular frsky telemetry?
If you were using passthru telemetry GPS altitude is encoded in a 9 bit payload with the following formula:
if (abs_number < 100) {
res = abs_number<<2;
} else if (abs_number < 1000) {
res = ((uint8_t)roundf(abs_number * 0.1f)<<2)|0x1;
} else if (abs_number < 10000) {
res = ((uint8_t)roundf(abs_number * 0.01f)<<2)|0x2;
} else if (abs_number < 127000) {
res = ((uint8_t)roundf(abs_number * 0.001f)<<2)|0x3;
} else { // transmit max possible value (0x7F x 10^3 = 127000)
res = 0x1FF;
}
An altitude oscillating around 1200m would be divided by 100 and rounded to nearest integer so from 1200m to 1249m would probbaly be rounded to 12, from 1250 to 1299 the result would be 13.
This value would be multiplied by 10 raised to the 2nd power, so multiplied by 100.
so to recap:
- for altitudes in the range 1200-1249 you would get a steady 1200m on your taranis
- for altitudes in the range 1250-1299 you would get 1300m
hope this clears your worries 
And before you ask why the passthru library encodes gps altitude this way let me answer that I don’t know for I wasn’t around when the decision was made. I guess the urgency to keep bandwidth low pushed the original designer to “extreme” compromises
Alex
1 Like
I am using regular frsky telemetry.
I was a little worried about the issue of altitude, but now I feel safe when flying, of course after reading the excellent explanation you gave me this way.
Thank you.
1 Like
Hi, by regular frsky telemetry I mean serial_protocol=4. What I described only applies to serial_protocol 10.
Sorry, I was wrong in the previous answer, I have activated the serial protocol in 10, which means that I am using passthru telemetry.
1 Like