It's cool that they open sourced this, but as someone who worked at a kite power company (a much smaller company with a much smaller kite) I'm not sure much here will be transferable to other companies. Makani was making a huge 2000 lb "kite" turbine. That requires the kind of money that Google could back them with - and since Google isn't funding this anymore I just don't see where this can go as none of the remaining kite power companies have much funding (ours ran out of money late last year).
While our code might be too specialized to help out other crosswind kite power companies in particular, I think the technical document might be quite impactful:
Thank you so much for that document it's so interesting. Interesting lesson from the exec summary: The real world kite underperformed the model by nearly half, and from the numericals it seems like the main reasons we're that the turning radius was about double that what you were trying to get, and that the tether drag was a significant loss that was not accounted for. The next gen model would be the same span but with a larger area and with a shorter tether, the turning radius would be a lot smaller and it would effectively halve the drag and increase performance by 30% but it would still underperform the initial model by about 20%.
The general big conclusion as I get it is that because of these losses even though the kites are capable of getting more wind per kite, when area is constrained a conventional turbine seems to have better density.
The idea that the kites have lower installation cost offshore does seem interesting to me, but I only skimmed it so maybe that's offset by something else.
The Airborne Wind Energy section is general, and discusses energy kite performance in a broad way - the tether drag was well predicted and wasn't a surprise for our prototype.
The inability to turn the necessary tight paths and some degraded aero performance are responsible for most of the performance miss. Also hugely concerning was the struggle to saturate power at high winds.
It is important to separate and highlight tether drag in the context of the purported big benefit of airborne wind turbines accessing higher, faster winds. While they do indeed access higher winds, they do so via tether length and elevation angle, both of which carry losses. The net effect in almost all scenarios isn't a win.
> ...tether drag was a significant loss that was not accounted for...
I wonder if some of the losses to tether drag could be made up for by re-purposing some of the wave energy tech to capture energy from the base of the tether as the kite pulls and slackens on the base, or if the tether could be made rigid on demand with some tech in the future.
There isn't a large amount of energy stored in the tether catenary or elasticity. Any hardware to recoup it probably wouldn't pay for itself.
Offshore, there can be a lot of energy stored in buoy motion, and utilizing this can help, but probably in a resonant way that doesn't require additional hardware.
"Rigid" is a relative term. The tether already utilized a carbon fiber core. It doesn't get much stiffer, short of going to exotic fibers or more of them, both of which degrade performance in other ways.
The optimum is going to be closer to a strength limited tether than an overly stiff one.
I don't think the goal here is to help other kite power companies. If google thought there was still something there they'd still be funding the project in all likelihood. But who knows what this might teach someone trying to move into a related space? Also it's just freaking cool that this stuff is available.
It was very much a blue-sky project. A very highly ambitious one. Other kite power companies are generally taking much more affordable routes by necessity.
We hope that others find the code useful. There are a lot of goodies in there. A full-fledged flight simulator that could be used to simulate a variety of physical systems. A Kalman-filter-based state estimator. Math libraries. Firmware to run high performance electric motors. We also understand that it's typically very hard to adapt and re-use other people's code, especially when it's no longer actively supported.
Aside from the "code dump" portion, we have published 400 pages of entirely new documentation describing the system, plus about an equal amount of technical document artifacts.
Hopefully someone can use it and realize the kite power dream someday. Right now funding in this space is tough especially, it seems, after Google stopped funding Makani. We used to be able to say "Look, Google is funding this kind of thing" - it lent a certain legitimacy, but now potential funders seem to be nervous about Google dropping the funding.
That's not totally true. While there are certainly custom control laws and gains, almost everything is parameterized in terms of the kite's configuration.
Edit: to clarify, I was responding to:
"I'm not sure much here will be transferable to other companies"
Dude, that's totally true. Just for one example: I.MX, TMS570, and ethernet of all things are all very expensive and extravagant solutions for the application. Those decisions are only supportable if you can hide the cost behind the price tag of a system the size of Makani (preferably much larger). Almost anyone else would be looking at Cortex-M and CAN bus and be quite satisfied with those selections.
The use of those processors and ethernet were not major cost drivers.
There's a very nice technical document describing the network topology titled "A Low-Cost Fiber Optic Avionics Network for Energy Kites" in the collection of technical documents:
At this scale, no of course not. But at 100 kW or 10 kW? Remember that the argument is about applicability to other kite energy systems. Margins get very thin when power electronics costs only 0.03 USD/watt for the entire system. It gets harder to hide signal processing costs as the size of the system decreases.
System scale is a crucial component of a cost competitive energy system. I lay out the argument for this in the early part of my section - Airborne Wind Turbine Performance - of the released documentation.
A 100 kW system may prove useful to some niche, but I don't think can be competitive with the utility energy market at large, even if you give away the system for free.
At the larger scales, these electronics are not meaningful cost drivers at all.
That's true - and it was always tempting to reach for another expensive sensor when we knew that ultimately we would have to simplify and rely on simpler/cheaper components.
Opening it up makes it available to people who might look at it and get an idea. Sometimes the thing has to be available before someone figures out what to do with it.
Oh sure, I completely understand that. The point I was trying to make was that all of this flight control & simulation software is very specific to the characteristics of their particular kite. I'm not aware of anyone else in the industry making a kite that large and heavy - most of these companies are operating on a shoestring budget. Sure, it's possible that maybe some general ideas could be obtained from their autonomous control software - but they would need to be heavily adapted to a different kite with different flight characteristics.
We were starting to think about using reinforcement learning to develop an autonomous controller for our kite. That would have involved recording lots of real-world in-flight data for our particular kite which we were starting to do. Similar flight data for a different kite wouldn't have done us much good when it came to training as each kite has very different flight characteristics.
We don't mention this at all in the technical report, but there was a lot of interest in applying reinforcement learning to the control problem, and there was some work done in this direction. (I was one of several who groaned whenever we were admonished to "just use machine learning." )
Ultimately we couldn't afford to dedicate much effort to the rather speculative RL approach (our team was small and we were always scrambling to meet our rather ambitious milestones - you know, the usual story :-) ). Instead we chose to continue to pursue tried-and-true controls techniques.
