Replies to This Discussion

Permalink Reply by Paul Mather on March 29, 2012 at 6:15pm

In what kind of a professional context would you be using a Mickey Mouse airplane? http://www.nitroplanes.com/93a300-1400-skytrainer182-red-rtf-24g.html The MP has lots of fans on this site. You're not going to make any friends with posts like this.

• ▶ Reply

Permalink Reply by Jake Stew on March 29, 2012 at 6:52pm

Mickey Mouse?  I guess it's not like the Cessna design is a proven workhorse of the small plane sector or anything.

I think you've got me all wrong.  I didn't mean "Fischer-Price interface" as an insult.  That's the style it is IMHO.  The term started when XP switched to the default "Luna" theme where they used a larger, brightly colored bar with rounded edges.

Large icons with text labels that take up a good chunk of screen real estate instead of a more modern-looking tabbed interface is a "Fischer-Price" style interface.  MP has great functionality and a lot of hidden and/or detailed options if you look below the surface.  But at first glance it looks like a few large buttons controlling a google maps API window.

Take a look at QGroundControl, then look at MP...  Which looks more complicated/advanced/professional?  I think the answer is more a statement of fact than a slam on MP.  If it was a slam then I could see you getting wound up, but it wasn't intended to be.  Just a simple statement of the most precise software engineering term I'm familiar with.

How exactly would you describe the overall impression of the two interfaces?

• ▶ Reply

Permalink Reply by Paul Mather on March 29, 2012 at 7:02pm

I'm afraid Fisher-Price is a slam no matter how you try to spin it. I'm very familiar with both interfaces. They both have their pros and cons.

 

The benefit of MP is it can be used offline AKA no iternet. Google Earth requires an internet connection. Guess how I know.

 

http://code.google.com/p/happykillmore-gcs/

• ▶ Reply

Permalink Reply by Jake Stew on March 29, 2012 at 7:14pm

Well, I didn't coin the term.  It seemed to fit, so I used it.

Maybe you can explain something to me.  Why are there so many GCSes out there?  If the programming time that was spent on all these different interfaces was instead invested in one or two we'd have some really advanced control software instead of a long list of pros and cons.

I'm sure there's a reason.  Obviously you wouldn't have expended all that time for no reason.

• ▶ Reply

Permalink Reply by Paul Mather on March 29, 2012 at 7:39pm

Ah, a history lesson. Well you see, it all started way, way back in 2008ish with the ArduPilot LabView ground station. http://code.google.com/p/ardupilot/wiki/GroundStation It was the bee's knees for the day. For the upstart ArduPilot it was the perfect match. It had several developers and a great following as it was really the only GCS available for ArduPilot Legacy at the time. It had some serious limitations in my view. It required a multi-thousand dollar development envirnment and a 100 MB runtime download plus the clunky NI VISA COM port download just to get the thing to run. Then it didn't seem to like the 50Mhz signal the ArduPilot was pumping out and seemed to generate a serious lag even with a semi decent processor (which most of the laptops people were using didn't contain).

 

So along came QGroundControl, written by the fellows from PixHawk. At the time, ArduPilot was still using it's own binary and/or ASCII protocol but after some work by Doug and James, the MAVlink interface was born. That opened up the possibilities for lots of new functionality. I had tried to use the QGC and frankly didn't like it at all. It was written by engineers for engineers. Michael Oborne and I both started writing our GCS's at about the same time. My goal was to make a GCS that would work with multiple autopilots ranging from just a GPS, GPS + IMU all the way up to ArduPilot/AttoPilot/GluonPilot and UAVdevboard. Michael O focused on ArduPilot.

 

So it was 3 different people/groups working independantly on 3 different projects. My time has been tied up with work and familiy so my project has been seriously lacking...but there's really no reason to try and combine GCS projects.

• ▶ Reply

Permalink Reply by Jake Stew on March 29, 2012 at 8:15pm

Thanks for the history lesson.  I had heard that ArduPilot started with LabView, which I was never all that impressed with.

I just wish there was more interoperability.  Sometimes it seems like people are going out of their way to do everything differently.  I'm glad at least MAVlink is shared among a few autopilots.

• ▶ Reply

Permalink Reply by Paul Mather on March 29, 2012 at 8:56pm

There's really no incentive to work with anyone else. I would say James was probably the biggest driving force in making MAVlink a success as he was working on both QGC and the MAVlink libraries for ArduPilot. Without that effort, APM would still have it's own protocol. But MAVlink is far from an industry standard. There are only 3 autopilots that run on MAVlink. The Pixhawk autopilot, APM and UDB (but I'm not sure if their implementation is done...I've been out of the loop for a while).

 

Think of all the other autopilots out there that have their own protocols.

 

Let's see, off the top of my head:

FyeiuTech

OpenPilot

GluonPilot

Pteryx

AttoPilot

Robota

MikroKopter

UDB's MatrixPilot

Paparazzi

...about 50 other autopilots out there...

• ▶ Reply

Permalink Reply by Jake Stew on March 29, 2012 at 11:37pm

The way I see it MAVlink works with 3 times as many autopilots than anything else out there.

I'm working on some paparazzi stuff at the moment, but have an APM2 hopefully on the way.  Paparazzi seems to be quickly falling behind some of the other autopilots. No mavlink, overly complicated code base and setup, only runs on linux, GCS only just passable, no NMEA support, all the gear is expensive, etc..

They've got a lot going for them, but don't seem to care about a coherent strategy for development.

• ▶ Reply

Permalink Reply by Andrew Radford on March 30, 2012 at 3:01am

One point of view is that there are many GCS out there like there are many web browsers. HTTP is the standard communications protocol, but for whatever reasons, people have their preferences so develop seperate apps that do 90% the same thing, but are different in 10%. They are all web browsers, but I am glad that we have Chrome, IE, Opera, Firefox etc to chose from, rather than having one 'super' browser that everyone 'invested' in.

As for the planner - it's difference is that it is focused on the APM, so has some perculiar features regarding setup and calibration etc which only applies to APM, and not other MAVLINK based UAVS. However, if you like QGC and are handy with python/QT, in theory there is nothing to stop you implementing these as addons - It is open source after all.

And lastly I suppose the Fisher-Price look and feel sometimes can have a positive spin, perhaps when we move to Windows 8 & 'Metro' on a Microsoft tablet, it will be easier to use when there is no mouse. Nice big buttons to mash with your fingers!

• ▶ Reply

Permalink Reply by Jake Stew on March 30, 2012 at 5:46pm

That's probably the exact same example I'd use to argue the other way.  The browser scene is a complete shit pile of a mess.  They all have their own bugs and ways of displaying pages, which is just plain wrong.  It's a really crappy situation for web page designers and users alike.

It would be so much better if we had ONE browser which supported configuration/skins/plugins to make it LOOK and feel like any of the current browsers but ran on the same engine or had actual interoperability at some level.

Or if there really were different design philosophies worth supporting then you should be able to choose your engine AND your skin independently.  That would be MAVlink in our case I guess.

• ▶ Reply

Permalink Reply by Paul Mather on March 30, 2012 at 9:12pm

It's time for the world government and Jake to select the car we should all drive...

• ▶ Reply

Permalink Reply by Jake Stew on March 30, 2012 at 11:28pm

LOL, think of the savings in parts and mechanic training!

• ▶ Reply

• ‹ Previous
• 1
• 2
• Next ›
• Page