24 replies to this topic

[Reddog]

I saw that Dankers asked for feedback on the GCS so I thought I should pipe up.

As the list of vehicles and options increase the GCS is going to get more and more complicated. I think simplicity is the key, especially if we want to bring on new users and make it easy for them. I believe a layout like a transmitter would be great, as we all get more and more models and setups I believe that the current basic GCS will not cut it. I know the initial reaction to this is going to be HELL NO, but think about the day when the GCS is the transmitter and everything else....

The below is just ideas on how to achieve a GCS transmitter. I do realise some of these changes are simply gadget changes, but new users just want to use things, not learn how to configure the GCS after they have configured everything else.

While the tabs are great there seems to be a mixture of of features for different areas and I believe that things could be done differently.

It is quite hard to describe in text and I have not drawn up a layout, sorry.

If you think about it slightly differently than we have now, the Airframe is the master Product and everything else is tied to it. You have two transmitters setup in the GCS, you can select a transmitter (currently Input) and apply that to the airframe, the board means nothing, its just a piece of hardware, the features you want on that board should be tied to the Vehicle. HW settings should only exist for things that you must select and then require a reboot as they are the only things tied to the hardware. For example Camera stabilisation can be selected but its configured as part of the airframe/camera section.

The GCS Configuration should be broken into 3 different parts - Airframe, Board, Transmitter, or names that are similar.

Aircraft, should be renamed to Vehicle or something similar.

The Data settings should be removed and put into a separate Tab called Advanced settings. The reason for this is they curently take up too much real estate for the benefit they provide.

The sticks part should be moved to another section of the GCS, the configuration wizard does away with that requirement, and you are never going to fly from the configuration screen under GCS control anyway.

Input should be tied to transmitter, most of us will only use one transmitter and the configuration part is going to be the same for every board we use, including flight mode switching etc. Saying this there should be options to change these for different airframes, but we should be able to save a generic transmitter settings and load them when setting up a new airframe without having to import the UAV settings.

[peabody124]

Sketches might help, but I think you need to clarify what you are talking about.  The configuration gagdet is only a small fraction of the GCS but that seems to be your focus.  Also you realize the GCS can be rearranged easily - Tools->Edit Mode or something.  That way you can move it around and take a screenshot of what you mean.

[Reddog]

peabody124, on 28 November 2011 - 02:32 AM, said:

Also you realize the GCS can be rearranged easily - Tools->Edit Mode or something.  That way you can move it around and take a screenshot of what you mean.

The configuration screen cannot be modified like that, it can only be removed. The GCS should not require configuration for basic use, it should be configured so you can install it and fly a UAV without configuration.

peabody124, on 28 November 2011 - 02:32 AM, said:

Sketches might help, but I think you need to clarify what you are talking about.  

I will try to do that ASAP but the meantime this is what I am trying to achieve - (quote from first post) - think about the day when the GCS is the transmitter and everything else....

peabody124, on 28 November 2011 - 02:32 AM, said:

The configuration gagdet is only a small fraction of the GCS but that seems to be your focus.

I am focusing on the configuration screen as this the only screen I have ever used, as its the only one that has a functional use for me at the moment. Its a little hard to fly and look at a laptop .

[Reddog]

I thought I would go through my logic here to see if it looks sound to others.

This logic is set at some future date when everything is done via the GCS.

Sadly you cannot create a GCS that fits every use case, so what I am trying to do is go through the logic to find the most obvious use case.

When you are using the GCS 90% of the time you are going to be either configuring or flying, therefore these are the main screens that matter most. When the day comes that we no longer use a transmitter, then the features that a transmitter has and is required to fly/configure a UAV need to be put in the GCS (see above for my ideas on that). The flight screen should be taken up by the PFD gadget with video and OSD information plus overlayed wth any alarms from the board (GCS can process this like it does now). The Magic waypoint is probably not going to be used a heap in flight, mostly in planning, but you want it available if things need to change, have it on another tab within the flight data area. The alarms and gadgets to either side of the PFD (currently) use a heap of space for their benefit. A good example of this is an autopilot alarm - you are flying 5 KM away from you searching for survivors of some disaster and an alarm comes on, you want to know about it but there is probably not much you can do about the attitude estimation going bad, you care about crashing the UAV into the ground where you are not going to hurt anyone. You quickly grab your mouse and everything looks very small, you decide you need to edit the gadgets to give you a bigger PFD/video overlay and by that time its hit the ground. Using another analogy - the way the GCS is setup at the moment is like having the sticks on your transmitter as small as every other switch on the transmitter.

[peabody124]

So take for example the main screen (first tab after welcome).  That is meant to be the one for flying.  That has the PFD and a map.  So is your main comment about that the size of the alarms?  Lack of overlay data or what?

[dankers]

A picture speaks a thousand words! Even badly drawn ones

[Reddog]

peabody124, on 28 November 2011 - 05:01 AM, said:

So take for example the main screen (first tab after welcome).  That is meant to be the one for flying.  That has the PFD and a map.  So is your main comment about that the size of the alarms?  Lack of overlay data or what?

What I am trying to do is both put my thoughts out there and by talking about my logic, allow others to put up their ideas. I guess I did it this way because I didn't want to put my ideas out there without explaining my logic first.

[Reddog]

dankers, on 28 November 2011 - 05:49 AM, said:

A picture speaks a thousand words! Even badly drawn ones

I am worse at drawing than I was flying a quad when I first started, be warned....

[m_thread]

Hi

Very interesting topic. I would love to see an example of how the GCS design could be changed to the better. I have been struggling with the config plugin for some time now and i really don't know if the current design will be a good base going forward.

/F

[Reddog]

On a similar note, is it worth it to continue to develop to GCS systems, one for android and one for the PC?

[m_thread]

Reddog, on 28 November 2011 - 09:36 AM, said:

On a similar note, is it worth it to continue to develop to GCS systems, one for android and one for the PC?

This is a very relevant question. In a perfect world there should only be one codebase of course. As of now with the platform choices we have at hand this is definitely not the case.

Going forward i can see two major types of users using the GCS:
1. The CC pilot, using GCS to configure and tweak the CC boards settings. Steering using a traditional RC Tx. Maybe tracking telemetry in real time.
2. The Revolution/UAV pilot, using GCS to actually steer their vehicles, handle navigation and get telemetry feedback in real time.

These two types of users definitely requires different types of support from the GCS klient.

/F

[Reddog]

QT has been ported to android so my question might be a non event?

[m_thread]

Yes Qt can run on Android. But the current GUI design would not fit on a mobile device screen even if we where to use a shoehorn

I spent quite a lot of time in QTCreator now and i'm still not really pleased with it. As a developer who 'left cpp behind' many years ago the turnaround time when developing is still very frustrating. Developing in Java or .NET is so much faster and more productive (at least that is what i think).

If i where to choose a framework/language for developing a client application like GCS today, i would have chosen different.

/F

Edited by m_thread, 28 November 2011 - 11:22 AM.

[Kenn Sebesta]

I like what you say, Reddog, but I think that before going too far into how GCS should look, or even work, we need to have a conversation about what we expect a GCS to do. What are the requirements? What audience are we aiming at? Do we have to leave an audience behind by the main branch? If so, can things be designed such that those left behind can still use the framework provided by GCS, e.g. with plugins?

I see a lot of similarities between hobbyist, research, and commercial users, but I bet there are a lot of differences. Could we/should we cater to them all?

[Spydmobile]

Reddog, I like to take a sreenshot of an application, then load it in thegimp/photoshop hack it up move things, resize etc and then post your mockup, it may help others visualize some of your changes.... Just a thought....
Franco

[Edouard]

I was wondering whether the first postulate of your message is actually valid: why should the GCS be the transmitter? On professional ground control stations, you always have actual sticks and controls outside of the computer screen/keyboard, so I'm not totally sure what you are trying to achieve here ? But your message is interesting, and I'll be waiting for drawings - even bad ones - to understand better what you have in mind!

[Reddog]

Edouard, on 28 November 2011 - 03:17 PM, said:

I was wondering whether the first postulate of your message is actually valid: why should the GCS be the transmitter? On professional ground control stations, you always have actual sticks and controls outside of the computer screen/keyboard, so I'm not totally sure what you are trying to achieve here ? But your message is interesting, and I'll be waiting for drawings - even bad ones - to understand better what you have in mind!

I should clarify the transmitter part a little further.

When flying a UAV using the GCS the hardware is already a transmitter, it is communicating with the aircraft and the aircraft is communicating with the GCS. If you look at the way we do things now, we configure via the GCS and then fly via the RC transmitter (we essentially use two transmitters). Why do we need two transmitters? We are never going to be able to fly a UAV over long distances using a transmitter, there are just not enough features available, in saying that current tablets are never going to be able to fly a UAV over long distances either (this is a whole new side discussion) - are you going to hold a tablet for 7 hours? There are just not enough features or flexibility in a tablet, joysticks anyone? What I am trying to say is we should allow both options (an RC transmitter is the easy part) but in the end the GCS will be the logical choice for flying a UAV or a CC Multirotor etc. If there are features of a transmitter as part of the GCS, then this will be possible. On this transmitter features note, I believe the GCS should function a little more like a transmitter. On a transmitter the starting point is always the Vehicle, everything else is linked to the vehicle. What to switch receivers, easy, just plug one in and off you go, try doing that with CC and the GCS as it is now. Yes I do realise that you can backup and restore the UAV file, but its never been that simple for me.

[Reddog]

Kenn Sebesta, on 28 November 2011 - 03:08 PM, said:

I like what you say, Reddog, but I think that before going too far into how GCS should look, or even work, we need to have a conversation about what we expect a GCS to do. What are the requirements? What audience are we aiming at? Do we have to leave an audience behind by the main branch? If so, can things be designed such that those left behind can still use the framework provided by GCS, e.g. with plugins?

I see a lot of similarities between hobbyist, research, and commercial users, but I bet there are a lot of differences. Could we/should we cater to them all?

This is what I was trying to get at in my third post, there are two main screens that every person is going to use, configuration and flight data (albeit with a different layout and some merged features of other tabs), that is pretty much all the GCS should have in it by default. I realise there are other features that people may want but then again, we do not have infinite resources, if we are going to do something we should do it well. If a researcher wants extra features (plugins) they just turn them on and if they don't exist, plugins can be easily developed.

This conversation is going to split into 3 different conversations all very much linked to each other, what hardware do we support, what language do we write the GCS in, how should the GCS look? While it looks like a good idea to develop for every use case and platform, our limited resources need to be used effectively.

[Kenn Sebesta]

Reddog, on 28 November 2011 - 11:04 PM, said:

I should clarify the transmitter part a little further.

When flying a UAV using the GCS the hardware is already a transmitter, it is communicating with the aircraft and the aircraft is communicating with the GCS. If you look at the way we do things now, we configure via the GCS and then fly via the RC transmitter (we essentially use two transmitters). Why do we need two transmitters?

Because the R/C transmitter is "guaranteed", whereas the GCS running on your computer is anything but. In a multitasking environment, you have no determinism, so you never know when something will interrupt. I was flying an AR.Drone and got a phone call. Whoops! Good thing the AR.Drone is able to freeze without danger to people or property. (HINT: we can't say the same thing about OpenPilot and thus phones should NEVER be allowed to fly the vehicle.)

That being said, there's no reason the GCS can't give supervisory trajectory tasks, such as "fly to this point" or "loiter here". So what needs to happen is to decide where OpenPilot needs to go. Is it a system for researchers and UAV "commercial" operators, or is it for hobbyists? I can trust a researcher to provide a computer appropriate for the task and 100% dedicated to it, whereas I cannot extend that trust to hobbyists. On the other hand, it seems to me that most of what OP is used for is hobbyist flight, so it's unfair to leave them out in the cold.

[Reddog]

Kenn Sebesta, on 28 November 2011 - 11:11 PM, said:

On the other hand, it seems to me that most of what OP is used for is hobbyist flight, so it's unfair to leave them out in the cold.

Most hobbyists will use a transmitter and if they want to use their phones as a GCS, fine, but as you said its probably not a good idea to use a phone as a transmitter, hence my comment about the hardware.