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 notifications@github.com 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 notifications@github.com 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" notifications@github.com 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" notifications@github.com 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.