We’ve just release Copter-3.5.3-rc1 for beta testing.
This means you should be able to download it using the Mission Planner (and perhaps other GCSs too) by selecting Initial Setup >> Install Firmware, then click on the “Beta firmwares” link and the string under the various multicopter and helicopter icons should change to “APM:Copter V3.5.3-rc1”.
This is a relatively minor release with just these changes (ReleaseNotes.txt):
Guided mode support yaw and yaw-rate fields from set-position-target message
Optical Flow startup retries 10 times
Bug fixes:
Septentrio RTK GPS driver robustness improvements for long messages
dataflash not-logging checks if not initialised
fix reporting of relative-position-NE-to-home (most users will not notice this difference)
The most serious item is the 1st bug fix which affected the Septentrio RTK GPS driver (it does not affect any other GPSs including the most commonly used UBlox GPSs). One user had their Septentrio GPS configured to output very long messages and experienced a sudden crash after 30minutes of flight. This fix is the result of working with that user to identify and correct the problem. If you’re using the Septentrio GPS we highly recommend upgrading to Copter-3.5.3 especially once it’s released officially.
All testing of this new release would be great, and please report any issues in this forum. Thanks!
If all goes well with testing we will release it as the official version in about a week.
@rmackay9 could you please describe what is the use case when user will notice the difference? And what will this difference about?
It is not clear from the PR discussion
I’m using RC telemetry (mavlink) as a backup info for case if I lost my video and OSD.
So I wonder do I need to upgrade or not.
@sergbokh,
Re the fix to relative-position-NE-to-home, this only affects the LOCATION_POSITION_NED mavlink message sent from the vehicle to the ground station. This is not a commonly used message so I don’t think you’ll notice the change. Most ground stations use a different message which provides the latitude and longitude of the vehicle and allows it to be displayed on the map.
I flew this build today. I noticed a few GPS gliches, but I cant say if it was related to the build. I was flying near a cell tower which may have caused the gliches. I have the AsteRX as my primary GNSS, which is backed up by a standard U Blox.
I’ve been chasing a bad logging error for months. I normally fly RTK fixed. Several flights last week I didn’t need RTK and never got a bad logging cue in the HUD. So I began to wonder if the AstreRX with a correction was causing the bad logging. Today with 3.5.3-rc1 and RTK fixed I never got any bad logging indications. I am hopeful this new build fixed my persistent logging errors.
Flew four times today. Unfortunately, got bad logging indications on 3 of the 4 flights and we weren’t sending a correction to the drone. Don’t know if the bad logging and AsteRX are related or not, but 3.5.3RC1 didn’t solve the logging issue.
We recently started using PPK instead of RTK, Don’t have a ton of data but I’ve probably taken 1,500 pictures with Copter 3.5 and PPK and they all worked fine.
Today I had significant drop outs in my PPK data. Took over 400 pictures and roughly 1/4 had no data. I have no idea if this could be related to the septentrio modifications, but want to through this observation out to the community for consideration.
Flying again tomorrow. I’ll report back when able.
I’m not the expert in either the GPS or logging areas but I can’t immediately think of a way they could be related. I’ll point this report out to Peter Barker and Michael DuBreuil who are the experts and maybe they will have some ideas.
For me, my best suggestion is probably just to ensure the SD card is high quality with a fast write speed.
I’ve just pushed Copter-3.5.3 just now so it should appear in the ground stations in a few hours.
@skyveyor when you say dropouts in your PPK data you are referring to the AsteRx-M’s SD card correct? And you are assessing the pictures don’t have data as the result of GeoTagZ or something else?
Flew 4 times today and each flight I had a bad logging cue. I’ve swapped SD cards, reformatted SD cards and even swapped out flight controllers. The stubborn bugger persists. It’s got to be something with my set up. I have a class 10 card in there now. The only thing I haven’t tried is formatting a high speed SD card as FAT instead of FAT32. FAT is only good up to 2Gb. I haven’t gotten around to ordering a high speed 2Gb card. Got plenty of 32 and 64 hanging around though.
@skyveyor can you share some logs? Are you stopping the SD card log before removing power? It is a known problem that if you don’t cleanly stop writing the SD card log file before removing power that it can be corrupted and you can lose data from the AsteRx-M’s log. (There is a button on the board to start/stop logging you should be taking advantage of).
Although a GPS status of 1 is NO_FIX which lends a lot of credibility to an antenna problem or interference. In RxControl what is the GPS’s RF power from the status panel? (The radio looking symbol at the top). The other thought of course would be interference, which you could use the spectrum analyzer for.
My last email was poorly written. I had two separate issue that I merged into one confusing thread. The problem with the AsteRX was two-fold: A) the antenna was loose and B) poor procedures. I was not habitually turning off logging before powering down. I missed that user note but was reminded by Dave at Septentrio.
The other problem I have yet to solve in bad logging on the pixhawk. Because I can’t geotag images with no logs, I ended up buying GEOTAGz for PPK EXIF data. Nice interface but not as simple as mission planner geotagging with DFlogs.
@skyveyor okay that makes more sense as to what was happening. If you are flying copter 3.5.3 you can set GPS_RAW_DATA 1 which will add as part of the GPS arming checks a check that the AsteRx-M is currently logging to it’s SD card.
I’m slowly looking for a way to automatically stop logging when the vehicle is disarmed for example, but due to the configuration time on getting logging started again I can’t do it the moment a user asks for the aircraft to arm. So I’m not sure of any good way to automatically start the logging yet. But I would like to get this feature sorted out as manually stopping logging is a large pain.
That is a great tip and addition to 3.5.3. It’s nearly impossible to see if the red LED is flashing in bright sunlight. I often have to cover the drone with my hat to see if the LED is flashing. Even then it’s hard to see.
For me the logging button is easily accessible so turning the logging on and off is a minor inconvenience.
Have you talked to anyone from Septentrio about a possible fix on their end?
While the button is in general easy to press, I’ve witnessed that users have a high tendency to forget to press this, so I’m looking for a way to minimize the users chances of screwing this up because they forgot.
About the logging or minimizing the corruption? The enable/disable logging at run time is the main way to fix it that I’ve discussed with them in the past. FAT32 filesystems are much more prone to corruption, however I can’t really track why it seems to be more of a problem on the GPS log then autopilot log.