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
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!
I also found log from yesterday where I have only 1 GPS unit connected, so only consumers are pixhawk module and smaller GPS unit that sits on the serial port on that 3DR power module.
Compare to the power chart in my previous post. I think it is it. GPS fails as it is unable to work on an unfiltered voltage.
Here is how VCC looks like, see on the chart. It is the only thing I can find different, it seems when I connect second consumer to the pixhawk is stabilizes VCC a bit and it start working OK. Jesus.
Does it sound logical?
The sun was very active yesterday with K-indexs ranged from 4 to 5.. Maybe relevant..
I have this board:
I have tried it with AC3.2.1 and all was fine.
I have tried it with AC3.3 rc7 and rc8 and I have problems:
Why with rc7 and rc8 I have the problem and with AC3.2.1 I didn't have it?
Attached a log. I hope that is the right log, actually I'am not so sure. If it don't seem the right log tell me and I will post another one (Hopefully the right one).
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.
Ok, so here is what I surmise is happening. The first and third screens show intermittent drops in the number of satellites. This is probably due to house or other structures near by which can cause two things; multipath interference and or blockage satellite reception from satellites out further away or near earth's horizon.
The second screen shot shows that when you were in an open field with a clear footprint to see all available satellites, the number of times the signal dropped from 15 to 14 was nearly zero. Running GPS inside or near your home can cause what you see in first and third screenshots.
Couple other factors you need to be aware of is Solar storm activity (K-Index) and Satellite orbits. Granted that a 30 minute test shouldn't show you a degradation of solar activity, but the sun is dynamic and solar storms do fluctuate hour to hour, day to day. When you perform tests, note solar activity as part of the testing process. The second factor is the satellites are not geosynchronous, they rotate around the earth. So the numbers could increase or decrease over time as the GPS detects or losses their signals.
I just purchased this board a few min ago! I hope it works w/ 3.3!!
Does anyone else have one of the pixhawk lites?
on my official pixhawk, w/ 3.3rc7, if my GPS/Compass rotates a tiny bit on its mast, I get that error until I recalibrate the compass.
Is there any chance it's a similar mechanical issue in your case? Maybe the 'issue' was there w/ 3.2, but 3.3 is more sensitive to such things?
yep, I just soldered in a new LC filter into primary feed line, 330mF capacitor and ferrite bobble, but it does not seem to change much from how VCC looks like, but, I think, it reduced amount of spikes a bit.
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.
Mast is not helping at all and causes EKF issues when your compass wobbles.
Best way is to do proper EMI blockade is to sit GPS on top of a carbon plate that has a layer of copper foil glued to it. copper foil like same that is used for electric guitars. It works better for me than any mast mount.
Just make sure not to use any metal bolts/posts on the GPS unit you will use as a compass.
I think only more or less supported mini board is AUAV. on that one you got you will probably be on your own.
AUAV has its Chinese clones getting sold on ebay as well. Not sure if it is worth doing, better get it from the maker, even if takes time. Vertical pins model is more compact, it is one on the Tarot image above. You can see even in the case (from shapeways) it fits in between 45mm posts - case has 45mm mounts, where those posts go into, screwed in and superglued. An awesome board for its compactness, but, has some quirks too.
"on my official pixhawk, w/ 3.3rc7, if my GPS/Compass rotates a tiny bit on its mast, I get that error until I recalibrate the compass.
Is there any chance it's a similar mechanical issue in your case?"
No, it is not possibile. I had tried also with only internal compass.
With only internal compass I get the same issue.
The log attached is with only the internal compass.
"Maybe the 'issue' was there w/ 3.2, but 3.3 is more sensitive to such things?"
About the PixHawk Lite/PX4Lite.
I have it but acualty I'm not using it for flying.
I do not trust at 100% this board.
Mine have 3 problems:
-It get hot when powered
-It have some problems with 3.3
-They send it to me with PPM encoder broken
I have some other boards.
With PixHawk by 3DR, VrBrain and HKPilot 32 it is all fine since rc7 (The first board where I tried the rc8 is the PixHawk Lite/PX4 Lite).
where can we find BIGGER than normal GPS units? Would something larger than the patch antenna's give better performance?