Ardupilot: Waypoint zero (home) location retrieval not working if no mission ever loaded

[Pedals2Paddles]

Issue details

_Please describe the problem, or desired feature_
Has something changed with how the home location is stored/managed since 3.3 or how it is stored on the Solo's branch? The Solo's companion computer is unable to retrieve the home location from a freshly flashed or reset Pixhawk. But if I load a waypoint mission, it is then able to retrieve the home location. Even if you subsequently clear the mission by loading a blank one. You don't even need to fly the mission. Just having a mission loaded at some point seems to fix it.

The companion computer is requesting the home location by requesting Waypoint zero with this code:
`self.vehicle.message_factory.mission_request_send(0, 1, 0) # target_system, target_component, seq

The mission library indicates Waypoint zero (home WP) just calls AHRS.GET_HOME(). But if no mission has ever been loaded, it doesn't seem to get a valid response from requesting this waypoint.

Note, Mission Planner and other conventional GCS have no problem. It's only the companion computer retrieving the home location in this manner that has this issue.

Version

3.5rc-3 (untested on 3.4)

Platform

[ ] All
[ ] AntennaTracker
[X] Copter
[ ] Plane
[ ] Rover

Airframe type

Solo

Hardware type

Pixhawk 2

Logs

This is the full python code on the companion computer that is requesting the home location and failing as described above.

def loadHomeLocation(self):
        ''' Hack method to avoid Dronekit issues with loading home from vehicle'''
        if self.vehicle is None:
            logger.log("no Vehicle!")

        #load home from vehicle
        # total grossness for getting HOME_LOCATION! Should be done properly in dronekit instead
        self.vehicle.add_message_listener('MISSION_ITEM', self.handleMissionItem)
        # formulate mavlink message to request home position
        self.vehicle.message_factory.mission_request_send(0, 1, 0)  # target_system, target_component, seq
        #logger.log("loading home from vehicle2")

    def handleMissionItem(self, vehicle, name, msg):
        ''' Handles callback for home location from vehicle '''
        self.vehicle.remove_message_listener('MISSION_ITEM', self.handleMissionItem)
        self.homeLocation = LocationGlobal(msg.x, msg.y, msg.z)
        logger.log("[RewindManager] loaded home %f %f, alt %f" % (self.homeLocation.lat, self.homeLocation.lon, self.homeLocation.alt))
        # Send home to the App
        self.updateAppOptions()


    def updateAppOptions(self):
        ''' send home loc to App '''
        # f = float_32
        # d = float_64
        packet = struct.pack('<IIddf', app_packet.SOLO_HOME_LOCATION, 20, self.homeLocation.lat, self.homeLocation.lon, self.homeLocation.alt)
        self.shotmgr.appMgr.sendPacket(packet)

[magicrub]

Great description of the problem, thank you!

[proficnc]

So, I assume that Solo companion computer requires this for the smart RTL?

[Pedals2Paddles]

Exactly.

[peterbarker]

@Pedals2Paddles does the associated commit (https://github.com/peterbarker/ardupilot/commit/7062a0e8d032b9d0bb208e5e7a3a059194309ce9) fix the issue?

[WickedShell]

It there any reason you can't use the proper MAV_CMD_GET_HOME_POSITION command instead?

[WickedShell]

@peterbarker your patch looks reasonable however.

[rmackay9]

Yup, I vote for @peterbarker's fix too.

[Pedals2Paddles]

YAY! I think that will do the trick! Thank you @peterbarker. I Believe that will do the trick! Does this mean the fix will be in the next version Randy pushes out? Or does it go immediately into the firmware files currently up?

@WickedShell I think that mavlink command would ultimately be the proper way to get the home position, but we don't have control over the Solo's companion computer code to make it do that instead for the masses of users. It is what it is right now, so for instances like this, we have to work around it.

[rmackay9]

@Pedals2Paddles, the change isn't in master yet but probably safe to assume it'll be in the next -rc which will likely come out later this week.

[OXINARF]

Agreed that @peterbarker's patch looks correct and should fix this issue.

@peterbarker will you open a PR with it? Or just push it to master, I think we can be confident enough that CI will pass :slightly_smiling_face:

[peterbarker]

On Mon, 3 Apr 2017, Francisco Ferreira wrote:

@peterbarker will you open a PR with it? Or just push it to master, I think
we can be confident enough that CI will pass 🙂

Pushed.

[rmackay9]

.. and I've added to our backports so we don't forget to include in -rc4