I think the largest hurdle is to decide on the best method of sensing the wind speed. I think there are a couple of ways to go. i think the quickest will be to use a analog input and a 360 deg potentiometer (I only found out they were a thing this afternoon). Another method would be to add support for absolute position encoders, i guess you could do it with the current incremental encoder support but i guess the drift would be quite bad?.
Potentially the most ‘professorial’ solution would be to interface with pre-existing mast head wind veins or add support for a absolute magnetic encoder over either uart or i2c.
I think for my project i will probably start with a 360 pot as it will be the easier to implement.
I would be great to have some advice and discussion about the best way of implementing sailing support, what new modes to add and sailing logic ect. I have more sailing experience than coding so will probably also need some help in that direction too.
Awesome!
Re wind estimates, one thing I’ve considered is using a pair of ms4525 or similar differential pressure sensors, and rather than a standard pitot tube, expose the ports in a square (+/-45, +/-135). This should be small enough to sit atop a mast and give a reasonable estimate once calibrated.
I also did some work on adding support over the past few days and my branch is here. I’ve got a lot on my plate though so we can go with your changes and merge them together.
Re the wind sensor, in my branch I’ve made it temporariliy use the RC channel 6 input for the wind direction. This allows us to test the code even though we don’t have a working windvane yet.
Re the windvane, I think this has become a critical blocker… Philip Rowse is working on a sophisticated solution but I think we are ahead of him so we should probably make something DIY. Connor from this thread is apparently using a “360 pot” which might be based on something like this from sparkfun but I worry that these stop at some point… so the windvane will get stuck if the boat keeps turning in the same direction a few times.
In the mean time have merged your changes into my branch and done some more work on the Library. I think we will also need to support some sort of cups type wind speed sensor, I guess we could use the pitot type airspeed sensors but that would be mechanically tricky to keep them pointing into the wind. For slower sailing boats its not so important, we will just have to decide on some assumptions to make in order to calculate true wind-speed and direction from out wind vane and ground speed.
I wonder if it matters if we know the absolute wind angle vs apparent wind angle.
I’m definitely no expert but I thought the sail was set based on the apparent wind angle… so as the boat speeds up and the apparent wind moves further forward… we need to pull in the mainsail. Is that not true?
I guess when we come to doing navigation and need to decide what angle to tack to, it will be better to know the absolute wind angle.
You are exactly right, you sail off apparent wind. You need to trim the sail to this, you can either trim the sail and stay on the same heading or keep the sail the same and change the heading, for different boats in different situations it may be better to do one or the other or a combination.
But for when you want to know how far round to tack or gybe and navigation its nice to have true wind, so you can match you current angle to the true wind on the new tack.
I think we could probably get it to work OK without true wind angle. If we assume the boat travels at some percentage of wind speed, say 25% we can then calculate a estimated true wind angle. So long as the percentages is higher than reality and thus the estimate true wind is further round than reality. Therefore we will always tack too far round. This is can then be corrected based on the apparent wind once were going on the new tack. Much better to tack round too far than to not go far enough and get stuck head to wind. For our keel boats I think this will work fine, for faster boats that can sail faster than the wind it will be too simple. It might also get caught out when sailing in current and other edge cases too.
It’s apparent wind that’s important. At some point when the code matures perhaps some parameter would be tunable regarding boat speed Vs. wind angle. A light catamaran Vs. a full keel heavy boat would need to behave differently. Sailing is so much of a all the human senses type a thing that it will be interesting how it is handled by a controller. The controller is not going to see a puff of wind ahead of time or a wave coming. These things can easily lock a small, less than 8 foot, RC boat into “irons” while tacking . I sail a lot of RC boats competitively and all designs are different and need to be handled in a specific way. I don’t see the code being meant for speed and racing, but more for long distance purposes to accomplish some purpose more economically than a larger manned vessel .
That looks like a great little sensor and would be ideal, unfortunately the none US distributor is out of stock.
I have been looking into a wind speed sensor, I thought a cups type sensor would be the way to go but they are quite big, would be at least as wide as the hull, pitot tube on the wind vane would be good but then you have to somehow get the signal off the rotating bit.
I guess the ultimate solution would be ultrasonic.
I think we can get it working well for even racing given time, we have the advantage over RC sailors of actualy being on the boat. As you say we will never be able to sail over to the patch of wind automatically. Some codes do wave tracking so they can tack on a flat bit.
I think we need some sort of system like planes TECS. This could select ideal sailing angles for the wind conditions and weather to bear off or sheet out in gusts, it could then be tuned to each boat just for best performance. Once we have the basics working I will have a look for papers.
Racing is like a chess match. What you do with the boat is often dictated by what your opponents are doing and determining when to go on offense or defense.
Not read all the papers yet, but I think I have a basic understanding. I can send the papers to anyone who is interested, but I better not post them here as I’m not sure how may off them are open access. Also if anyone has another paperers that would be great, or needs to access some I can have a go.
Essentially my understanding is that in order to determine the fastest way of getting to any one point you can use the boats polar plot to calculate tacking angles. This plot is just a record of the best/ideal case boat speed at each true wind angle and wind speed.
So the tricky bit in not really the navigation but generating this polar diagram for a wide range of conditions. So far there are three different approaches.
Generate a polar plot based on a number of none dimensional numbers calculated from the size and shape of your boat. There are a few sets of empirical equations that are commonly used. These equations however are based on measurements or full size yachts and will likely not apply to smaller scale craft very well. Especially unusual configurations.
Black box approach, the polar is drawn from only test data, The boat utilizes a maximizing algorithm to optimism its speed, once a good solution is found this becomes a point on the plot. This has the advantage of not needing to know anything about the boat. It will however take a significant amount of time to converge to a solution. As each trail and error step will take tens of seconds to reach a steady state. This could result in several hours to get a good polar for a range of wind conditions. I guess this method is similar to copters auto tune, sort of.
This is sort of a mixture, you generate you polar based on size and shape but then compare it to what can be achieved using method 2. Because your just sort of calibrating your parameters you just need to pick a couple of points rather than populate the whole polar so its quicker.
I think something a bit like 3. would probably be the best way to go. Would be nice to implement some sort of long term learning so it will continually improve. Possibly give it a generic polar plot to start with, each ‘point’ on the plot could have a low level of confidence then as it sails along it trys to optimizes speed and thus alters the polar to match this would then increase the confidence level in that point. Once it competently confident it would then stop trying to optimisme that point of sail and try another one near buy. Hope fully we would end with a polar that is quite accurate at the ‘useful’ points of sail that would be the fastest for going up and down wind.
These sailing boats it turns out are a lot more complex systems than copters and planes. In order to fully charictierise each boat I think we need:
Ideal heal angle, this is essentialy power for fixed keel boats.
Target/achievable speed
at a range of sea states, wind speeds and true wind angles.
This will require a large number of parameters to competently define, Its I think essentially two 3dof polynomials. But is we want to update points as we go it would be better stored as a set of look up tables. I think this would be too much for parameters, possibly we could do something on the SD card, not too sure.
In the mean time I will keep reading the papers I have found, would welcome any other ideas or feedback.
OK, that’s very interesting. the ideal heal angle in particular makes sense and isn’t something I’d ever even considered.
I agree that (3) is probably the best approach. Maybe it will become clear what those tuning/calibration parameters are once we start collecting data from our own boats and other users.
Weather helm is something else that may need to be taken into consideration. In other words how much rudder needs to be applied to sail straight. If it becomes excessive ease sheets a bit.
Thanks to @rmackay9 for adding logging, what is the best way to add your stuff to my pull request? I have had a play about and I think the best thing to do would be for me to close the current PR and open a new one with a clone of your branch.
The code now compiles but wont run, I guess I have made a error somewhere, this would also explain why it failed auto-test. I guess it must be something in the main loop or the library that is called regularly, I have had it in plane where it will work fine but then lock up when you switch to the mode that uses the new code. I have tried my version without the logging and Randy’s new version, no luck with either. Any tips on the best way to debug this, I guess just commenting out stuff until it works again?
I wanted to go and test the boat so I flashed the daily build of rover for a test run. I still ran into some issues however. I couldn’t get Sbus to work on the f405-wing not sure whats going on here it seems to work for others, flashed copter to see if it was a rover thing but still no luck, I checked the receiver was working on a pixhawk. Possibly a bug in the latest code? PPM works fine on both the rx2 and Sbus pins on the f405-wing so I ended up using a PPM decoder just to get it working. Also fr-sky pass-through telemetry only worked when disarmed, would lock up when armed then when you disarmed again you would get all the buffed messages through, again not to sure whats going on, its always worked perfectly for me on copter.
I ended up setting the main sheet servo to pass through the throttle channel and went for a test. Unfortunately I forgot to re-calibrate the compass after flashing firmware back and forth so It wouldn’t let me try acro mode and I had no laptop to start a calibration (I tried to start on using the sticks like you can on copter, I guess this is not implemented in rover?) So I had a nice sail round in essential manual mode, I also sailed round with it disarmed so I could keep a eye on the battery via the pass-through telemetry. Its good to know the boat is up to it, I can concentrate on the software now.
I have a 360deg pot for a wind vane on the desk, telemetry radio and one of @LuisVale 's wind sensors in the post so hopefully we can have sailing working nicely in the near future!
“cherry picking” from my branch is the way to get my commit in there. Personally I usually use the gitk tool to do that, “gitk randy/branch-name” and then right-mouse-button-click on the commit and select “cherry pick”. If you can’t figure that out, I can push my commit directly to your branch I think (branches that are sent as PRs become editable by others).
Closing the existing PR and opening a new one sounds fine to me.
Can you show a picture of your wind vane? I’ll probably order one of the sensors suggested by Luis … but it’s the direction part that I’m unsure of how to do.
