Ardupilot: Copter: handle boat take-off and landings

[rmackay9]

This was requested as part of AC3.2 testing.
http://diydrones.com/forum/topics/arducopter-3-2-beta-testing?xg_source=msg_com_forum&id=705844%3ATopic%3A1656303&page=112#comments

There are two risks for arming and taking off on boats. The first one is that the gyro calibration will likely fail. It'll go with it's best guess which is likely ok most of the time but at least one case has been reported where the vehicle got a case of "the leans". I.e. the pilot had to keep pulling further and further back on the pitch stick to keep it level... eventually there wasn't enough stick left and it flipped over. This is because the gyro calibration didn't work very well. Plane has a parameter that allows skipping the gyro cal, we don't have it in copter although it's easy to add.

The 2nd less risky issue is the pre-arm checks will fail if it thinks the vehicle is moving over 50m/s (i.e. 1.5feet / second). This can be disabled by setting the ARMING_CHECK to Skip INS.

For Landing there may be an issue with the landing check's 30deg/sec rotation rate not being passed meaning the vehicle cannot be disarmed in AltHold or Loiter.

[jschall]

Flying over water in general needs to be documented. There are a number of failsafes that just land the copter - if the copter is over water we are going to want it to either return to shore or hover until it runs out of batteries. In case of a persistent RC failsafe, we need the former to be possible. So, a rally point or a pre-set home location.

So basically, a wiki page explaining the current best-practices for flying over water would go a long way.

[ghost]

@jschall,
agree with you. Large copter community in my area which is surrounded by water. A guide for flying over water would be very much appreciated.

[govsux]

There are several FS that can be set to land. Perhaps it would be advantageous to have one param for flying over water that would skip gyro AND set all FS that are set above 0 [ to land or anything else ] to default to RTL or if no gps lock simply alt hold.

[nicksargeant]

Agreed with everything said. It wont simply be a matter of changing the gyro calibration; there will need to be appropriate changes to failsafes as well as comprehensive documentation. Perhaps it might be appropriate to discuss the implementation of "boat mode" along side "indoor mode" (https://groups.google.com/forum/#!topic/drones-discuss/ssVJ7F4iHwU) as there will need to be similar considerations despite being quite different in nature?

[govsux]

The most pressing issue at hand for boat mode is the gyro cal though. That's the one thing that needs changed in order to fly safer. The rest is more of an insurance policy.

Here's sort of a wish list for boat mode am I forgetting anything?? Probably :] When boat mode is turned on it...

-skips gyro calibration or makes it much longer as I think Randy mentioned once.

Then prompts you to review these settings

-Change any FS settings that are set to land to RTL with gps lock or alt hold if not? Y or N
-Set a separate boat mode RTL landing site for any RTL situation OR enter follow me if available? Y or N

Not sure on that one though. I don't think the controller knows if there is a GCS with follow me right? It only knows when you tell it so right? So that would have to be established and set up by the user. So essentially for the first time that I'm aware follow me would go from a neat trick to a new FS event? hmmm Can of worms? But worth looking into as there is a very good chance the boat has changed locations for filming etc. A friend with a Phantom almost lost his for this very reason.

Another thought. In an extreme rough situation it might be a good idea for the controller to override takeoff throttle input unless the controller is + / - 3 degrees from level. That alone could be the difference between a successful launch and getting a hair cut in tight quarters.

[govsux]

Randy
'skip gyro' in Arm check is not the same as skipping gyro as discussed for this issue is it?

[rmackay9]

@govsux,
Yes, "skip gyro" in the arming check simply turns off the check of whether the gyro calibration succeeded or not. On a boat it would very likely fail and then it's a bit of a crap shoot as to whether the attitude estimates (in particular the heading) will be ok. Jonathan, PaulRiseborough have discussed this and we think a much longer gyro calibration using many more points will likely work. So a longer gyro cal rather than simply skipping it is likely the answer.

[govsux]

@rmackay9 That would be great if that worked seems like a simple fix. I'd be happy to test it out.

[seamaster101]

Not long ago I had to develop a device that would detect lean angle on a boat using crane. The part of the challenge was the oscillation induced by the wave action, that I preferred to avoid.
So if let's say the allowable lean under load was 12deg and wave induces another 2 degrees roll, it would have resolved in 14 degree roll in one direction and 10 deg in the other. I needed to find way to get the mean leaning angle ignoring the roll from the waves. The solution was to start a timer every time the boat exceeded the allowable lean angle. If the timer exceeded the 1/2 roll period of the boat and the lean angle was still over the allowable limit (usually boat roll period is 5 to 8 seconds for 45 -70 foot boat) the SW would trigger max lean angle alarm. The logic was that during the wave induced roll, the boat will exceed the mean lean angle for the 1/2 of the boat roll period and then it will go below it...
The reason I'm bringing that up, is that maybe there is a way to average the calibration values if the readings are taken for longer period of time (longer then the boat roll period).
Just food for thought.
Captain Jordan Shishmanov
M/V SeaWitch

On Nov 20, 2014, at 2:05 AM, Rick [email protected] wrote:

@rmackay9 That would be great if that worked seems like a simple fix. I'd be happy to test it out.

—
Reply to this email directly or view it on GitHub.

[govsux]

@ Seamster Very interesting! And as a matter of fact I think Randy had mentioned the same idea of a longer calibration time.

[lthall]

We have a couple of issues here. If we only average for a longer period then we may be averaging while the copter is still being handled and as a result average during a 360 rotation of the copter and therefore the average rate will be way out.

Maybe we could do a double arm process where we attempt to arm and the arm process fails because the offsets are very different. At that time we could restart the averaging process. The following arm would then be more likely of being done while the copter is not being handled. This still doesn't account for someone hand launching the copter.

Hard problem. We may just have to run the EKF to combine a number of sensors and let the EKF converge......

[jschall]

Paul is working on math that will allow the EKF to converge from an arbitrary initial orientation, and I think this means that it will converge from a bad initial calibration within reason. If this is the case, gyro initialization is no longer necessary.

[seamaster101]

Very good. I think this approach will work for boat launches. Within a reason :0)

Captain Jordan Shishmanov
M/V SeaWitch

On Dec 12, 2014, at 10:28 PM, jschall [email protected] wrote:

Paul is working on math that will allow the EKF to converge from an arbitrary initial orientation, and I think this means that it will converge from a bad initial calibration within reason. If this is the case, gyro initialization is no longer necessary.

—
Reply to this email directly or view it on GitHub.

[govsux]

Is this going to be in the next Beta by summer?? Hope so. I'll be happy to test!

[Pascal-SoGeo]

I am also very interested in that function. I am looking toward offshore activity with UAV and obviously would need to take off from very large metallic and slow moving structures.

[rmackay9]

The arducopter part of the return-to-me is in master now and will go out with AC3.3. This is one more step towards resolving this issue.

[TerryPts]

If the channel 9+ implementation is completed, one of the extra channels can be used to select "boat" mode which could set up the necessary parameters.

[rmackay9]

landings should be much better in AC3.3. Take-offs (in particular the gyro calibration) could still fail and we will need to push that portion to AC3.4 'cuz we're simply out of time for AC3.3.

[nicksargeant]

This is disappointing but very much understandable given that boat operations are a pretty niche use case and there are plenty of other requests with wider applicability . Thanks for trying Randy! I am pretty keen to see this through, so if there is anything that can be done to help from an end-user perspective (testing/datalog collection) please let me know.

[CodeChief]

As a side note for when any development on this continues, you probably need something like GPS RTK to get enough accuracy to land on a boat deck. From what I understand so far 1cm accuracy is possible, but the base station must remain static so not sure what happens when the boat is moving.

Perhaps then it needs to just make the coordinates between the GPS on the boat and copter match rather than trying to get global accuracy. Actually if the boat has the gyro and compass too (potentially full APM hardware) then that should solve the calibration too?

Until a certain height is reached (and below when landing) we should match the horizonal of the boat anyway (to avoid crashing in rough conditions = think big). When enough clearance is available (I guess 1m+ depending on size of drone) we can do some sort of gyro stabilization similar to the auto-tune stuff.

Just some random ideas, I find this fascinating. Logically we need need intra-APM communication mechanisms first, like Antenna Tracker but baked into the core. That could even bring new features like swarming, a good test case for that core feature. We need swarm/relative positioning to get the boat landing you see, it's kind of a variant of the same thing. The Antenna Tacker could also be refactored then to re-use the same code.

p.s. if Pixhawk is not powerful enough to do all this then the new GPS RTK "REACH" product from Emlid could help as a peripheral, or their existing NAVIO+ Pixhawk on RasPi (Linux) also has GPS RTK support. http://www.emlid.com/reach/ I just got one of those on a RasPi2, so in addition to my existing Pixhawk should be able to test this RTK stuff.

[nicksargeant]

Precision landing is largely a separate issue and there are numerous solutions being developed (see ir-lock for example). A competent pilot should be able to land a multirotor on deck, but before you worry about landing, the multirotor needs to be able to initialise, arm and deploy from a boat.

[rmackay9]

@CodeChief, the idea to use a separate APM for the gyro cal (or to speed up the EKF stabilizing) is an interesting one. I'll pass it onto Paul Riseborough.

[rrr6399]

I ran into this issue recently as well. We could not get the copter to pass the prearm checks (velocity error and gyro health errors.) I started an experiment to disable the prearm checks and perform a hover test, but ran out of time.

I was wondering if it'd be possible to perform the prearm checks on land before getting on the boat and having any required calibration data saved. Then at sea, the saved data would be used (except for home) for calibration and safety check purposes. Even though this process is not ideal, would it work?

[rmackay9]

@rrr6399, yes if you arm once on the ground and then put the copter into the boat then it should be ok.

[govsux]

Arming on the ground then getting on the boat isn't real practical at least for me because where I fly is a mile from the boat ramp. About the only way I was able to have it work was to hold the quad and do my very best to keep it steady while the boat was rocking with the waves as it armed. It doesn't work very well. Hanging it by a string/s would work but again not real practical. Seems like if there was a way to have ch7-9 allow 'boat mode' which you would arm the copter on land then 'save' those calibrations to 'boat mode calibrations' then the next time you fly in boat mode it would use those.

[govsux]

re- This can be disabled by setting the ARMING_CHECK to Skip INS.
Would this effectually then use the last know calibrations?

[rmackay9]

Yeah, the arming on land isn't a long-term solution. I talked with Paul Riseborough this morning and I'm pretty certain we will get the improved gyro-cal which doesn't require the copter to be completely stable into AC3.4.
Disabling the arming-checks helps some but there's still one gyro calibration on the first arming that isn't optional. It'll try for up to 30seconds but if it can't get a good calibration it'll fail to arm.

[rrr6399]

Why does gyro calibration have to be done every power on? (Or arm?) Could it use last known good instead as a workaround? That would allow cals on level land, power down and then power up the boat, arm and launch.

Or, does it currently need a stable state at takeoff to reference?

[R-Lefebvre]

Actually I thought we did have an option to allow booting without calibrating gyro. It uses the numbers from parameters. I think Triage does this with planes?

[rmackay9]

the SKIP_GYRO_CAL param.. indeed. sadly it's only implemented in Plane. I looked at adding it to copter but I saw too much drift. If it was implemented, I imagine it would work, you'd just need to leave the copter a long time to let it learn the change in offsets from the previous boot.

[govsux]

Dang. Need a sensor that only see gravity? I work in construction and use a rotating laser level. It finds level right away. Then again it has an advantage it's spinning. And I never used it in a boat :] Would there be a way of asking the gyro to take snap shots of the full 360 [ with the help of the compass ] simulating spinning then average it out? Or maybe that's what it basically already does? Easy for me to say I'm just the carpenter.

[rmackay9]

@govsux, it just measures it's rotation rate really quickly in very short bursts and then averages the results. It does that a couple of times and checks that all the averages match. The problem that they don't match if the boat is rotating left, then rotating right relatively slowly.
What we need to do is extend that period of averaging so that it's really long. So say the boat rocks back and forth maybe once every 5 seconds.. we need to average over a 10s period.

[govsux]

Just fyi the time frame back and forth is more like 2-4 seconds. Splitting hairs.. but just saying, Because 5 seconds plus probably starts to get to boats much bigger and thus not even having a problem.
If the options were A- start by arming whilst bending your knees then double check it worked by holding the copter and going 1/2 throttle to check if it tries to stay level or off by a few degrees [ while the boat is rocking no less ] OR B- arm copter like normal but wait 30-60 seconds I'd got with B every time! If that was the beginning of 'beta boat mode' I'd say that's a great start!

[rrr6399]

@rmackay9, what is the reason for the gyro drift? When you say leave it for long time, do you mean let it sit on the ground after powering it up for a long time or arming it and leaving it for a long time or something else?

[rmackay9]

@rrr6399, The gyro offsets seem to change quite a bit from boot to boot. Maybe it's the temperature change or maybe it's just that we need the offsets to be really accurate. In any case, if we don't get those offsets really close (i.e. within 0.1 deg/sec) then you'll see the HUD rotate badly especially after arming because at that moment we increase reliance on the gyros.
The EKF will learn the gyro offsets at the rate of about 1 deg/sec. So if you manage to arm it once and then leave it sitting on the ground (or even leave it on the deck of a moving boat) long enough it'll get the offsets right and the HUD will remain stable.

[govsux]

Any movement on this?

[rmackay9]

@govsux, not yet - stlil working on getting AC3.3 out the door, but AC3.4 will certainly include this ability.

[govsux]

@rmackay9 Good to know. Thank you! Can't wait to test it out. Still flying 3.2 [ seems like you have a lot of testers for 3.3 so I passed this phase ] but will be more than happy to test 3.4 when it's ready :]

[antslake]

I recently did a "job" filming boat races from a boat. We had a lot of difficulty arming. I definitely could use a boat mode. Speaking from ignorance, would an alternate way of doing this would be to have a second gyro that you initialize on shore, then somehow use that as a reference for the main gyro. A virtual gimbal so to speak? Second problem is initializing gimbals.

[ballan33]

Could you arm on land and then just keep it powered? Obviously you would need to change batteries, but could this be done by hot swapping on a parallel adapter? I understand this isn't ideal, but would it work for the time being? As long as the copter doesn't turn off, you don't need to do a re-calibration.

I'm still fairly new to multirotors, so please let me know if there is a reason this would be a bad idea.

Thanks

[antslake]

Last boat race I filmed was 10 hours long. Of course you aren't filming the whole time, but it is impractical to keep it powered that long. I also had no access to the shore until tthe race was done, so if something happened and I lost power, I would be out of luck.

[magicrub]

There is a large ekf update in the pipeline. One of its new features will
be arming while on a boat. No ETA, just giving you a little hope.
On Jul 7, 2015 7:03 PM, "ballan33" [email protected] wrote:

Could you arm on land and then just keep it powered? Obviously you would
need to change batteries, but could this be done by hot swapping on a
parallel adapter? I understand this isn't ideal, but would it work for the
time being? As long as the copter doesn't turn off, you don't need to do a
re-calibration.

I'm still fairly new to multirotors, so please let me know if there is a
reason this would be a bad idea.

Thanks

—
Reply to this email directly or view it on GitHub
https://github.com/diydrones/ardupilot/issues/1361#issuecomment-119398771
.

[nicksargeant]

@magicrub, are you refering to Paul Riseborough's post here: https://groups.google.com/d/msg/drones-discuss/fP6l7EnOF88/aEL1Z9eqq0YJ
Very excited for this.

[magicrub]

Yup
On Jul 7, 2015 9:57 PM, "nicksargeant" [email protected] wrote:

@magicrub https://github.com/magicrub, are you refering to Paul
Riseborough's post here:
https://groups.google.com/d/msg/drones-discuss/fP6l7EnOF88/aEL1Z9eqq0YJ
Very excited for this.

—
Reply to this email directly or view it on GitHub
https://github.com/diydrones/ardupilot/issues/1361#issuecomment-119433663
.

[ballan33]

Thanks @antslake. I know it would be difficult, but keeping a single battery (8000 4S in my case) just for powering the multirotor on the boat but not for flying would last all day. This would mean you only really need to carry 1 more battery than you would have to normally.

I understand that 1 mistake with battery changeover would render the multirotor unusable, but my bigger question is whether it would be safe to hot swap using a parallel adapter? After a flight you'd be going from a battery at 20-30% capacity and connecting a battery at 100% capacity. I know they will start to balance between themselves, but unplugging one and plugging in another would only take seconds. Does anyone know if the abrupt change in voltage would damage the batteries/multirotor?

Thanks

[govsux]

re- battery swap No that wouldn't hurt anything I don't think.
Lets keep our fingers crossed on that EKF update!

[AndKe]

@ballan33 depending on internal resistance of your batteries, connecting a full and depleated pack will cause high current. A diode and lower voltage ground power would fix that.
Voltage changes are not a problem

[ballan33]

Thanks @AndKe, I was thinking of using XT-90S anti-spark connectors to help with sparking issues, but I was wondering if you could provide more information on the type of diode set-up you describe?

Thanks!

[govsux]

@ballan33 I connected one fully charged pack with one drained pack in parallel for 15 seconds without issue. Small gauge wire between them didn't even get warm. Very small spark similar to what you see just connecting a pixhawk. So the internal resistance of the pack is minimal. Not much current flow between the battries. I think you'd be fine with just a basic Y connection.

[ballan33]

Thanks very much for testing it @govsux, and fantastic result! This gives me an option for my splashdrone (modified with APM) until a better solution comes along.

[R-Lefebvre]

Another option would be to use a special harness based on female balance plugs, using only the positive and negative wires, and some resistors to reduce the power flow between batteries. When doing the battery hand-off, you'd first connect the special balance harness to the old battery, disconnect the main connector from the old battery. Then connect the balance harness to the new battery. Disconnect the balance harness from the old battery, then connect the main connector to the new battery.

Slightly complicated and overkill, but it's a thought.

[govsux]

Not to be pest just hoping there is some movement here. I flew off my boat this weekend I haven't done so since a couple versions ago pre 3.2 I think,,,, Something changed I could not get it to arm at all unless I skipped the pre arm checks and even then it took a LONG time to calibrate and arm. After I took off it sort of wigged and said it had a EKF variance.. scary as I just installed my first gopro and I was of course over water. All ended well... but I would sure love not turing off checks. Hoping boat mode get's the nod for 3.4. I wish I could do more than just complain but code isn't my cup of tea. But as mentioned I would be happy to test and knowingly take the risk over water for the cause. Without the gopro though :]

[CodeChief]

+1 for that, but perhaps it should be called/developed as a more generic "Take-off from moving platform" mode (with a shorter name of course) rather than the specific "boat mode". I'm thinking about those FliteTest videos where they launch a plane from a moving quad bike, an "aircraft carrier" or "roving home" in a mission to Mars scenario. All professional examples that justify some development.

I think base stations will become more attractive (think RTK 1cm GPS accuracy, WiFi relay and antenna tracker features) as these various libraries/components are updated to support them. Professionally they are really a requirement.

Taken further, multiple "stations" or "mobile platforms" could be defined. Think drone delivery or RTK reference points for stationary "stations". I was thinking about mesh networking, recharge points and the like. But that's way off in the future. To start with we just need to take-off relative to the platform we are sitting on.

Perhaps "Platform" mode is a nice short name for this?

EDIT: for implementation are we not simply using the external (e.g. boat/platform) sensor as our own temporary additional sensor and mixing that into the EKF math with higher priority, for the first meter or two? Maybe supporting temporary external sensors via MAVLink would be the way to implement this. Think about a space capsule docking which will switch to the video from the space station (looking back at itself) just before it docks to line-up. Temporary external sensors are really a good way to go.

Then perhaps the "Docked/Docking/Dock" mode name might be more appropriate. That fits even better, like Star Wars when you fly near the station you are automatically landed or limited in speed/agility until you leave the docking area. Now I really like that feature!!!

[rmackay9]

@priseborough and I discussed this again a few days ago. There are a few changes required but the most important is the removal of the 2nd gyro calibration that happens when you arm (just the first time you arm). We need to get rid of that and we know basically how to do that so it's just a matter of time. It'll be in AC3.4 for sure though.

[priseborough]

My work on the updated EKF maths is sitting here:

https://github.com/priseborough/ardupilot/tree/ekfNewMaths-wip

So far it has only flown on an Iris, but did demonstrate its ability self align whilst moving. It needs to be rebased again on Master (basically replace the entire AP_NavEKF.cpp and AP_NavEKF.h file).

Takeoffs from a steel deck with large magnetic interference could be an issue unless we delay using GPS for the first few metres of height gained or use some other external data to initialise heading.

I plan to resume work on this branch in a few weeks.

-Paul

[govsux]

re-Takeoffs from a steel deck with large magnetic interference could be an issue unless we delay using GPS for the first few meters of height gained or use some other external data to initialize heading.

%99 of users aren't on a steel deck I don't think?? But either way thank you for working on this!! No pressure but summer [ boating weather ] is winding down for us poor chaps in the norther hemisphere. Thanks

[rmackay9]

Copter-3.3 includes the metal deck fixes from Paul including a reset of the compass heading once the vehicle is about 1.5m off the deck. It's more the compass that gets upset rather than the GPS I think.

[priseborough]

We can take off using GPS on a metal deck, if we are prepared to trust our compass readings to come good when the height increases. it just means we can't check compass health before takeoff unless there is another compass co-located that sees the same field.

[rrr6399]

FYI: I noticed that the Mikrokopter folks handled the boat launches by saving the gyro calibration parameters during accelerometer calibration and then allowed the pilot to optionally choose to use the saved gyro settings when taking off from a moving platform:
http://wiki.mikrokopter.de/en/Firmware-2.08#Boat_Mode:_Switch_on.2C_calibrate_and_start_under_moving_conditions

[rmackay9]

The ability to disable the gyro calibration is in master now and will go out with Copter-3.4.
The parameter to control the behaviour is INS_GYR_CAL:
0 = never do gyro calibration
1 = do once at startup
2 = do once at startup and once again during first arming

"1" is the new default for Copter. For "boat mode" the user should set this param to "0".

[magicrub]

I know this is probably too late to mention, but why use _GYO_ instead of
_GYRO_ ?
On Oct 2, 2015 9:02 PM, "Randy Mackay" [email protected] wrote:

Closed #1361 https://github.com/diydrones/ardupilot/issues/1361.

—
Reply to this email directly or view it on GitHub
https://github.com/diydrones/ardupilot/issues/1361#event-425862901.

[rmackay9]

@magicrub, the other gyro related parameters (like INS_GYR_OFFSET) all used just "_GYR_" instead of "_GYRO_".

[govsux]

Great!!!!!! Thanks!!! Any idea when 3.4 beta will be available?

[rmackay9]

@govsux, it'll be months and months before it's the official release but we will probably do some beta releases in a couple of months. Summer is slipping away in the northern hemisphere so I know that's not ideal but..

[govsux]

Thanks Randy. I'm just glad there seems to be a solution. Guess I'll just have to go to FL this winter to test it out. whooooo is me.. ha

[ballan33]

We're coming into summer in Australia (the land that has forgotten snow), and I'm happy to test it Randy.

[rrr6399]

FYI: I ran a simple test in the park where I performed simple hover test in guided and auto mode using INS_GYR_OFFSET=1 with prearm checks with the copter at rest. Then I set INS_GYR_OFFSET=0, cycled power and moved the copter around continuously to attempt to simulate a rocking boat until I got GPS lock. Then performed the hover test in guided and auto mode again. It worked flawlessly for this test! Looks promising!

[rmackay9]

@rrr6399, cool, thanks for testing!

[govsux]

I thought this wasn't available until beta 3.4?? How long has that param setting been around?

[rrr6399]

I used the latest 3.4 development version for testing despite the risks:
http://firmware.diydrones.com/Copter/latest/

(along with the beta version of the Mission Planner.)

[govsux]

oh I see... thanks. Only thing is I don't know how to direct APM Planner [ Mac user ] to use the downloaded file. I'll have to look into that. Obviously I'm not a 'code' guy :]

[rrr6399]

Yeah, it looks like APM Planner doesn't support loading downloaded firmware like Mission Planner does. From this page http://firmware.diydrones.com/, there is a section on uploading firmware on Linux and Mac to PX4FMU, which I'm assuming would work for the Pixhawk:

To load a PX4FMU firmware on a Linux or MacOS machine you will need to use the px_uploader.py python script. You can run it like this:
python px_uploader.py --port /dev/ttyACM0 px4fmu.px4
After starting the script, press the reset button on your PX4FMU to make it enter bootloader mode.
(It might be simpler just to find a Windows box or use Parallels on your Mac and use Mission Planner though.)

Be sure to recalibrate your copter after the firmware update.

[govsux]

great many thanks rrr6399!

[billbonney]

You can upload custom FW in APM Planner 2.0, you just need to file you want to install downloaded to your HD. You will need to select File->Advanced Mode to see the option in the Install Firmware view. You can download the 'beta' releases easily as well.

[govsux]

@ Bill ohhh gotcha so the 'custom' button... I should have figured that out. Thanks!

[rrr6399]

Weird, my version of APM Planner on Windows doesn't have those buttons:

Glad that it should!

[govsux]

Make sure you click on the 'advanced' button under the file menu. That might be it.

[rrr6399]

You're right! Who would've known! :-)

[govsux]

FYI I installed the dev version PX4v2 0036002D 30345101 37383933 and tested 'boat mode' and it worked great!! My boat is put away for the winter but I armed it holding it in my hand [ which was almost impossible with 3.3 ] and it worked flawlessly. Several times I armed it whilst moving the copter around as much or more than I would ever expect in my boat and each time it flew perfectly level just as though I had taking off from a solid surface. I did not do anything with the params, settings, didn't even recalibrate the compass or IMU's it just worked great right out of the box so to speak. I did not do any other testing of the code just as mentioned above. It does seem to take a few seconds longer to boot up the pixhawk than before. But no error codes thrown. Seems good :]

[rmackay9]

@govsux, excellent, thanks for testing!

[TerryPts]

This looks very promising. Thanks Rick for your tests and Randy for your hard work. Any chance that 3.4 will be released before spring?

[rmackay9]

@TerryPts, yes, very likely before spring. We're working with the Solo guys to merge their fork with master and the most efficient thing to do would be to start testing Copter-3.4 in early Jan. That will mean Copter-3.4 will be a little lighter on features than originally planned but this one would be included for sure because it's already done.

[govsux]

I'd like to test 'boat mode' in the FL keys over the Christmas holidays while I'm there. Not to mention some great video. Have you been flying dev 3.4 for long Randy? I know there's no guarantees but is there anything with the code that seems iffy? I'll pass if there are for sure known bugs not ironed out. Either way it's at my own risk of course.

[rmackay9]

@govsux, I fly master quite often and generally it's fine.
It changes nearly every day though so it can be fine one day and not the next. We always try to keep master reliable and flyable but sometimes we make a mistake. Besides that, it's difficult for the dev team to support people flying master because we can't make assumptions about what's in/out of the code so we have to consider the possibility of bugs in all parts of the code.
Anyway, in short, my guess is you'll be fine but you know.. as you say, it's at your own risk.

[govsux]

Yea that all makes sense thanks Randy

[govsux]

FYI 3.4 PX4v2 0036002D 30345101 37383933 auto, pos hld, alt hld, stab, no noticeable problems. It's nice not to have to baby sit the thing for 30 seconds until it's done booting. :] Seems like it's not as good in loiter / pos hold as 3.3 but hard to tell probably just me. I set boat mode to '3' aka never re-cal imu's. . Many flights no issue arming even whilst moving.

[govsux]

FYI 3.4 PX4v2 0036002D 30345101 37383933 I had many many flights launching and catching by hand in my boat over a 2-3 week period with no issues. Awesome. Thanks!

[nicksargeant]

Thank you for the report @govsux. I look forward to beta testing "boat mode" in 3.4!

[StepperUser]

@govsux , I've tried to put FW beta v3.4 but there is no "boat mode" neither something called alike, I've been looking each parameter and lot of them have been renamed in comparision with v3.3 and have no description. How did you did it? I'm very interested in testing this "boat mode" and don't wanna wait until 3.4 stable release :)

[rmackay9]

@StepperUser, there's no new "boat mode" so to speak. Basically you can just power-on and take-off in regular Loiter mode (or whatever flight mode you want) and it should just work.

[StepperUser]

Yes, I tested yesterday and it works, thank you @rmackay9! :100:
It's a pitty that in order to know which parameter is which because some of them have been renamed, but for sure will be solved for the stable release :)

[StepperUser]

@rmackay9, I think I found a bug. When powering the quadricopter, if I try to arm before finding 9 satellites then it will never arm, have to disconnect, connect, wait until reaches the number of satellites and then it works perfectly. Amazing work what you are doing with v3.4!

[OXINARF]

@StepperUser that's a support question, please post in the forum (http://discuss.ardupilot.org) together with a log.

[StepperUser]

Done, @OXINARF , sorry for my mistake.

[antslake]

Now that we can arm our copters on a rocking boat, has anyone figured out how to arm the gimble for the camera?

[lvale]

@antslake post in the forum (http://discuss.ardupilot.org)

[rmackay9]

@StepperUser, The issue will most likely be that the circular fence is enabled. To enforce the fence it needs to know it's position so it requires the GPS..

[ytlee]

For boat landing, can we program a "kill" switch that instantly cut off all the motors, as for boat takeoff, can the user do the gyro on land first, when it is in boat mode, just skip the calibration and use existing (previous) value.

[lvale]

@ytlee This might not be the best place for support questions, but yes, just program one of the options as the kill switch.

[govsux]

@ytlee I have thought the same thing. I hand catch mine now because the odds of me bumping something with a prop is very high trying to land in such a tight space. I have often thought if I had a small net suspended in my boat that if I could kill the motors whilst I have the quad directly above the net it would catch it nicely.

[lvale]

https://www.youtube.com/watch?v=-Db4u8LJE5w

http://ardupilot.org/copter/docs/channel-7-and-8-options.html?highlight=ch7#auxiliary-function-switches

[R-Lefebvre]

Wow, those are some fantastic features. :)

[dposea]

I thought I would toss in my $1000 testing with a Phantom. 23 foot Grady White in 3-4 foot seas. The only really decent launch spot was the top of the transom where there is a 15"x15" cooler built in. After arming the drone would speed up and slow down props to compensate for wave action. To launch I just punched the throttle, rocketing up 100 feet. No issues.

Landing is almost impossible. You can not match the deck lean to the drone without the drone moving in the lean direction. On about attempt #4 I hit an outrigger and drone went to visit the fishes :(

Second attempt, all rods not in holders, riggers extended outwards, brave buddy in the back of the boat. Speed increased to about 10 mph to steady out the boat, and direction picked to minimize roll. I just flew the drone right over the motor then slowly guided it into grab range. He grabbed the gear and I instantly killed the rotors.