I wrote a feature for ArduPlane that allows the home position to be somewhere else than where the APM was started. This is useful for flight under "flying line" rules or if you want to ready your plane in one place and fly it from another.

The feature was requested and discussed in this thread and here. My modified code is here.

The original APM behavior: Home position is set to one of the first positions the GPS reports after powerup. Even if you desired another position as home. The position is written into waypoint 0 too, so you will see the home position by (re)loading the mission into MP.

Modified behavior: There is a new parameter STICKYHOME_RAD, in meters. If the GPS position is nearer than this from waypoint 0, home will be se to waypoint 0. Otherwise it will remain unchanged and the controls will wiggle 3 times. This allows one to set an alternative home position without risking a flyaway of more than STICKYHOME_RAD meters. In this version, I have removed the servo wiggling at normal startup because I find it unnecessary and it makes my planes rock'n'roll at gyro calibration. Wiggling = something was not as expected.

Waypoint 0 is only overwritten if it was previously undefined. Reading the mission, the waypoint 0 read is the one last written. Any reason to change that?

There are a few console messages too. It appears that not all get though because they come in a too rapid succession. See init_home() in commands.pde.

The home altitude may be quite inaccurate too, because GPS takes some time to get altitude right. If you fly with pure baro altimeter (ALT_MIX=1) and you use relative-altitude waypoints, you will not be affected. Funny enough, this is default. I fly in hilly terrain and need to check my missions carefully against Google Earth etc. and therefore need absolute altitude. I often get home altitudes that are 100s of feet off, potentially disastrous if not rejected.

To try solve that problem, the altitude of waypoint 0 is also used. If the horizontal distance to waypoint 0 was OK, the GPS altitude is compared to the waypoint 0 ditto. If off by less than STICKYHOME_MAD (Max Altitude Deviation), the altitude of waypoint 0 is used for home. Else, the controls will wiggle 5 times.

So all in all

No wiggles: Waypoint 0 was undefined at startup, or both position and altitude were within bounds of waypoint 0
3 wiggles: Position was not within bounds of waypoint 0. GPS position and altitude were used for home3 wiggles:
5 wiggles: Position was within bounds of waypoint 0 but not altitude. GPS altitude was used for home. Recommended action if using absolute altitude: Wait a few minutes, try reset APM.


For consideration: When reading the mission, should the EEPROM stored waypoint 0 be returned as waypoint 0, or should the actually used home position (which is the same if within bounds)?

If postion is OK but altitude is off, should the APM go into a wait loop until altitude is OK?

Views: 453

Comment by Tommy Larsen on August 20, 2013 at 1:17pm

This function is already in MP. Just click the Lat field in "Home Location" down to the right corner in "Flight Plan" and you can set Home pos :)


Moderator
Comment by Nathaniel Caner on August 20, 2013 at 1:38pm

@Tommy,

Actually it's not, and that's the whole point. Go ahead and try it sometime and you will see that RTL still returns to the point where GPS Lock was first obtained, not where you told the MP to place WP0.

What WP0 does in the MP is set a different starting point for the mission. All distances to 'Home' reference WP0, which is under normal circumstances the same as 'Home'; however when you move WP0 to a new location and store it to the APM by writing the mission to the APM or by using the 'Home Location' button you mentioned all that happens is that you define a new starting reference for the mission that's not 'Home'. When you read the mission from the APM you are misled by the fact that 'Home' appears to have moved, when in fact only WP0 has moved.

@Soren

Thanks for the effort here, I hope to be able to try this soon! Have you tested it yourself? What revision of code is your mod based on?

Regards,

Nathaniel ~KD2DEY


Moderator
Comment by Nathaniel Caner on August 20, 2013 at 1:40pm

Any chance you can post a hex file to make it easier for more people to test it without having to compile the code?

Regards,

Nathaniel ~KD2DEY


Moderator
Comment by Nathaniel Caner on August 20, 2013 at 1:43pm

Looks like early 2.75 beta1 code base right?

Regards,

Nathaniel ~KD2DEY

Comment by Søren Kuula on August 20, 2013 at 2:08pm

Hi,

I gotta get the code up 2 date. It is based on the beta as was about 2 weeks ago.

Any good ideas on what to do if startup location is too far off from waypoint 0? Warn and go ?

And altitude too far off? Warn and go, wait till GPS gets better or ignore, I think that are the options..

I have desk but not field tested it here.


Wiki Ninja
Comment by Gary McCray on August 20, 2013 at 2:56pm

Hi Soren,

Sounds like a great feature for copters too.

I also think that an absolute home override parameter should exist that will allow user to enter actual GPS coordinates of home just like waypoint.

I know the dangers of this and they should be illuminated, but in the final analysis, the user should have the choice.


Moderator
Comment by Nathaniel Caner on August 20, 2013 at 5:08pm

Hi Soren,

My original idea was that a simple logic check be performed at GPS lock. If the current GPS location is within STICKYHOME_RAD then keep WP0 as programmed with the MP, else store the current GPS location as usual. As far as altitude goes, I'm not sure how the MP treats it when you move the home location and write it to the APM but I think we may be over thinking the issue, the purpose here is only for an RTL location other than the startup location. The RTL location will be well above ground level, I think having a check that ensures the new altitude is within the range defined by STICKYHOME_MAD is sufficient.

Regards,

Nathaniel ~KD2DEY

Comment by Søren Kuula on August 20, 2013 at 11:55pm

Hi Nathaniel.

Yeah OK you are right about keeping it down to the basics...

I wanted to throw in a solution to a different issue that I often experience. ArduPlane often gets its GPS home alt pretty badly wrong. That does not matter if you use relative altitude in your flight plans - but I'm in mountains and I can only plan safely by looking at maps or Google Earth and using absolute altitude. If APM gets its home alt/ wrong the plane will fly too high or too low the whole mission. Wanted to add some safely for that.

Regards

Soren

Comment by Søren Kuula on August 21, 2013 at 5:16am

I have improved the GCS text messages so they don't get suppressed by other messages now.

Here is a test where the plane was powered up on my balcony. WP0=MP's home position was on the other side of the railway. The plane is in RTL mode. The map module of MAVProxy shows that it has snapped to WP0 as home position and is navigating there.

The firm is based on my personal version of ArduPlane but the relevant changes are easy to isolate.

Other changes (not relevant for here) are

  • Much smaller dead zones (hate 'em)
  • Auto trim is less tolerant about taking large stick deflections as trim values
  • Two UARTs can be used at the same time for telemetry
  • Comments added here and there

Regards

Soren


Moderator
Comment by Nathaniel Caner on August 25, 2013 at 5:09pm

Anyone get a chance to test out the feature this weekend?

Regards,

Nathaniel ~KD2DEY

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2014   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service