ArduCopter 3.2.1-rc2 (release candidate #2) has completed beta testing and has been released as the official version available through the mission planner and other ground stations.
Changes from AC3.2 are listed below and in the ReleaseNotes:
1) Enhancements:
a) reduced twitch when passing Spline waypoints
b) Faster disarm after landing in Auto, Land, RTL
c) Pixhawk LED turns green before arming only after GPS HDOP falls below 2.3 (only in flight modes requiring GPS)
2) Safety Features:
a) Add desired descent rate check to reduce chance of false-positive on landing check
b) improved MPU6k health monitoring and re-configuration in case of in-flight failure
c) Rally point distance check reduced to 300m (reduces chance of RTL to far away forgotten Rally point)
d) auto-disarm if vehicle is landed for 15seconds even in Auto, Guided, RTL, Circle
e) fence breach while vehicle is landed causes vehicle to disarm (previously did RTL)
3) Bug Fixes:
a) Check flight mode even when arming from GCS (previously it was possible to arm in RTL mode if arming was initiated from GCS)
b) Send vehicle target destination in RTL, Guided (allows GCS to show where vehicle is flying to in these modes)
c) PosHold wind compensation fix
d) prevent infinite loop with do-jump commands pointing at each other
e) pixhawk memory corruption fix when connecting via USB
f) vehicle stops at fence's alt limit in Loiter, AltHold, PosHold (as it did in AC3.1.5)
g) protect against multiple arming messages from GCS causing gyro calibratoin failure
Thanks to Raph for the video. This is actually a video from AC3.2 until we have one specific to AC3.2.1.
Replies
No need to re-move and re-install. You can press CTRL-F and select refresh parameters and that will download an XML file from github with all of the parameters listed.
I used the Beta firm MPlanner and works Pos Hold, try Beta
Randy, in my case I was using the beta MPlanner to be able to choose Pos Hold, I always take off in stabilize mode and not switch to other mode during take off, at first I think that it was a radio signal problem but the log shows a mode err; to fligth I used the Droidplanner as ground station, It's possible that the GS report a bad command? or something that I did unconsciously wrong or a problem In my equipment? or is common that log report a mode err when you lost radio signal? now I'm desoriented what to check to not repeat the crash, any help please?
Cala,
Your setup sounds a lot like mine. The first time I flew Arducopter 3.2 rc1 I had a crash. It was clear I had selected Position instead of Poshold. I used the wrong version of Mplanner in selecting that mode. It boiled down to simply seeing Pos... and thinking it was Poshold.
Since I had two versions of Mplanner installed, I had opened the wrong one. I also use Droid planner on my Android as my ground station. I have tried both Droid planner 2 and 3 but they do not work with my setup. The ground station connects to my quad directly via Bluetooth. Droid planner works, but 2 and 3 will not connect via Bluetooth.
Right now I am testing arducopter 3.2 rc2 and it seems to be better. Testing yesterday went without a hitch. The problem is that ground station software can't keep up. The latest flight modes are reported by the ground station as mode unknown. Had that worked I could have recovered from the crash when it was switched. I am still not sure why Poshold didn't simply replace Position since it was removed and invalid anyway. I have a use for Poshold, but Position wasn't useful in my case.
I wish that when Mplanner is updated, the other ground station would follow close behind. It is one of those things I have to accept when using the latest version of the arducopter software.
Thank's for your answer Craig, the strange thing is that I only used the latest vers from the two softwares, I have many fligths with no problems, i check many logs because studying vibs and never a Pos reports in logs, I don't find what is mode 15, instruccions mention 14 modes, I was taking off from a tall sunflower, perhaps it was a failsafe and a incorrect report in logs but I'm not shure, that worries me, i have 433 radio (Dragon) and was near but tall plants were arround the cuad.
When I had my problem, Mission Planner clearly indicated a flight mode err in red. Since Position had been removed, I did not find it in documents. I did chase it down in the source code. That way I could verify the mode in the parameter listing of MP.
I could use the value in Droid planner to manually set it. I hate doing that when I am in the field. I used MP when I got back to the office to make the change.
I recently added a 3dr Power Monitor, and setting that up has been fun. My flight time was reduced until I was able to configure it properly. What seems like a straight forward configuration took some time to actually get right. A couple minutes into the flight it would trigger a landing (land or RTL). My battery still had plenty of power left. Two days of testing finally eliminated that issue. While it continued to happen, I was getting frustrated. I do have plans to eventually use the new rally points for some of my flights.
Hugo,
I am still evaluating that issue. I do stand by my configuration settings. I have checked them quite a few times now. During my last test, I switched off both voltage and reserved power checks. I still received the same warning. It appears the 5volt power from the power monitor falls below 4.5 volts triggering the error. This was not a problem with my last bec power supply. The battery certainly has 40percent left. I am considering removing the power connector from the power module and reinstalling the previous bed power supply. That will require me to handle the input from the power module separately on the Apm.
I would have expected that error to be considered a browout, but the APM does continue to add log entries after the event. From what I have read, that is a good indication of a brownout. Log entries stop.
I would have thought the power monitor would hold a steady power supply for the APM. A capacitor is one solution, but I can add a separate power supply for the APM if necessary. The old bec power supply certainly handled that well because my flight times were doubled until I changed to the 3dr power module.
I still have those tests to conduct to see if they solve the problem. I do plan to have those kinks worked out before spring. I have an interest in doing commercial work and reliability is key.
Hi Craig,
What was the problem with the power module? Did you have the wrong voltage offsets?
Quite honestly, I feel your valuable time would be better spent refining the flight software than programming checks to verify GCS/vehicle compatibility the operator should be fully aware of and accountable for. But that's just me.....
Sir, you are correct! It seems I started an older copy of Mission planner. It was set to Position. I had an old link but thought I got rid of the older versions. My bad, but at least I have a good explanation. I am still wondering why it went crazy. I did think I was switching to Position hold.
Thanks for the look at the logs. That was the first time I had ever seen that error. I owe you a beer!