John Wiseman and I have been working on the browser-based frontend for Mavproxy which he announced a few weeks ago. Here's a new demo video I made controlling an ArduCopter:
Heres a screenshot of the new and improved user interface with PFD:
We're actively developing on Github. You can start using Mavelous today!
Comments
Jan, I agree, to do anything else would be a kludge. That's why we already do that.
Except we use modestmaps for maps and KineticJS for graphics. Use the source, Luke: https://github.com/wiseman/mavelous
F11Music (and anyone else), could you post questions about how to use it to the mailing list at https://groups.google.com/group/mavelous ? It's somewhat easier to follow conversations there.
That said, if you're trying to run mavelous with a simulated vehicle, then see the "Software in the loop simulation with ardupilot-mega" section in the README.
If you're trying to connect to a real arducopter, then you need to plug your Xbee or whatever radio you're using into your Mac, and you need to tell mavproxy which device file corresponds to the radio. I don't recall offhand what the radio device is typically named on a Mac, but in Linux it will be something like
/dev/ttyUSB0.As an example, here's how I start mavproxy in my linux machine:
python mavproxy.py --master=/dev/ttyUSB0 --baud=57600 --quadcopter --streamrate=5OK this is my first time with GIT so bear with me. I just installed GIT, clicked on 'download this repository as a zip file', then unzipped that and ran mavproxy.py which opened up terminal and went into what I guess is mavproxy. The prompt in terminal looks like this.
Steves-MacBook-Pro-17:wiseman-mavelous-e94a6d7 steve$
When I try to do anything from there, I get errors. I read the instructions that talk about setting the baud rate and starting the browser session but I'm stuck at how to do that because the prompts in the instructions look different than mine or am I suppose to set the serial port first?
Yes, as I said, it should be possible. The server code is python so as long as you can run that on your phone/tablet/whatever you're good.
I'm actually following his post. My target actually is to create a single Arduino server that can receive multiple inputs and transmit outputs to different gadgets through serial connection, here is my post to clarify my idea.
What I'm asking, is if Marvelous/MAVproxy server be an Android tablet instead of a computer since python can be ported to android. The GCS is exactly the same, front-end browser, but the server is running in Android.
I forgot to be specific in my first post. :)
Still, the GCS you've made is awesome, multiple input multiple output. Will be using it as soon as the APM2 and RFD900 arrives. :)
Delfin, that should be possible. FYI Zachary Eldridge is already developing a serial connector and nativ... (I am concerned about the difficulty of getting Apple MFI approval, though I would love being shown that's my pessimism is unfounded).
Cool. Probably more lightweight than Mission Planner GCS. If it is possible to connect an Android tablet to a serial connection of an Xbee/3DR/RFD900 radio, Is it possible that the server is the Android tablet?
I'm not sure why I had to double-tap on the screen twice to get that first waypoint to work, but occasionally the double-tap detection does fail- its not perfect yet, and I hope we can improve it. I'm still learning JavaScript as I go along, so I've probably made some mistakes.
We can probably experiment with bumping the HUD datarate to the full 10hz it is sent over Mavlink at. Right now the individual HTTP requests take about 4 to 6ms roundtrip, so we might not be able to sustain more than 10hz without changing the incoming mavlink stream to work over websockets.
The update rate is currently 4 Hz, and I haven't experimented yet with other values. This doesn't seem like something that needs to run particularly fast, though I think it could probably approach 30-60 Hz with some tweaking (maybe not on an iPhone).
The protocol is HTTP, so some people probably consider it lightweight and others consider it heavyweight, but I'm sure it can handle an update rate of more than 4 Hz. If higher update rates are desired it would be easy to use the WebSocket protocol with its much lower overhead.
As far as touch input performance goes, I expect it does suffer from being an HTML app vs. a native app, in the same way that Facebook's current HTML-based app sometimes feels pokey. This may be an unavoidable price to pay in the portable HTML vs. less portable native app tradeoff.
It's definitely the kind of thing that's good at getting a job. It just seems a bit slow & the screen took a few tries before it took the input. Is that the browser update rate or the protocol?
-
1
-
2
-
3
-
4
of 4 Next