MAV Takeoff

[akabaker]

Added ground takeoff functionality via the command_long method in mmap.py. This method will allow for the MAV to lift off to 10m and enter loiter mode. A 'takeoff' button was added to the flight commands menu.

[pchickey]

Hi Luke, thank you for your contribution.

A few comments:

• This doesn't currently merge on top of master. Can you please perform a git rebase on top of origin/master? An interactive rebase would allow you to squash the rewritten code into logical commits.
• I'd prefer if the user had to first click arm in the client, then takeoff - the arm button is there as a safety measure. I hope to replace it with something a little safer, in the style of the iphone slide to unlock, soon.
• I'd prefer to keep the server logic much thinner, and never use time dependent events like sleep inside the server.

Could you change the timing of the takeoff events (throttle override, wait, send mission item message, wait, loiter) to be implemented in the client? You could refactor the server api to just expose the mission item message, and do everything else in terms of the existing APIs. I think doing all this in the client will pay off in simplicity in the long run - for instance, implementing the event stream on the server makes it difficult to support either canceling the events midway through, or handling other commands while these are ongoing. On the client, that wouldn't be a big issue.

[akabaker]

Sure, I'll take a swing at it. Backbone is still new to me (thus my hesitancy to touch the client side), but this is a fun reason to get more intimate with the framework.

For implementing these features, would you prefer another pull request or some kind of review via gist in the google group or email?

[pchickey]

Cool. Either of those sounds great. You can mail me directly if you need help with backbone.

On Sun, Sep 23, 2012 at 10:44 PM, akabaker notifications@github.com wrote:

Sure, I'll take a swing at it. Backbone is still new to me (thus my hesitancy to touch the client side), but this is a fun reason to get more intimate with the framework.

For implementing these features, would you prefer another pull request or some kind of review via gist in the google group or email?

— Reply to this email directly or view it on GitHubhttps://github.com/wiseman/mavelous/pull/17#issuecomment-8808015.

[wiseman]

I was thinking a little about the question of where the sequencing of primitive actions should occur.

That is, takeoff is a sequence of adding throttle, waiting a while, pulling back on throttle, and sending a waypoint (or whatever the steps are).

One concern I have about doing this on the client side is that it may be less robust: Closing the browser window or a little wifi slowdown are two new failure modes. You should have radio control at all times, but still I think it would be unfortunate if i accidentally command-W my browser window right after throttle up is sent.

I tend to think the sequencing should happen on the server side, but it needs to be robustly asynchronous--no sleeps, no blocking the main loop.

Are there other sequenced actions that could be useful besides takeoff?

John

On Sun, Sep 23, 2012 at 10:45 PM, Pat Hickey notifications@github.comwrote:

Cool. Either of those sounds great. You can mail me directly if you need help with backbone.

On Sun, Sep 23, 2012 at 10:44 PM, akabaker notifications@github.com wrote:

Sure, I'll take a swing at it. Backbone is still new to me (thus my hesitancy to touch the client side), but this is a fun reason to get more intimate with the framework.

For implementing these features, would you prefer another pull request or some kind of review via gist in the google group or email?

— Reply to this email directly or view it on GitHub< https://github.com/wiseman/mavelous/pull/17#issuecomment-8808015>.

— Reply to this email directly or view it on GitHubhttps://github.com/wiseman/mavelous/pull/17#issuecomment-8808024.

[pchickey]

On Wed, Sep 26, 2012 at 1:21 PM, John Wiseman notifications@github.comwrote:

One concern I have about doing this on the client side is that it may be less robust: Closing the browser window or a little wifi slowdown are two new failure modes. You should have radio control at all times, but still I think it would be unfortunate if i accidentally command-W my browser window right after throttle up is sent.

That's a really good point which I hadn't thought about. We should change the semantics of the RC Override API a bit to always include a relatively short timeout before going back to the user input.

I agree with the rest of the points you make - that it makes sense to do takeoff as a server side state machine. It would make even more sense to implement an auto takeoff entirely on the arducopter, though, for the same reasons.

I'm happy with getting a basic prototype done on either the server or client for us to play with in the field a bit. Once we have something that works, we should try to get one of the Arducopter maintainers to build it as an onboard state machine triggered by a nav command.

[akabaker]

We've tested the 'old' takeoff method in the field with a 'trash' quad and it ended in tears (it didn't help that GPS was lost mid-flight). The quad tookoff at about 5 meters and then continued to drift

[image: Inline image 1]

I cleaned up the original (but still blocking) takeoff method and added a loiter at the end.. in the SITL this seems to work much better. Haven't had a chance to try it out, currently traveling.

elif m['command'] == 'NAV_TAKEOFF':

The MAV_CMD_NAV_TAKEOFF command returns '3' when sent, so this is a

  #hack to get the quad off the ground

  #10m
  takeoff_alt = m['alt']

  #Throttle up
  self.rcoverride({'ch3': 1500, 'ch4': 0})

  #Wait a second and then hold throttle
  sleep(1)
  self.rcoverride({'ch3': 1315})

  seq = 0 # Mission command sequence number
  # NOT a coordinate frame, indicates a mission command, see mavlink

common.xml frame = mavlinkv10.MAV_FRAME_MISSION cmd = mavlinkv10.MAV_CMD_NAV_TAKEOFF param1 = 0 # Hold time in seconds. param2 = 5 # Acceptance radius in meters. param3 = 0 # Pass through the WP. param4 = 0 # Desired yaw angle at WP. x = 0 # Not used in mission frame y = 0 # Not used in mission frame

APM specific current value, 2 means this is a "guided mode"

  # waypoint and not for the mission.
  current = 2
  autocontinue = 0
  msg = mavlinkv10.MAVLink_mission_item_message(
  self.module_context.status.target_system,
  self.module_context.status.target_component,
  seq, frame, cmd, current, autocontinue, param1, param2, param3,

param4, x, y, takeoff_alt) self.module_context.queue_message(msg)

  #Wait 2 seconds then enter loiter mode
  sleep(2)
  self.loiter()

Just a note.. I was able to adjust the takeoff view on the front end to wait for an 'armed' message from the mode model, among others. Anyway, good discussion - having a complete mission from takeoff to land is still a much desired goal : )

On Wed, Sep 26, 2012 at 3:49 PM, Pat Hickey notifications@github.comwrote:

On Wed, Sep 26, 2012 at 1:21 PM, John Wiseman <notifications@github.com

wrote:

One concern I have about doing this on the client side is that it may be less robust: Closing the browser window or a little wifi slowdown are two new failure modes. You should have radio control at all times, but still I think it would be unfortunate if i accidentally command-W my browser window right after throttle up is sent.

That's a really good point which I hadn't thought about. We should change the semantics of the RC Override API a bit to always include a relatively short timeout before going back to the user input.

I agree with the rest of the points you make - that it makes sense to do takeoff as a server side state machine. It would make even more sense to implement an auto takeoff entirely on the arducopter, though, for the same reasons.

I'm happy with getting a basic prototype done on either the server or client for us to play with in the field a bit. Once we have something that works, we should try to get one of the Arducopter maintainers to build it as an onboard state machine triggered by a nav command.

— Reply to this email directly or view it on GitHubhttps://github.com/wiseman/mavelous/pull/17#issuecomment-8905183.

[wiseman]

Any objection to closing this request? https://github.com/wiseman/mavelous/blob/master/modules/lib/mavelous_server.py#L74 shows an example of sending multiple commands asynchronously and https://groups.google.com/forum/?fromgroups#!searchin/mavelous/takeoff/mavelous/duCk48FmzTg/vUkkA95qMtQJ has a little more info about takeoff.

[akabaker]

No objections, thanks for the feedback.