69 replies to this topic

[Halves]

One example of the simplicity required to an Lite version is the GUI of the
iRemoco project.

( But the UI is seriously outdated to my taste)

[jes1111]

@Halves: just a small point - your division between fun and pro users skips over the "pro" aerial photographer who wants a simple, safe way to control the aircraft.

Which leads me to my main point...

The more I think about this, the more concerned I'm growing about this idea of using a phone for full control of the aircraft. It may be okay to do that with a toy in your living room, but I shudder to think of the danger of having a 12 pound UAV with lethal propellers being controlled by a phone. What happens when a call comes in? What happens when you drop it? What happens when the battery dies? What happens when the touch-screen decides not to register your last touch? What happens when you accidentally press the home button and close the app?

I do think we need to be careful what we offer: what may be technically possible (and even "fun" for some) may itself be irresponsible. As much as I dislike RC radios and want to see alternative methods of controlling an OP craft, I'm really not sure that a phone is the right alternative. It's just too "casual" and prone to "loss of control".

[Halves]

jes1111, on 06 June 2011 - 12:06 PM, said:

Which leads me to my main point...

The more I think about this, the more concerned I'm growing about this idea of using a phone for full control of the aircraft. It may be okay to do that with a toy in your living room, but I shudder to think of the danger of having a 12 pound UAV with lethal propellers being controlled by a phone. What happens when a call comes in? What happens when you drop it? What happens when the battery dies? What happens when the touch-screen decides not to register your last touch? What happens when you accidentally press the home button and close the app?

I do think we need to be careful what we offer: what may be technically possible (and even "fun" for some) may itself be irresponsible. As much as I dislike RC radios and want to see alternative methods of controlling an OP craft, I'm really not sure that a phone is the right alternative. It's just too "casual" and prone to "loss of control".

@Jes1111

It's a valid point the dangers of a cell phone as the control method. But even with an RC radio, there is a risk of failure.
People need to understand the risks and we as developers need to provide safe behaviors in case of failure.
But no matter what we do, we won't  cover avery possible danger.


As the OP project has full control of both ends of the UAV equation, I think it's possible to have safe guards built into the board's firmware to accomodate safety of operation.
For instance, in a CC board firmware being flow "by phone", we could but the drone in a stop and hold position if anything happens to the communication link to the GCS.
Dropped phones, battery dying and application shutdown could be handled in such away.


The "Pro" version, in my mind would be tablet oriented, for mode screen real state , but easy of use is still a must.

[Kenn Sebesta]

Halves, on 06 June 2011 - 12:25 PM, said:

It's a valid point the dangers of a cell phone as the control method. But even with an RC radio, there is a risk of failure.
People need to understand the risks and we as developers need to provide safe behaviors in case of failure.
But no matter what we do, we won't  cover avery possible danger.


As the OP project has full control of both ends of the UAV equation, I think it's possible to have safe guards built into the board's firmware to accomodate safety of operation.
For instance, in a CC board firmware being flow "by phone", we could but the drone in a stop and hold position if anything happens to the communication link to the GCS.
Dropped phones, battery dying and application shutdown could be handled in such away.

I've been flying an AR.Drone when my phone rang. This is not a hypothetical problem in the slightest. It is a real problem, and one for which there is no solution, IMHO. Neither the CC nor the OP is capable of staying in place in a hold. In a perfect outdoors environment, several meters off the ground, with no multi-path GPS reflections, on a calm day, the OP might be able to do a reasonable job of staying put. However, those are ideal conditions which rarely, if ever happen and we should not count on them for outdoor safety purposes. As of this moment, there is no sensor package available to the OP/CC that will allow it to position hold indoors. Moreover, a hold only makes sense with a hovering vehicle. An airplane is not capable of this sort of holonomic control.

The AR.Drone solves this problem because it is light, has weak motors, and flexible props. It's by design a system guaranteed not to do much more damage than knock over your vase. OP already has machines with excess of 1HP of available power, and will certainly grow.

In short, the only safe option is not to enable flight from the telephone. Not to even go down that route. Better to spend development time on other things, such as having a great mobile GCS that monitors, saves, and communicates (but does not control), then to start having to defend the OP project in case of catastrophe.

[muralha]

First, I believe the naming should be more like: mobile version and tablet version.
Lite and Pro naming is dangerous... normally, people wants to use the Pro version (everyone wants to be a Pro).

My initial view of this apps is that, they should be more or less a viewer apart from the PID tuning.
When we integrate the navigation system, the navigation should only be available if there's a TX/RX connection (as a safety link).
Also, auto take-off and landing is a thing we need to consider when we start testing the sensors and code.
I think a GCS "viewer" is what we're building now... (apart from the PID tuning settings)

[CheBuzz]

Kenn Sebesta, on 06 June 2011 - 12:42 PM, said:

I've been flying an AR.Drone when my phone rang. This is not a hypothetical problem in the slightest. It is a real problem, and one for which there is no solution, IMHO.

Sure there is a solution.  It's called Airplane Mode.  Pretty much guaranteed to not receive a call.

[ligi]

so the "Airplane mode" gets a totally new meaning *SCNR*

[Kenn Sebesta]

CheBuzz, on 07 June 2011 - 02:44 AM, said:

Sure there is a solution.  It's called Airplane Mode.  Pretty much guaranteed to not receive a call.

Assuming the user does it, and that's a big assume, that works for calls, it doesn't work for a telephone's general unsuitability for such a flying machine. TXs are tested thoroughly and are single-purpose, telephones are multi-tasking, untested, and can crash. From a safety perspective, I just feel that we're asking for trouble if we develop the means to directly control the aircraft from a telephone.

[CheBuzz]

Sure.  I'm not suggesting that phones should totally replace TX.  There are use cases for each and that's what should be discussed I think.  I am mostly interested in using a tablet to replace my laptop as a GCS.  Control via a phone could also be seen as a nice failsafe in the case the TX battery should die, or some other mishap should happen.  For fixed-wings, it's quite common to fly "fully autonomous flights" which could be serviced by this approach.  I'm sure there are other use cases that I haven't thought of.

[Reddog]

Will something like this allow you to install the full GCS? It has USB for Xbee or PipExtreme and Bluetooth.

http://hothardware.c...spx?PageIndex=3

Edited by Reddog, 15 June 2011 - 08:43 AM.

[Halves]

Reddog, on 15 June 2011 - 08:38 AM, said:

Will something like this allow you to install the full GCS? It has USB for Xbee or PipExtreme and Bluetooth.

http://hothardware.c...spx?PageIndex=3

@Reddog -
I was gunning to use a tablet like this to run a GCS with most of the features of the "desktop" GCS.
With a small purpose build interface box( with USB<->PipExtreme or/and USB<->Xbee) would be ideal.

@All
I've been listening to all the ideas and as soon as possible I'll be posting some mockups I've been working on.
.

[3rdeyepro]

Please let me know if I can help designing the UI graphics. I also have an EVO phone to test software on.

[Liftor]

Hi ligi,

I gave the DUBwise UAVTalk a try on my Samsung Galaxy S with Android 2.2.1 together with a RN-42 bluetooth module on the CopterControl. For this early stage of developement it's very impressive already!

Now my observations:
- bluetooth connection was established, but it takes some time and the handshake window does not close automatically afterwards
- text size is (extremely) huge in the main section of UAVObjects and in Alarms. See screenshots attached. Otherwise it's fine.
- expected some crashes and hangups with vibrating alert. Can i save logs for you somehow?
- If I click on the value of an uavobject which is not the first in the list of the values, I still get the first value in the list as a default in the appearing number entry field.
- UAVObject Changes were not saved, perhaps because it's not implemented yet?
- A separate stabilization tuning tool similar to the one in GCS would be very cool for optimizing the settings on the flying field.

I am looking forward to the next update. Tell me if I can help with testing.

Attached Files

•  SC20110618-102200.png   37.87K   27 downloads
•  SC20110618-102225.png   57.57K   23 downloads

[muralha]

Basic PFD with top phone bar and bottom menu
 MobileGCS-03.png   28.54K   56 downloads

On top, there's the compass/heading display (345   N   15)
The left box shows the speed (airspeed or gps or ...).
The right box shows the altitude/height (gps or baro or sonar or ...)
The bottom box shows the Armed/disarmed status. When the craft is armed, it doesn't show "Armed" (not to scare some people thinking it's military stuff), it shows the Flight mode (stabilized 1, ..., position hold, velocity control). In the future, it can show the autopilot's commands like: "Loiter WP7", ...

I didn't put labels above the left and right boxes (like: ALT and SPD) because it takes some space and it would clutter the view with some visual/text noise that's not very important (it's easier to add a help information screenshot).
I've put the menu on the bottom because: otherwise the user would have 2 menus/bars on the top (this is not very UI friendly); every time a user would change the menu, he would be blocking his view of the display with his hand/finger and because we (normally) read from top to bottom and the menu is secondary information, it should be way down.


PFD with guidance lines and triangles
 MobileGCS-02.png   18.01K   75 downloads

The horizontal line shows the desired altitude/height.
The vertical line shows the desired heading.
Each triangle shows the desired box value (in this example: more height and less speed). When the values are the desired ones, it can show both triangles or don't show any of them.

The 3 top boxes (Link connection, Timer and battery voltage status) should be configurable, should let the user switch order and should allow the user to choose other options like: GPS status/number of satellites, ....
If the timer is a down to zero timer, it should show "-09:57" and when it reaches "00:00", it should show "+00:01" so the user knows he has passed his limit time.
The boxes color depends on the configuration/input values. In this example, if the battery is a 4S Lipo with that value the battery is in a dangerous voltage (for 4S Lipo I would do: >16v = green; >15-16v = orange; 14-15v= red). In a timer situation I would do: <75% of time = green; 75-90% = orange; >90% = red.

Both guidance lines are the most top layer, so they show above all the other lines.

PFD with guidance dot and arrows
 MobileGCS-04.png   17.74K   62 downloads

Same as the above only difference is the simpler guidance signs.

The altitude/height guidance "dot" appears above all lines but below the horizon dot, this way it shows both dots are zeroed in, more easily.

[jes1111]

Looking good... although I wouldn't agree with your "don't label it" idea. This stuff is not intuitive to "never flown RC or real aircraft" people like me. Smaller font, 70% alpha, whatever - but I wouldn't want to look somewhere else for confirmation of what's what (particularly when the pressure is on). I'd be careful, too, of using colours like red - the internationally understood meaning of red is "stop" (as green is "go") - any other usage would be non-intuitive.

[ligi]

It was a bit quite here as I was traveling - will try to keep up with the discussion now - first one video-demo of DUBwise for UAVTalk in interaction with OpenPilot CopterControl on my testing Quad - showing the PFD and SystemAlarms



@muralha: thanks for the mock-ups - I will try to keep some of that in mind when implementing, but I will not move the ActionBar down because that would break a very wide spread Android UI Pattern and will confuse a lot of users

@Liftor: thanks for the list - that is most helpful - I will start with the last point on your list as I have to tune my CC-Quad now and the rest will also follow - please PM me for the vibrating alert as I cannot reproduce that

@pro_vs_light_discussion: I do not want to split versions as I know the pain that causes on both ends - I will rather try to make it able to grow with user-/UAV- needs by configuration and unlocking functions

@3rdeyepro: GFX would be really useful - e.g. 2 Icons to show the armed state in the PFD

Edited by ligi, 21 August 2011 - 10:31 AM.

[ligi]

Small update - first the PI-Tuning Interface:


switching between inner and outer loop is done via left/right swiping - not yet sure about that UI concept - it is hard to get the 3 axis ( axis,parameter,loop-level) on a small space to the user UI-wise - Ideas welcome but is working in principle ( updating every 400ms - and save button behind menu key )

second is the main menu - was a thorn in my eye from the beginning - I used the popular new DashBoard UI Pattern here - the Images need improvement though but they are easily replaced:


Also you can apply/save UAVObjects now ( press the menu key )

You have to uninstall the old version and get the new version from the market - I had to upload a new version to the market as I lost some keys with HDD crashes - in this early stage i hope this is no problem - I will backup these keys to "the cloud" to be sure;-)

As I cannot upload apks to the forum ( Error You aren't permitted to upload this kind of file ) - here the apk for people without market http://dubwise.frees..._uavtalk_11.apk

[Snagglesworth]

Does anyone know if it would be possible to use an APC220 with a Samsung Galaxy S2. The S2 supports USB OTG (On The GO) so I presume the ony thing missing would be a driver for it?
If it could be made to work then we could have a 1km link to our android phones    and mean those of us on 2.4 radios can use something other than bluetooth.  

[Brian]

Snagglesworth, on 26 August 2011 - 05:31 PM, said:

Does anyone know if it would be possible to use an APC220 with a Samsung Galaxy S2. The S2 supports USB OTG (On The GO) so I presume the ony thing missing would be a driver for it?
If it could be made to work then we could have a 1km link to our android phones    and mean those of us on 2.4 radios can use something other than bluetooth.  

I don't know about the APC220, but it should be pretty straightforward to connect a Bluetooth to serial converter to an Xbee (on the ground), with an Xbee in the air to give you long-range wireless telemetry.

[Snagglesworth]

Brian, on 26 August 2011 - 06:26 PM, said:

I don't know about the APC220, but it should be pretty straightforward to connect a Bluetooth to serial converter to an Xbee (on the ground), with an Xbee in the air to give you long-range wireless telemetry.

but that still doesn't help those of us on 2.4 controls. We cant use bluetooth.