Serving Mavelous from a Raspberry Pi

[Pat Hickey]

From a fresh boot of Raspbian this took about 15 minutes to get running. It's still routing through my home router, but next up is to get the RPi acting as the access point.

Pat

[John Wiseman]

Nice!

I have a Pandaboard I can try running it on, too.

These scenarios really call for some good source of map tiles for offline use.  Anybody know of one?

John

On Sat, Sep 22, 2012 at 5:43 PM, Pat Hickey <p...@moreproductive.org> wrote:

From a fresh boot of Raspbian this took about 15 minutes to get running. It's still routing through my home router, but next up is to get the RPi acting as the access point.

Pat

--

[Luke Baker]

I'm thinking something like this..

http://www.axismaps.com/blog/2012/01/dont-panic-an-absolute-beginners-guide-to-building-a-map-server/

I'm not sure if you would have the ram/storage/cpu on a PI however.

[Pat Hickey]

Unfortunately it does not look like there are any free sources of
satellite imagery at anywhere near the resolution we need. The Blue
Marble dataset is free but has a 500m resolution.

Bing and Google both provide the high quality satellite imagery we
need, but their ToS prohibits that data living anywhere except their
servers. We need to cache the data for offline use, but it will break
their ToS.

I could implement either of the following pretty easily:

- Implement a proxy server to Bing or Google Maps inside the mavelous
server, and cache fetched tiles to disk.
- Use the web browser's Local Storage API to implement caching.
Similar concept, different implementation, and less flexible for
connecting any device to your Mavelous server for getting maps - you
have to cache the map on each device separately.

Since we aren't making a profit off this code, and are just caching
tiles because an internet connection is unavailable, I see this as
morally "fair use", even though I'm sure the Google and Bing legal
teams would see it differently. I'm happy to leave my contact info in
the code that implements this and if they want to send me a cease and
desist[1], I'll take responsibility. However, if John wants to veto
breaking Google or Bing's terms, I am sympathetic to that viewpoint
and we'll drop this line of thought.

Best
Pat

[1] A number of other autopilot GCSs have been caching tiles for years
- Paparazzi has been doing this since at least 2008, when I first
looked into that project.

> --
>
>

[David Court]

I'm very interested in doing a similar thing with my Raspi - mavelous seems to be the ideal platform for my needs.

A few comments:

• Maybe there's a way to achieve caching in the client device rather than the mavelous server?  I haven't yet looked at the URLs and requests used for the map tiles, but if the client device can be used from within an internet-enabled environment to precache the relevant maps for the flying location, then I think that would be acceptable.  I'd be surprised if Google et al prevent any client-side caching.
• Setting up a Raspi to run from batteries, and automatically launch a wifi access point at boot time is nice and easy.  What seems harder however is to launch the mavelous server at boot time on a headless device - it seems that maybe mavproxy expects to be connected to a TTY?
• Are there any plans to include support for MAVLink parameter viewing and editing to mavelous?  I have my Arducopter and TX set up ready to do inflight PID tuning, but I don't have a laptop that's usable in the field for the APM Mission Planner, which seems to be the only current option for configuring the necessary parameters.  I was prepared to develop an iOS app to interface with mavproxy, but adding the relevant function to mavelous would be a much better option.  If anyone's able to provide some starter info about the code architecture, then this is something I'd be happy to add to the project.
  

[John Wiseman]

Hi, David.  I don't know anything about client-side caching, sorry.

Could you open an issue on github for the problem you saw starting the server on a headless device, including the error message and stack trace you got?  I'd like to make that work easily.

And yes, I'd like to support parameter viewing and editing, but I don't have a timeline for that yet.  You might want to create a github issue for that too so it isn't forgotten about.

Thanks,

John

--
You received this message because you are subscribed to the Google Groups "mavelous" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mavelous+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Pat Hickey]

On Tue, Feb 19, 2013 at 3:35 AM, David Court <david.c...@gmail.com> wrote:

• Are there any plans to include support for MAVLink parameter viewing and editing to mavelous?  I have my Arducopter and TX set up ready to do inflight PID tuning, but I don't have a laptop that's usable in the field for the APM Mission Planner, which seems to be the only current option for configuring the necessary parameters.  I was prepared to develop an iOS app to interface with mavproxy, but adding the relevant function to mavelous would be a much better option.  If anyone's able to provide some starter info about the code architecture, then this is something I'd be happy to add to the project.
  

Yes, we'll be looking into this soon - I agree this is a necessary feature.

Pat

[Pat Hickey]

Sorry, I hit send before I finished writing my reply...

I can help walk you through adding a parameter API to our mavproxy server, and some pointers on frontend code. If you'd like we could do this as a skype/google hangout call with screen sharing, or it may take me a bit of time to get some sort of document put together.

[Chris Gough]

What about using a web console to interact directly with MavProxy,
such as ajaxterm. Overkill?

http://antony.lesuisse.org/software/ajaxterm/

Chris Gough

> --
> You received this message because you are subscribed to the Google Groups
> "mavelous" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mavelous+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
.

[David Court]

I think to be fully useful from a phone, something friendlier than a terminal UI is required. Sliders, dropdowns, etc. where possible. Selection of parameters from a list, and so on.

Otherwise, it's straightforward to simply use a standalone terminal app to connect to mavproxy - no need to do it through mavelous, although I agree that integration with the front end would be nice

[David Court]

FYI, I now have what looks like a field-usable Raspi-based setup up and running.

To avoid map tile issues, I've got a fairly hokey network setup, using the Raspi to talk to a mifi-like access point over wifi, and my iPhone talking to the same wifi AP, and finally a 3G modem stuck into the AP to give WAN access.

It seems to work pretty well testing in my study, so I hope to be able to try to field test it tomorrow.  I've raised a couple of issues to cover things that I've noticed so far.