Warning #1: an issue has been found with Tower's Pause button which can cause the vehicle to fly to an old position if the vehicle has not sent a position update to Tower in some time.
Warning #2: Copter-3.3.2 fixes a bug found in Copter-3.3.1's desired climb rate initialisation which could lead to a sudden momentary drop when switching from Stabilize or Acro to AltHold, Loiter or PosHold.
Warning #3: Copter-3.3.2 fixes an issue found in Copter-3.3.1 which could lead to hard landings in RTL or AUTO if the WPNAV_SPEED_DN was set too high (i.e. >400 or 4m/s) and/or the WPNAV_ACCEL_Z was set too low (i.e. <100 or 1m/s/s).
Warning #4: a bug was found in Copter-3.3 which could cause a sudden crash if you abort a Take-off initiated from a ground station. Video description is here. The bug is fixed in Copter-3.3.1 so we recommend upgrading.
Note #1: AC3.3-rc8 corrected a long standing bug in the HDOP reporting. HDOP values will appear about 40% lower than previously but this does not actually mean the GPS position is better than before.
Note #2: if upgrading from AC3.2.1 the vehicle's accelerometer calibration needs to be done again.
Note #3: set SERIAL2_PROTOCOL to "3" and reboot the board to enable FrSky telemetry like in previous versions.
Note #4: the wiki will be updated over the next few weeks to explain how to use the new features
Copter-3.3.1 is available through the mission planner. The full list of changes vs AC3.2.1 can be see in the ReleaseNotes and below are the most recent changes since AC3.3.
Sadly this version (and all future versions) will not run on the APM2.x boards due to CPU speed, flash and RAM restrictions.
Changes from 3.3:
1) Bug fix to prevent potential crash if Follow-Me is used after an aborted takeoff
2) compiler upgraded to 4.9.3 (runs slightly faster than 4.7.2 which was used previously)
Changes from 3.3-rc11:
1) EKF recovers from pre-arm "Compass variance" failure if compasses are consistent
Changes from 3.3-rc10:
1) PreArm "Need 3D Fix" message replaced with detailed reason from EKF
Changes from 3.3-rc9
1) EKF improvements:
a) simpler optical flow takeoff check
2) Bug Fixes/Minor enhancements:
a) fix INS3_USE parameter eeprom location
b) fix SToRM32 serial protocol driver to work with recent versions
c) increase motor pwm->thrust conversion (aka MOT_THST_EXPO) to 0.65 (was 0.50)
d) Firmware version sent to GCS in AUTOPILOT_VERSION message
3) Safety:
a) pre-arm check of compass variance if arming in Loiter, PosHold, Guided
b) always check GPS before arming in Loiter (previously could be disabled if ARMING_CHECK=0)
c) sanity check locations received from GCS for follow-me, do-set-home, do-set-ROI
d) fix optical flow failsafe (was not always triggering LAND when optical flow failed)
e) failsafe RTL vs LAND decision based on hardcoded 5m from home check (previously used WPNAV_RADIUS parameter)
Thanks for your testing!
Replies
I think you are onto something there. I was going to reply to your earlier graph that although the VCC is stable around 5.07 volts, that there is a large spread of power fluctuations. If I may ask, what GPS modules are you using? I've researched enough of the M8Ns to know they are both sensitive to satellite signals as well as EMI and power noise issues. I run dedicated power filters on my GPS and LIDAR units to ensure clean power to these sensitive units.
A dedicated filter right on the 5V line feeding GPS unit is probably a very sound idea. It was not really obvious to me, as GPS consumes a tiny fraction of current from pixhawk, so what we see on the graph is most likely an illustration of an internal lack of VCC stabilization in the flight controller... As in my case now I cannot see how this filter would not be sufficient.
From what I remember about old APM 2.6 and 2.8 I would always see almost ideal digital trend in that VCC voltage correlating with a capacitor used, here on pixhawk is seems way less stabilized. So it may be a good idea just to try to put an LC on the other side of power rail where serial ports are, not sure yet. I wish I would still have my oscilloscope to look at all that.
But, to be honest, I see now this dual GPS configuration to work fine.
As of GPS units - they all are from witespy, big one is a $33 45mm big square unit with compass on the top plate, other one is a 'house' EMI protected 35mm unit.
I saw other response you sent - I understand about near house blockage, but, real deal is the difference between first an third screenshots. as after flying in the field small gps unit somehow forgets that was only able to see 7-8 sats for an hour and start working with 14 sats again like nothing happened in the same exact spot near house where it was only seeing 5-7 sats before, for LONG time.
Last screenshot is from this flight I just did after getting out from the basement with new LC filter soldered in - you can see small GPS with green chart is still able to get to almost same level where big one sits. Sudden drop in the end is where I took drone into my hand and blocked small unit`s antenna.
Still, it works now, again, and yesterday it was sitting at 6-7 sat for 2 hours no matter what. Still, I can live with that, a dual GPS setup I think is a given requirement for any drone anyway, you just cannot rely on a single unit as it seems to be way too sensitive to unknown factors.
Those cables are routed in between two plates that are covered in copper foil. It is beyond me what can be causing any interference there to a level of disrupting 38kbit serial stream, and it is not happening now as it was not happening for a whole week.
I think ideally only solution is to find a source for light well made shielded cables, we need here 2 kinds - 3 wires in a shield and other with 5 wires in a shield, but I did not see a good source for such cables and it is a pain to solder tiny connector to those cables. But I would agree, it seems on any drone all with no exception signal cables should be 100% shielded. It is the only way to make sure no random movement of a cable will lead to a glitch.
I had a ton of issues with 2 other GPS M8N units from ebay and I am positive now - all was related to same exact issue with some sort of an interference, and most likely, a feeding voltage cable is responsible as I cannot see how serial interface wires can get signal disrupted that much, plus, realistically, I was getting an erratic reading of a location, but it was showing well - means GPS circuit could not read location but it was communicating it out well.
Now, to make it really tricky - on this drone my GPS is the only consumer of the voltage connected to Pixhawk, NOTHING else is powered up from pixhawk at all and this feeding 5V voltage is IMHO stable enough. Look at its chart - is it acceptable? Or do I need new LC filter in there on feeding 5V line?
There have been some changes to the ublox driver since -rc7 so it's possible that something has been broken in the firmware. Definitely a dataflash log with the logging-while-disarmed bit set would be good. The dev team is growing and we have one guy, Michael De Breuil who has spent a fair bit of time going through the Ublox driver and looking for problems so I think I could ask him to have a look and see if he sees anything strange.
Wes,
Thanks for the report.
The issues with the current sensor sounds unusual. Simply plugging/unplugging it shouldn't make any difference.
For the GPS, we see reports nearly every release about reduced GPS performance but they almost always end up being environmental changes that coincided with the firmware upgrade. Here's an example of such a discussion. If you could try again outdoors that would be best. Worst case if you can provide a dataflash log we can check the UBX1 messages to see if there's jamming happening which is normally caused by surrounding electronics.
I'll wait for the dataflash logs before commenting on re the AltHold and Loiter issues. For Loiter we actually do have some new parameters that should allow reducing the "freight train" effect of Loiter. The performance in these two areas shouldn't have changed since AC3.2 though.
Thanks again.
Here is the bin file for Mondays flight with better uncontrolled climb and loose Loiter.
Are there any good tutorials on understanding logs? I only understand about 10% of the info.
Randy, please check in the code what logic is used to generate message 'prearm needs 3D fix'.
I see this message for very long time now, when GEOFENCE is activated. if it is not activated it seems to respect value for a HDOP given in the gps paramters and arm, but with geofence it seems to wait for something else.
Paul,
It's probably that EKF has not declared it's position is ok. When the circular fence is activated the position estimate from the EKF must be good before the pre-arm checks will pass.
The EKF does a bunch of checks internally including ensuring the velocity is ok. Maybe those checks are too tight or maybe there's really some issue with the GPS velocity numbers or something else. If you turn on logging-while-disarmed we can ask Paul to have a look.
Maybe we can add some extra information to the check to clarify exactly what is going bad.
OK, I will try.
It is an interesting comment about EKF getting hooked into GPS that tight. I can see that when bigger GPS units hooks into at least 13-14 sats it is satisfied, but, it is M8N unit that does it, I know for a fact that none of my older neo6 units ever hook up to that many sats, so, I wonder how all other folks are managing with that.
I struggled with that yesterday as I got bigger GPS unit removed and had to tinker a lot to make small GPS work again, got it to the level of getting 9 sats connected to, HDOP reported as low as 1.1 - 1.3 something - but I could not get drone to arm a single time as it was constantly demanding for this '3D fix'.
I am not sure if I want to take it apart again, but, it is something that was not really expected.
Hello all,
I'm hoping someone can offer some input. Ive been flying 3.2.1 since its release and I saw that 3.3 was released, so wanted to give it a try. (3.3rc7) 1300 sized quad running 6S, T-motor 4014-11 330Kv with and all up flight weight of 6200g. I tried Stab, Alt Hold, and Pos Hold. The quad seemed much more responsive and generally smoother flying even with the default PIDs.
I was flying in Pos Hold and all was well until about minute 9 where the quad started to uncontrollably descend and yaw counter clockwise. I tried to feed it counter yaw and boosted the throttle to attempt to keep some altitude. Nothing worked and it crashed, fairly gently however. No real damage just a significant twist to the gimbal as the gear was still descending and didn't make it. I've looked at the logs and Yaw seems to be leading DesYaw but not drastically. The clockwise motors were hot to the touch as would be expected from chasing the yaw for 9 minutes.
I'm not experienced with logs and was hoping for some input.
I can't attach the log as its too large so heres a link:
https://drive.google.com/file/d/0B1CbIAUo7keqblZuRXdPS0NJc0U/view?u...
Thanks!
-
310
-
311
-
312
-
313
-
314
of 558 Next