Tablet control testing

[peabody124]

Cross posting from my blog: http://buildandcrash.blogspot.com

So I finally got some flight tests done with Tau Labs' tablet control feature, although it was a bit on the windy side. In this mode the flight mode switch is flipped to "TabletControl" and which point control is ceded to the tablet. This means you can use labeled buttons to control from a large number of flight modes instead of confusing switch positions, as well as seeing the performance from the tablet.

https://vimeo.com/63529694

This mode allows Position Hold, Return to Home, Return to Tablet, Follow Me, Fly Path, Camera POI mode and Land. Most of these are demonstrated in the 

video. This follows up on some previous work here

AndroidGCS Transmitter - Navigation Control Demo from James Cotton on Vimeo.

but I found the OPLink wasn't reliable to use as the only link and had some fly-aways. This system keeps the regular transmitter in ultimate control in case anything goes wrong. Safety testing is demonstrated as well to show that the motors shut off when the transmitter is turned off. The new architecture makes it easy to define other failsafe behaviors like RTH on transmitter loss, but not until navigation is extremely robust and well tested. The results of enabling Fly Path mode were a little disappointing. It would hit the first few waypoints but the requested velocity and path follower settings weren't aggressive enough to fly upwind. More testing soon hopefully! 

[metRo_]

really great:)
Is that code ported to F3?

PS: can you share your setup in the other topic I created about quadcopter setup?

[peabody124]

Yep, it should work equally well on FlyingF3 and Quanton provided you have a modem.  I got the 3DR modem working with android a few weeks ago.  This was tested with Freedom since the logging facilites are useful for analysis.

[Olivier Damiron]

Awesome. Is this with the latest Taulabs code from jenkins.taulabs.org or are you using some test code of your own?

Position hold looks sharp, RTL looks sharp and it can do NAV already?

Got a little delayed in finishing my Quanton based test quad but hoping to get out next weekend to put her through her paces.

Now if the wind could die down a bit, it would be nice, haven`t had one day with winds below 15 Kph in 2 weeks.

[peabody124]

This is some additional code beyond that.  I've actually been working heavily on navigation for the last 6 weeks and it's getting pretty close to creating a PR, although we need to get Qt5 merged first since I've long since merged that into all my branches.  There are definitely still some quirks left to work out - some of them critical before I'd want anyone else playing with this and having issues (e.g. zeroing out the home altitude for each flight).

Yep, position hold, RTH, and full navigation are all working (although this video did not show off navigation well).  Right now it's also RTH instead of RTL which is the same thing if you don't save the home location and let it grab a new one each power on.

I hear you on the wind.  I've ended up doing a lot of this testing at 15 mph, and this quad isn't running flashed ESCs so really suffers from it.

[Olivier Damiron]

Looks good so far. Quick question for you: How does the TauLabs code handle FAILSAFE?

I usually set my receiver failsafe to neutral sticks, hovering throttle and position hold on the mode switch ( and eventually RTH when it will be 100% ready and it sounds like it is coming along nice)

I am asking because I am a former APM2.5 user and that board just had a knack for completely ignoring failsafe and doing whatever it wanted to do.

I have had situations where after a purposely initiated failsafe (turn off the TX), then turn the TX back on to test recovery scenarios, the APM would ignore the TX when it was turned back on and I couldn`t change anything or control anything. As if once you go failsafe, there is no going back sort of thing. I know the Arducopter code was particularly wonky (still is in fact....) but I am just wondering how TauLabs approaches this.

Different controllers have different philosophies about failsafe, just wondering how the Taulabs code handles that aspect of things.

In other words, does failsafe have full authority and whatever else is going on is ignored until proper PWM or PPM signals are restored? APM sure did not have that feature, it seems it did whatever it felt like at the time, never the same reaction which was freaky. 

Cheers,

[peabody124]

Yeah that is one of the things I spent some time on.  Previously the handling of fail safe was kind of ad hoc and buried in the code.  Now it's is very clearly separated out and handled - which makes it a lot clearer to write more complex failsafe code (e.g. maybe PH for X seconds, then RTH, then land, etc) while making sure it is still safe.

Right now when the transmitter signal is gone (including when using tablet control) then control is passed to the failsafe sub module.  When transmitter signal is reestablished it goes back to the transmitter.  If you lose signal for 30 seconds then by default it will disarm so you would have to rearm after reestablishing contact.  I've tested restoring control numerous times and never had an issue.

In fact if you look in the video when I'm testing how it responds to removing the transmitter, you'll notice when I reestablish control you hear it say "disarmed" since i had the sticks in the disarm position.

[Olivier Damiron]

Excellent. Thanks for clarifying that.

[metRo_]

Android app should work with any modem that use FTDI, isn't it?

[peabody124]

Probably but having not tested them I wouldn't want to promise.

[metRo_]

There are any development in the android application to use telemetry over a udp connection? (http://forums.openpilot.org/topic/7700-telemetry-using-wifi/)

[peabody124]

I've used a serial wifi adapter with the android app in the past.  I can't find it right now to tell which one in particular.

[metRo_]

But i'll use a seria-wifi in the F3 and in  the tablet set it to use udp.

[peabody124]

The tablet uses TCP, not UDP