Android Update

I pushed a pretty major update of the Android application to the Google Play Store today that I'm quite pleased with.  Felix Da Cat suggested using a Navigation Drawer to get around the app (he actually suggested it on the OP forums, which puzzles me since they don't have an android app). A year back I tried getting rid of the home page by using a spinner bar at the top and really wasn't happy with the results, but this worked much better.

So you swipe from the left hand side or touch the title bar and you can directly jump to the other pages. The back button should work fairly intuitively to the previous view. This also led to me converting more pages into fragments and really working on how they store state. The most useful of these changes was in the map, so that when you rotate the tablet or phone it will preserve your current zoom level and location. Also the zoom level is cached between runs so no more starting at an awkward way zoomed out distance.

Tablet mode got some aesthetic love. The armed/flight mode notifications were added to the PFD which cleared up some space. Also it didn't seem necessary to show the alarms (cropped) at the bottom of the page when you can just touch the alarm summary button. Getting rid of that junk made it easier to handle rotations in tablet mode too - which behaves reasonably for phones (at least on my N5) and tablets.

The browser was touched up. Editing and viewing both take place in the side view (which behaves well with rotation also) and the back stack will take you back to the previous UAVO you were viewing (but skips editing). This system seems to work well, although it is a bit tight in portrait mode on a phone.

Finally the most useful change (at least to me) is the map now shows a history of where the UAV was. This shows up as a small white trail. Currently rotating or changing screens will flush this which is unfortunate. Later I need to make this aspect of the logging happen at the level of the telemetry service so it can persist between views. But that is for another update. Unfortunately I don't have a screenshot from when I was outside so feel free to send me one :).

Easy logging with OpenLog

So one of my friends has wanted something light and easy that he can use to log data, and also Aqualuna on IRC has been wanting something similar. After seeing some of the logs that Ardupilot produces that my friend was getting with his Revo port I was really encouraged to just come up with something quick and easy that would just work.

And this was definitely easy. I think it took about 15 minutes from when I told Aqualuna I definitely wouldn't start working on this to having a working log file. I used an OpenLog and then connected it up to the flexiport on Sparky. Then I configured it to run at 57600 baud and first showed that it would work and collect data using the mavlink output. 

However, this has a limitation that there is no timestamping data (or handy parsing code) so I decided to adopt the uavorelay module to this purpose. Luckily from the Overosync module I'd added a native timestamped packet to uavtalk so I just modified it to send that type of message and periodically send AttitudeActual, Accels and PositionActual. Then I grabbed the file off the SDCard and ran it through the matlab LogConvert.m (from "make matlab"). Easy peasy, plot of the attitude of the board on my desk:

One of the nice things about this design is it is super flexible. For example, you could just have this attached to the line going to your telemetry system and have it redundantly log all the telemetry data in case you drop out (or don't always have it running) or you could even write a custom data format that is highly efficient to collect as much data as possible at a fixed rate. You can find the branch I'm using here. Hopefully at some point I'll tie it into our logging metadata so you can easily select which objects update at what rate. For the time being I'm just hardcoding it to a fixed rate for preselected objects.

For now I'll probably just make another module (don't want to break UAVORelay) that just allows streaming a few of the major data objects at a fixed rate.

If anyone wants to play with this, the code I used it located here.

Return to home and landing

So at the last Houston meetup at that Haymerchant I was talking with Oso Grande and he described the Naza failsafe sequence. Essentially hover in PH mode for a few seconds, then fly home, hover over home and finally land. It seemed like a good idea, but our current Vtol Path Follower didn't support any multi-step sequences like that. A day or two of thinking about it and a pretty clean implementation crystalized in my head.

Essentially for any "goal" the path follower might have, which range from simple ones like "hover here indefinitely" to the one described above, there would be an FSM that is switched in, which allows arbitrary levels of complexity. The basic description can be seen on GitHub.

I went ahead and implemented it this week and surprisingly it worked in simulation right away, so I got ambitious and went ahead and tested it at our Houston meetup this weekend. The results were pretty good. Also it was flown on Freedom, which has the benefit of providing high quality logs for offline analysis. I had one flight where it wasn't performing terribly well because I forgot to calibrate the mags (no fly away but some serious toiletbowling). However you can decide for yourself on the other flights:

And here is an image of the position data as it returned:

The location control was pretty good and the path home nice and straight. The altitude control wasn't great. It was meant to hold a minimum altitude of 15 m above home, which it tried but gradually dropped. However the altitude drop came from two issues:
1. the accels were biased so the estimate of vertical velocity was a bit off so when it was still it though it was already going up 0.5 m/s
2. the max vertical velocity was set at 1 m/s so it spend most of the time with this request pegged and not making much progress

First the good points. You can see there is less than 1-2 meters of error in the PH segments. However, you can also see how the altitude slowly droops down in the upper right panel, and the velocity is basically thinking it is going up (down at -1) 1 m/s squared so it thinks everything is peachy. After recalibrating the z-accel, this is the result:

Luckily we added a button the other week to facilitate this.

I also had the opportunity to see Naza PH and RTH, and I have to say I was impressed. It holds well and is nice and stable. It definitely has me questioning whether our dual loop controller for PH is the right design, as opposed to a directly PID control on position. We used to have an implementation of the later, so I'll probably try and resuscitate it and play this week. Also our altitude controller in general needs some love.

So a suggested change is that, like Naza, it also ascends in place when it is going to, before returning home. Also making the time it hovers in place programmable before RTH is important. Then add a simple geo fence and we should be able to get some users testing this. If we can make it robust it might actually be an option for failsafe in not too long!

TauLabs gets MultiWii Horizon mode

Some people were asking about Tau Labs getting support for a mode like MutiWii horizon. Credit goes to them for describing it and testing, as well as the MultiWii guys for the idea. In this mode as you move the stick it smoothly transitions from an attitude mode controller (in the middle region) to a rate controller (in the outer region). This means you can have the benefits of a pretty tightly locked self leveling mode with an aggressive rate mode.

Anyway, I whipped it up this morning and managed to get some tests in this evening. It's not identical to MultiWii but it's pretty similar. It felt really fun to fly and was neat having the best of both worlds. It was also fairly natural to fly.



This tricopter wasn't really tuned up so the rates are a bit slow and my loops had to be quite high. The leveling performance was good as always and it felt good in attitude mode regions of the stick range. The rate mode also felt good aside from not being fast enough.

I also tested it on a plane and had no issues there. Nice stabilization in the center and was able to do rolls and flips fine (although again it did not have a fast enough rate so they were fairly slow rolls). Hopefully you guys enjoy the few bloopers at the end. It's been a while since I did any flips.

(Updated) Here it is on Aggressor with Sparky doing some pretty nice tight flips

Horizon Mode - Flipping from James Cotton on Vimeo.

As an aside - we recently added an exponential to Tau Labs rate mode. This allows you to set a really high maximum rate (e.g. 500 or 600 deg/s if you set your gyro max rate high enough) while keeping good control in the middle region. Using this also works in horizon mode, so you can keep all your settings that you tuned independently in attitude and rate mode and it will just switch between them.

If you want to test it here is a version for OSX and here is a version for windows.  BTW there was a problem with the GCS on OSX 10.9 but that is fixed now. (Warning, the firmware in this doesn't flip properly and will do a split-S maneuver automatically. Use this updated firmware)

• Sparky
• CopterControl
• Quanton

If you want to test it here is a version for OSX and here is a version for windows.