Path smoothing demonstration

I commented in my previous post that there was some oscillations in the flight when it would be asked to do impossible things (e.g. sharp turns with constant velocity). Kenn wrote a really nice (and necessary) feature for the fixed wing code that would fillet the turns and generate nice smooth curves when you request impossible flight plans. I ported this to the general waypoint editor so you can apply algorithms to a flight plan, such as smoothing it.

The nice thing about this, is you can take a flight plan with sharp edges and generate a nicely smoothed plan:

I also updated the VTOL follower to properly handle landing waypoints and finally had a chance to test it out. The result was quite nice

This shows three flights plotted on top of each other. There are one or two spots where it diverged a bit (it was a bit breezy today) but generally it behaved quite well. It also removed any obvious ringing like the flights last week. Unfortunately, I haven't written the matlab code to visualize curved flight plans, so I can overlay the intended plan. However you can see it in the previous figure and it's pretty much spot on.

The landing waypoint type also worked well, which is nice. However, it is an important warning that with multirotors you can have the landing location a good distance from the previous waypoint. In this case it just starts decending and going sideways rapidly. I might update it to have a similar sequencing to the RTH sequence: fly to landing location at a fixed altitude and then descend.

So here is the video. The first half just shows making the path and is kind of boring. Sorry about the excessive reflexion from my screen. The second half shows the flight and also overlays the telemetry data for comparison.

Navigation testing and post-crash disection

Another fairly typical day or two of testing navigation but with some amusing crashes.The first day was uneventful, but the second less so:

Tau Labs Waypoint Testing from James Cotton on Vimeo.

 

More Waypoints and Crash Analysis from James Cotton on Vimeo.

The navigation portion worked really well. I flew a 7 point sequence twice and got very nicely reproducible results.

This shows the log from two sequential flights. You can see the blue trace (real position) follows the path desired (green) quite closely. It's also quite interesting to see that the errors in how it flies the path are quite reproducible. Specifically trying to ask for a sharp angle makes it start oscillating. Parly from the amount of oscillations you can see that this is underdamped and I'll be trying to tune it.

However, the other half of the problem is that the path isn't achievable. Quads cannot make instantaneous turns. We have some code that can reshape paths to something more achievable.

Before filleting path

After filleting

Unfortunately I didn't get a chance to test that yet. When I was testing I did get good performance on the navigation. However, I had two crashes that were pretty bad. In the middle of flying the path it just randomly fell out of the sky.

Luckily the second one I got a log which showed the culprit. Once I started doing nav from takeoff (i.e. arm and flip switch) I kept leaving the throttle in a low position. This resulted in a disarm timeout after 30 second. I decided to use the awesome Python log parsing that Stac has written to visualize the results, as well as the new feature in matplotlib for XKCD-style plots.

Analysis from logged data from crash

So this plot pretty clearly shows the drop in altitude from the baro. While that is happening the desired throttle goes to max, but the actual PWM output drops because the system is disarmed. Unfortunately telemetry didn't catch the change in FlightStatus to definitely prove this, but the time from arming to falling is 30 seconds (both times in the video) which is pretty much conclusive as far as I'm concerned.

Poor quad will be waiting on some new parts though :(. Impressive that it took two of those hits

So the simple solution to this is to keep throttle above zero while performing anything autonomous. This is even on the wiki and something I knew about. I'm hesitant to remove the disarming right now though since when I had the flyaway attempt at OP that was the only thing that ultimately brought it down. For sure the GCS should be honking a huge alarm at you (and Android should) if you are doing this though since it is a guaranteed crash combination.  I opened an issue to discuss this https://github.com/TauLabs/TauLabs/issues/1078 .

EEG Stuffing and Testing

So my Sparky EEG board data boards arrived the other week. I'm quite happy with how they turned out. I used a 0.8mm manufacturing to have something smaller to mount on the head and it seems sufficiently strong.

Before

And after

Before getting into the build, I'll cut straight to the cool punchline.

EEG Testing from James Cotton on Vimeo.

I finally had the opportunity to solder up one up yesterday. The first board I pasted was a little heavy. I'm not used to the 0.8mm boards I ended up using. However, since I only expect to solder one of the 10 boards I got it seemed not worth worrying about so I immediately set the rest of them up as a platform and got a great solder application. The rest of assembly was great and there were a few solder bridges that were easily touched up.

Then the super fun (read: tedious) part of populating the board.

Finally throw it in the toaster oven until done. Only a few shorts which were easily fixed.

 It was pretty easy to bring the board up and get it reading the accelerometer and gyro since that isn't changed from Sparky proper.

 However, I wasn't initially getting any ID when I attempted to query the ADS1299 chip, so it was time to bring out the good old OpenLogic analyzer. Finally I realized I didn't have the SPI Mode correct for this chip and the data phase was wrong. Once that was fixed the communications were flawless. A few hours of writing a driver to work with the chip, bring it up, get the inputs in the right mode, etc.

At this point it was essentially working, and I plugged it into the android app to be able to check out the data (although I can also use the Tau Labs GCS). I went ahead and soldered a straight header on for now so I can test it on the bread board, adding another 10k between VIN1P and SRB1 and then using the 7.8 Hz lead off detection. The data looks pretty good.

With the period matching pretty well. I'm not sure right now why it doesn't look more sinusoidal.

Loiter mode and more RTH testing

So I met up with the Houston flying crew yesterday and had the chance to do more testing of the new RTH and loiter modes.

Loiter testing

One of the changes in this code is that now the VTOL control loop actually tries to control acceleration (and through that the airframe angle). This is inspired by the Arducopter code and seems like a sensible idea since it makes the control laws more linear. It does mean that units of the parameters change so it was necessary to retune.

It took me a bit to find good tuning parameters but overall I was happy with the results by the end of the day. Here are my final gains:

• HorizontalPosPI.Kp was 0.8 with zero Ki
• HorizontalVelPID.Kp was 2 with a Ki and Kd of 0.

Tau Labs Loiter and RTH testing from James Cotton on Vimeo.

The loiter mode is very similar to the Arducopter code. You apply pitch and that will move the set point for position hold forward at a rate proportional to the stick input. Roll moves it sideways.

Mike suggested an alternative control scheme: when the stick input is outside a certain range you fall back to stabilized mode so you can basically free fly, then when you release it goes back to PH mode where you are. I might implement that later and let people compare the two.

I was doing this on Freedom so I had Overo logs afterward to look at. You can see this above - the black dots indicate updates of the setpoint and when I use the stick movement the position moves. The quad does a really nice job of tracking it. If we really zoom in on a steady segment we can see the amount of drift:

You can see there is above 1 meter oscillation around the setpoint. This probably reflects some gains that are too high. I also didn't have any integral yet and it was fairly breezy which explains the residual error. I definitely need to do some work on how to compute optimal tuning parameters for PH and navigation.

Return to home

As you can see in the video above, RTH is also working pretty reliably. I think I probably did about 5 or 6 runs with it and it usually landed within a meter of home. It doesn't turn off the motors when it lands right now - that will come later. The stability during the landing decent wasn't quite as good as some of the other platforms people were showing off - I'm not sure yet if that is a tuning issue or what.

Here are three RTH flights overlaid. You can see it pretty reliably flew back at the right altitude and landed in the correct location. There is also a view from the top. Ignore that trail for one of the flights once it lands - that is just dragging on the ground.

Some interesting points. The middle flight is the one in the video. You can see where it starts shifting back and forth is when the wind was gusting. I should have remembered to do a test flight above the 15m minimum RTH altitude. The RTH paths aren't quite as straight as I would like, but that also comes up to tuning.

Overall it is working well enough to get the copter home, so that is good.