Follow-me mode

103 views
Skip to first unread message

John Wiseman

unread,
Jan 4, 2013, 12:06:34 AM1/4/13
to mave...@googlegroups.com
I realized we might be able to do a useful "follow me" mode in Mavelous, along the lines of what Pat has previously implemented: http://code.google.com/p/ardupilot-mega/wiki/FollowMe

In follow me mode,

The mavelous front end would begin requesting GPS coordinates using the W3C geolocation API, using the watchPosition method and specifying enableHighAccuracy: true.

The front end could provide a different interface that would make it easy to select the follow-me range and bearing--maybe the map would be centered on your position, and wherever you touched on the map would define the follow distance and bearing.  We might also have RTL and LOITER/CANCEL buttons.

The server would continuously send GUIDED mode waypoints to keep the vehicle at the requested range and bearing.

The "TP-Link Portable Battery Powered 3G/3.75G Wireless N Router (TL-MR3040)" that Pat previously pointed out is only 3.4 ounces, which is lighter than an iPhone, so I think it could work as part of the portable follow-me setup.

I did some testing with an iPhone 4 and Galaxy Nexus using the geolocation API, and the reported accuracy is between 5-10 meters, with position updates coming every couple of seconds.  If there's cell (or wifi) coverage, a phone could even have an advantage over a dedicated GPS chip/device that didn't do A-GPS.

Any thoughts?


John

Greg

unread,
Jan 4, 2013, 1:43:16 AM1/4/13
to mave...@googlegroups.com

I'll gather up some test hardware.   I have both iphone4  and galaxy siii devices to test with.   

--
 
 

Pat Hickey

unread,
Jan 4, 2013, 2:06:01 PM1/4/13
to mavelous
Sounds like a good idea to me.

Currently, the standalone followme code is bit rotted and I should spend some time getting it back into shape. The state machine is simple enough, though - the only complicated part is to implement it so the user can override the repeated guided commands from the rc controller (important for safety). The solution is to logically separate the commands to give a new guide waypoint, and switch into guide mode - currently, both of these events are triggered by the guide mode nav command. Because we can only observe the mode state perodically (via heartbeat), we can't be sure a new guide mode nav command won't switch the vehicle right back to guided mode after the user overrides via the mode switch.

I asked the ArduCopter developers to look into this but never heard back, so I'll probably have to do it myself. 

Pat

David Court

unread,
Oct 22, 2013, 5:13:16 PM10/22/13
to mave...@googlegroups.com

For what it's worth, I've been experimenting a little with this on Raspberry Pi.

Currently I haven't bothered much to integrate properly with the Mavelous front end - just a simple button that takes you to a separate, trivial web page that allows adjusting height, seconds of delay, and start/stop the follow-me mode.  When sending position updates, it just uses the /guide URL on the main mavelous back end, which seems to work well enough in theory, and at home - I can watch mavlink messages being sent over the telemetry link, with sensible coordinates and timing.  The resolution seems to be very good with an iPhone 5 - generally around 5m, and it does seem to update plausibly as I move around.

But the odd thing I've noticed, and I tend to notice this with Mavelous running standalone on the Pi too, is that eventually it seems that responses seem to slow down over time, and eventually everything just seizes up.  I have a measurement of server response time on the follow-me page, and it tends to go from around 150-200ms at start of day, to eventually degrade to 30secs+ as things start to seize.

I'm not sure yet why this is happening, but it does seem to prevent me from using follow-me at all seriously, and so I haven't yet put in any effort to merge my code properly into the front end.  The only theory I have so far is that mavelous + mavlink are using a lot of the Pi's available CPU - around 90% or so, according to top - and I suspect that the Pi just can't keep up with the demands of serving mavelous.  

If I have a chance, I'll try to look into profiling and optimising the processing somehow - in particular, I've heard bad stories about lagginess and stuttering in CherryPy under load, so possibly that will be a good place to start.

In the short term, though, I think I'll just settle for an Arduino + GPS + telemetry module, running the FollowMe sample code from the Arducopter repository.  I expect that will be more reliable in the short term, and will certainly be a bit more compact (albeit with much less function) than my current Pi-based setup.

Pat Hickey

unread,
Oct 22, 2013, 5:21:57 PM10/22/13
to mavelous

Cool to hear you've had success with this so far. I haven't taken any time to hack on Mavelous lately but I'm glad to hear that it still works for you.

On Tue, Oct 22, 2013 at 2:13 PM, David Court <david.c...@gmail.com> wrote:

I'm not sure yet why this is happening, but it does seem to prevent me from using follow-me at all seriously, and so I haven't yet put in any effort to merge my code properly into the front end.  The only theory I have so far is that mavelous + mavlink are using a lot of the Pi's available CPU - around 90% or so, according to top - and I suspect that the Pi just can't keep up with the demands of serving mavelous.  


That CPU usage seems really high, even on a not-so-great CPU like the RPI's. How are you starting Mavproxy? In the past, I've seen some folks have trouble when starting Mavproxy via a rc script or otherwise - it doesn't deal well if there isn't a tty attached to stdin/stdout. Starting it inside GNU Screen or tmux will solve this problem. 


Reply all
Reply to author
Forward
0 new messages