Copter-3.5.0-rc2 (2nd release candidate) is now available for beta testing. As per usual the beta version can be downloaded using the MP’s Install Screen’s beta firmwares link and I believe there’s a similar ability in QGroundControl.
There have been quite a few changes and fixes compared to the previous release candidate. Most of these changes are listed below or can be seen in the ReleaseNotes.txt.
Changes from 3.5-rc1:
Improved dual GPS support including blending (set GPS_TYPE2=1, GPS_AUTO_SWITCH=2)
AutoTune with position hold (enter AutoTune from Loiter or PosHold modes to enable light position hold)
New boards/drivers:
a) PixhawkMini support
b) AUAV2.1 board support (for AUAV2.1 set BRD_TYPE to 20 to distinguish from PixhawkMini)
c) Garmin LidarLiteV3 support
d) Maxell Smart Battery support
e) Invensense ICM-20602 IMU and ST L3GD20H gyro drivers added
IMU to Motor lag reduced by 0.6ms
Object Avoidance:
a) support TeraRanger Tower sensor
b) support using normal (1-dimensional) lidar/sonar
Minor changes/enhancements:
a) add MOT_SPOOL_TIME parameter to allow users to control spool-up time of motors
b) remove Solo gimbal from -v2 because of 1MB Flash limit on many Pixhawk1s (Solo users should use -v3 firmware)
c) altitude check for Guided mode takeoff (must be at least 1m)
d) auxiliary switch to arm/disarm vehicle (set CH7_OPT to 41)
e) change battery alarm tone to reduce impact on IMU
f) add battery monitor health reporting
g) support DO-FENCE-ENABLE mission command to enable/disable fence during missions
Bug Fixes:
a) OLED Display clears messages after 10seconds
b) Servo Gimbal output range fix (could attempt to push servos beyond their limits)
c) fix do-set-servo
d) fix dataflash log time (was always appearing as 1970)
I suspect this release is quite close to the final official version but there will be at least one more release candidate. We hope/expect to pick up the pace of release candidates from now on - releasing one new release candidate each week or so until we get to the final version. I.e. only bug fixes from now on.
Thanks very much to our beta testers for helping us find issues before the official release!
Yes, I tried autotune-with-postiion-hold and it worked fine. The vehicle stayed within about 15m of it’s original position. One thing to be careful of is the somewhat sudden heading change it does now and then so that it’s twitching 90degrees from the wind. On the off chance that you do need to re-take control of the vehicle, you have to be ready to do that mental shift on the controls based on the vehicle’s new heading. alternatively, the pilot could also enable simple mode.
Thanks- great news! I will give it a spin over next WE on my DIY copter.
One question about the removal of the Solo gimbal code - you mentioned Solo users should use v3- do you mean RC3 or are you referring to a new build option in the make?
The v3 build is the correct option for the CPU’s that don’t have the 1MB issue, which is the case of the Solo, and most of the newer PixHawk family boards including the “Cube”
What is this > Maxell Smart Battery>?? I was playing with TIs SBS but afaik it is not supported. Might there be a better smart battery interface that i could hack the TI board to?
As in the firmware file called Arducopter-v3.px4. As opposed to what most people use, which is Arducopter-v2.px4. The v3 is designed for the cube with more memory. TBH, I have no idea if Mission Planner pulls down v2 or v3. So I just grab the PX4 file from github and install it using the load custom firmware function of Mission Planner. That way I know I’m getting the right one.
I’ll be giving the AutoTune with PosHold a try later this week. I performed auto-tune on just the Yaw axis of my 550 Hex over the weekend running 3.5-rc1 and had the best results ever! Looking at DesYaw vs. ActualYaw I was seeing significant oscillations, but after the tune you almost can’t distinguish between the two lines.
Massive thanks to the devs and I can’t wait to re-tune Roll/Pitch without having to constantly reposition. I look forward to reporting back with my results.
3.5-RC2 (-v3.px4 version) is now installed on my experimental solo. Installation went fine. It maintained all the parameters I had set with RC1 before thankfully. I had some very funky AHRS issues. Sitting on a level table, it showed an 8 degree roll to the right. Level and accel calibrations failed repeatedly. Rebooted, same, failed. After that I used the reboot action in MP to reboot the pixhawk once more. It booted up level and normal. Passed all level and accel calibrations. Not sure what the deal was with that. But all appears to be well now.
It needs a compass calibration, but won’t be doing that until I get out to fly. Which probably won’t be until Saturday based on the weather. Snow, cold, and wind says me and dog are staying inside with pasta and beer until Saturday. Well, and going to work.
KarlU,
Re the Maxell smart batteries, these batteries are available in Japan but I’m unsure of other countries. I will write up a wiki page to describe how to connect them before the official release. I suspect other smart batteries can also use this new driver but I don’t know for sure. Pretty much all “smart batteries” use the SMBus protocol which is compatible with I2C so if you have another variety of smart battery you could try to connect it’s SMBus lines to the flight controller’s I2C port and see what happens. Best to check the datasheet and pin voltage first to ensure they are 5V or less.
i have been trying to find information on smart batteries that would work but when you search for “maxell smart batteries” all you get is your post on github talking about adding them?
is it an impimentation of the Smart Battery System (SBS) standard?
Aparetly the TI board i have uses same registry addresses as Maxell so they should be compatible. With 3.4 if i hook it up and fiddle with registries the flight controller freezes.
I was looking at the rc code and noticed that only current and voltage are defined for use so i guess the current aim is to make those Maxell batteries usable rather than making batteries smart? If i uncomment the registry values for other parameters then in user defined code i should be able to request state-of-health, cycle-count etc data?
@George_Muirhead On the SBS wiki article it says that its sort of a de facto standard. What the differet boards do internaly probably differs but the interface available to SMBus seems to be the same.
Nice work Karl.
Yes, the current Maxell battery driver is just a starting point with basic functionality (voltage and current) but the maxell battery itself also doesn’t provide as much info as say the Solo battery. Hopefully we can do more (with the maxell or these TI batteries) including what you’ve mentioned and also individual cell voltages, setting battery capacity, % of battery remaining.
Are the TI batteries readily available or is it still very DIY?
Its DIY as its custom made batteries with TIs SBS controller. This chip to be exact. I can get quite a bit of data from my batteries but not everything that the chip offers is imlpemented yet. Will be quite a while before it can become a fully blown product if ever. If you need someone to test the interface then from this chips perspective im happy to help.
Generally, Autotune would never have been possible under such conditions without PosHold
Turning into the wind works perfect!
Due to the higher wind speed during this test turning into the wind can look like a “flyway”. I guess this is the phase when wind direction is measured.
Problem:
Autotune failed. At least there were no changes in the PIDs. There is no indication if it failed or finished successfully in the logs. Autotune logging simply stopped.
At that point the copter started drifing in the wind - it seemed like normal AltHold behaviour.
I landed and disarmend with autotune still on. But no changes in the PIDs.
Questions:
What went wrong?
I can imagine that AT failed due to too high wind speeds. But, how can this be seen/determined?
Another thing - maybe related to Copter 3.5:
Getting Params over USB after connecting in Mission Planner is sometimes unusually slow. I saw this behaviour on different boards (Pixracer, AUAV-X2) and different USB cables. Downloading a log afterwards was as fast/slow as usual. I’ll make some further tests.
Thorsten,
Thanks for the report. I think I know what this is. We throw away the first request-for-parameters if it arrives before all our internal objects have been created (it takes a few seconds after startup). I think you’ll find if it’s possible to wait a couple seconds after startup before connecting and downloading parameters it will be fast. Tridge has mentioned this issue to me and I think we have a fix in mind.
