The tow test on Wed Nov 14 provided some insight into how much force is needed to pull our kiteboat at a range of speeds. By measuring the tension of the tow line and plotting it against the boat speed, we can infer the approximate force that a kite would need to generate to pull the boat at those speeds. The first attached plot shows only the tests with a crew of three, for which the maximum sustainted speed was 38 knots. The second plot shows the towing power, calculated as the product of the force and speed. The polynomial fit (red and green lines) may be helpful to understand the density and trend of the collected data, but should […more]
Dudu has been working on the bridle system algorithm for the last 3 weeks, and he finally got it working.
It has the same tools as the current software with many improvements. The algorithm finds the perfect path from the bar through all the bifurcating points along the “tree” to finally end on each kite attachment point. Attached are some screen grabs of one bridle model, and below is the XML file that contains bridle data and the C++ code that is the “engine” of the bridle system.
This was designed to be flexible and allow the use on many types of objects other than conventional kites. Dudu is now working now on the UI (User Interface) to facilitate the flexible design and […more]
Jamie has made several changes to the KAICam Android application, in support of the cruise with MBARI this week. To make the screen space on larger tablets more usable, the layout is now dynamically adjusted to maximize the preview image size.
To help in situations in which the network topology changes frequently, the app now automatically find other instances of itself that inhabit the same network. This way, the remote viewing client can connect to a camera server without being specially configured with the camera’s IP address in advance.
Other improvements include better networking efficiency and stability, and the continuous logging of GPS and air pressure (for altitude) where available.
The two images are screenshots of the app running on […more]
We have made progress in creating a usable web interface to the kiteboat and Kite Assist logging systems. The basic idea is that the logger acts as a wireless router and web server. Any wifi-enabled device with a browser can connect to view the logger status, monitor the realtime data stream, and to send control commands to the device network.
Pictured are two Android mobile devices, which are connected to the kiteboat logger and showing realtime telemetry. The phone on the left is displaying the boat speed, line load, and kite inflation pressure. The larger tablet has a “kite” screen selected, which shows the current kite inflation pressure, the target inflation (with +/- pressure adjustment controls), and the battery voltage […more]
KAIView 0.2.6 contains several improvements from the last few weeks, particularly in the mapping component and its integration with the other data displays. The overall goal has been to make the mapping window more useful as a primary interface to the data, instead of just a supplement to the graph display. By default the map window is now larger, the data that it already displayed is easier to read, and a legend shows the geographic scale and the meaning of the color-coded data.
In addition to these visual changes, there is now better correspondence between selections made in the graph window and those made in the map. Right-clicking and dragging in either view will create a selection that is shown […more]
We are exploring the use of our new Nexus S Android phone as a kite-based programmable wireless camera and pan/tilt controller. The first step in making this happen was to make a bluetooth connection to an RC servo controller and control it from the phone.
For extra fun, we mapped the phone’s orientation to its commands so that the pan/tilt unit tracks the phone’s rotations.
Next we will improve the app so that a user interface on a second phone or a remote computer can control the phone remotely over a socket connection. The final step will be to transmit both low-resolution, low-latency “preview” images and full-resolution images from the phone back to its client.