Tack and Laylines Plugin - Beta?

[rgleason]

Dominiq,
Sorry I got sidetracked on the main goal for now.
Here are some screenshots using Paul's upwind file from San Francisco Bay Bridge area. It's a very useful and helpful file, see this thread
http://www.cruisersforum.com/forums/...ml#post2090849

Also I have been using OpenCPN v4.2.0 rather than v4.2.1 lately and no matter what .pol or .csv file I use there does not seem to be a double polar diagram image with the black one on top, so perhaps that problem has more to do with v4.2.1?

Anyway, the angle between tacks seems to be too narrow and together about 90 degrees off. I will try to find some B&G Sailsteer layline screenshots to augment this.

[rgleason]

I found this Instrument by tom_BigSpeedy intriguing.

http://www.cruisersforum.com/forums/...ml#post1915794

because of the goal to reduce the real estate and number of dials and get data into a condensed area.

This is another good example.
http://www.cruisersforum.com/forums/...ml#post1914181

[rgleason]

Dominiq,

After watching TnL operate for awhile in different configurations and using NavMonPC to feed nmea to Opencpn v4.2.0 I believe that the basic wind direction is acting properly and is calculated appropriately, and I realize that the problem is the calculation of the tacking angle from the polar files. The current calculation is resulting in two narrow an angle (as you know the angle should be closer to 90-110 degrees I think).

I am going to try to find the calculation in the code, but I suspect it may be using some wrong parameters.

[rgleason]

Starting line 599 tackandlay_pi.cpp

if (Wind.TWS > 2) {
GetCanvasPixLL(vp, &pp, boat_lat, boat_lon);
boat_center = pp;

//Using TWD<=TWA+COG
Wind.TWD = (Wind.TWA + Boat.COG);

//Test of greater than 360 and if so subtract 360
if (Wind.TWD > 360) Wind.TWD = Wind.TWD - 360;

//Draw Black Wind_Barb at boat_center, Vector Direction=Wind.TWD and Length=Wind.TWS
Draw_Wind_Barb(boat_center, Wind.TWD, Wind.TWS);

//Test if wind is forward of the beam, port or starboard
// Set the tack_angle = TWA_for_Max_Tack_VMG (Wind.TWS) using the polar array
// So what does TWA_for_Max_Tack_VMG do?
if(Wind.TWA <= 90 || Wind.TWA > 270) { // Wind forward
tack_angle = TWA_for_Max_Tack_VMG(Wind.TWS);
//red green blue alpa so its a green line
glColor4ub(0, 255, 0, 255);
}

//Checking for downwind wind aft of the beam. Uses a different formula
if(Wind.TWA > 90 && Wind.TWA <= 270) {
tack_angle = TWA_for_Max_Run_VMG(Wind.TWS);
// different color is green-blue
glColor4ub(0, 255, 255, 255);

So what does TWA_for_Max_Tack_VMG do?

[rgleason]

Starting Line 702 Tackandlay_pi.cpp

double tackandlay_pi::TWA_for_Max_VMG_to_Mark(double TWS, double TWD, double BTM)
{
double pol_speed, max_speed = 0;
int pol_TWA=-1, max_TWA=-1;
int i_wspd =-1;

for (int i = 0; i < MAX_WINDSPEED_INDEX; i++) { // Find current wind speed index
if (Master_pol[i].TWS < TWS)
i_wspd = i + 1;
}

double Course_WA = TWD - BTM; // determine if upwind or downwind to mark

if (Course_WA < 30) {

};

if (Course_WA < 90) { // Tacking - approach from 0
for (int j_wdir = 0; j_wdir < 30 ; j_wdir++) // 0-90 deg TWA

{
pol_speed = Master_pol[i_wspd].boat_speed[j_wdir];
pol_TWA = Master_pol[i_wspd].TWA[j_wdir];

double VMG = Calc_VMG_W(pol_TWA, pol_speed); //VMG_C to wind
if (VMG > max_speed) {
max_speed = VMG;
max_TWA = pol_TWA;
}
}
} else if(Course_WA > 90) { // Running - approach from 180
for (int j_wdir = 59; j_wdir >= 30; j_wdir--) { // 180 -> 90 deg TWA
pol_speed = Master_pol[i_wspd].boat_speed[j_wdir];
pol_TWA = Master_pol[i_wspd].TWA[j_wdir];

double VMG = Calc_VMG_W(pol_TWA, pol_speed); //VMG_C to wind
if (VMG > max_speed) {
max_speed = VMG;
max_TWA = pol_TWA;
}
}
}
return max_TWA;
}

What is BTM? Everything seems dependent on it. Something "B" to Mark?
Also what does "double" do?

Also where is the calc for the layline angle done, or perhaps it is done somewhere else?

Also, is this checking for downwind again? If so, I thought
TWA_for_Max_VMG_to_Mark was for calc of Upwind Max_VMG, so why do it twice?
--See end of previous post using different calcs "TWA_for_Max_Run_VMG(Wind.TWS)"

} else if(Course_WA > 90) { // Running - approach from 180
for (int j_wdir = 59; j_wdir >= 30; j_wdir--) { // 180 -> 90 deg TWA
pol_speed = Master_pol[i_wspd].boat_speed[j_wdir];
pol_TWA = Master_pol[i_wspd].TWA[j_wdir];

double VMG = Calc_VMG_W(pol_TWA, pol_speed); //VMG_C to wind
if (VMG > max_speed) {
max_speed = VMG;
max_TWA = pol_TWA;

AT line 660 this is found:

double tackandlay_pi::Calc_VMG_W( double TWA, double SOG)
{
double speed = SOG * cos(TWA * PI / 180);
return speed;
}

double tackandlay_pi::Calc_VMG_C(double COG, double SOG, double BTM)
{
double speed = SOG * cos((COG-BTM)* PI/180);
return speed;
}

[rgleason]

I'm trying to change the TnL plugin icon. There is a TnL.png icon that needs to be turned into a bitmap code that gets placed into icons.cpp, ...I think.

Both are attached...delete the .doc on icons.cpp please.
At the top of icons.cpp there is a note

"/* Autogenerated by png2wx.pl on Fri Jun 22 12:43:35 2012 */"

Is png2wx.pl a python script? If so do I just point it at TnL.png and take the output and paste it into icon.cpp in place of what is there?

https://github.com/ghthor/hxtools/bl.../smm/png2wx.py

No I guess it is a perl script. I can't do that.

Is there a more modern way for icons now, using svg? Is that hard to do? I suppose the cmake has to change and we need to add the SVG files, but that would be better I think.

[Paul Elliott]

double Course_WA = TWD - BTM;

BTM is probably the Boat To Mark bearing. True Wind Direction minus BTM will give you the Wind Angle when the boat is pointing at the mark.

"double" is a variable type declaration. Variable "Course_WA" is being declared as a double precision floating point type. The actual precision of a double is machine-dependent, but it is extremely precise.

[rgleason]

I asked Willem Amels of TacticTool about current and leeway. Here is his response.

Current and leeway are not calculated separately, as the only way to calculate leeway or current is to compare the COG/SOG with Speedlog and heading. The difference between the two is calculated as a vector. The vector could be leeway when there is no current.

So the best way is to find slack tide, by watching bouys and then record carefullly in different winds. Then put that data into a reference table. Its also when you will get the best polars, so that makes a second reason to check that there is no current!

Then we would need to reference the heeling table somehow for the current calcs.

[Paul Elliott]

You can of course visually observe leeway by looking at your wake. Stand by the mast and look aft. The wake will not be exactly in line with the boat centerline, but will be off at a slight angle, which is your leeway. This assumes that any current you are in is uniform, but the technique usually works well enough.

Some racing programs use ultrasonic water speed transducers that can track the angle of water flow as well as the speed (much like a wind sensor), and so measure leeway.

Leeway matters because it upsets the relationship between heading and course. With no leeway, course = heading in a water-referenced system. (This is not the same as COG, in this case I'm merely talking about the boat not going where it's pointed, and not considering current at all.) The leeway has the effect of shifting apparent wind and disturbing the AW/TW calculations.

[rgleason]

Paul, I'd like to know if you disagree with statements in the post below.

I like your wake idea and the transponders that sense leeway (but too high tech for me though).

I am suggesting that we should measure polars with no current, and record a full set of nmea readings, including Heel Angle (using manual comments as appropriate), AW, TW, HDG, STW, COG, SOG, etc. The difference between the HDG/STW vector and the COG/SOG vector should then be a Vector that is amount of Leeway at that wind speed (since Current=0). - (What if the vector is not perpendicular to thee boat's centerline? What would that other small force be?)

I am saying eliminate Current from the equation and use COG/SOG to help calculate leeway, while you are recording your polars.

This is not the same as COG, in this case I'm merely talking about the boat not going where it's pointed, and not considering current at all.)

The leeway has the effect of shifting apparent wind and disturbing the AW/TW calculations

Yes, that is another reason I think we should try to know/measure/approximate what the Leeway is at different heel angles (or even wind speeds).

[Paul Elliott]

If you have no current, then you can measure leeway as the difference between heading and COG. While I guess leeway is actually in the direction that the wind is blowing, you might as well think of leeway as being at right angles to the boat heading. The resulting leeway / speed combination is a single course vector anyway.

Leeway is often estimated using the equation:
Leeway = K * heel / speed^2

K = a constant, selected to best match your boat performance. K=10 for a typical racer, and K=12 for a typical cruiser, but with measurement you can get a more accurate number.

heel = boat heel angle in degrees

speed^2 = (speed through the water in knots) squared

The equation gives leeway in degrees.

I've also seen leeway equations that use windspeed instead of heel angle, but can't find any examples at the moment.

Here are a few links that discuss leeway and calculations:

http://www.bandg.com/Documents/essen...8x210_1334.pdf
Calibration Details
Leeway

Finally, I have to admit that I've never tried any of this on my own boat, or in NavMonPc. I got those typical K factors by reading about leeway, not my own measurements. Just getting the apparent wind instruments accurately calibrated is tough enough, what with upwash corrections and other factors. My own instruments are poorly calibrated, so any leeway fine-tuning would be wasted effort. As I said in the other thread, "garbage in, garbage out"

[tom_BigSpeedy]

Hi guys,

I'm pretty close to where I want to get with my performance adaption of dashboard_pi. What I basically did was to clone dashboard_pi and rename it,
then threw some instruments out and added a set of performance instruments instead (there's a technical restriction in dashboard_pi, as is right now, you cannot add any further instruments/NMEA channels).
Anyway, I still have in mind to merge that stuff back into dashboard_pi once it's stable and runs as expected. I named the plugin tactics_pi, and you can simply run it like a second dashboard in parallel. Bascially you can load a polar now (took the code from polar_pi, to keep the plugins compatible), and I also took some ideas from "tack and layline".
What is currently available :
* calculate true wind data : TWA, TWD, TWS from true heading (HDT), speed through water (STW) and app. Wind speed (AWS). Calculation is only done if not yet available on the bus.
* Calculate the momentary surface sea current and display it as single instruments (current speed/direction) or as overlay on the chart (semi transparent). The routines take boat heel into account. If you don't have a heel sensor, there is a simple workaround, you can enter a simply heel polar manually (see preferences screenshot). Current display in the chart can be disabled by a preference setting.
*calculate and display the boat laylines for the current tack, and the same AWA on the other tack. Surface sea current is taken into account, if available ! Laylines may be toggled on/off.

* You can load a polar file and calculate/display performance data, like Target-VMG speed, Target-TWA (the opt. TWA up-/downwind), CMG (course made good towards a waypoint), Polar speed (=the speed you should be able to sail at current TWA/TWS based on your polar),...

* you can set a temporary waypoint and show the laylines to the mark, based on a Target TWA calculation

*it has a “dial instruments” which I called “Bearing compass”. Boat true heading points “up”, it shows also the boat laylines, the sea current, a pointer to the waypoint (either set manually or read from a NMEA RMB sentence), AWA, TWA and a marker for the Target-TWA.

* you can display a wind barb at the boat and temp. WP position, showing wind speed and direction


Currently there's a tab with a lot of preferences, which I added to improve easy testing. This may be reduced to what's really necessary in the end ...


What is still open :
* I changed the filtering of the surface current calculation, this needs thorough testing.
* Target CMG calculation still has a bug
* Layline calculation towards the temp. waypoint need to be reworked and the results verified:
On the first layline screenshot you see a "valid fix" (where the calculation makes sense)
on the second screenshot with the wind barbs, you don't you don't have a "fix", meaning that when you sail optimum/target TWA you won't make it to the waypoint ...
I need to rethink these calculations ...
Currently implemented and compiled under Win7, VC 2013


Thomas

[rgleason]

tom_BigSpeedy, wow. Aren't we all going to be spoiled!

It looks pretty darn good to me, even though there are some things to work out yet.
With Tactical_pi you have stepped way ahead of TackandLay_pi and the the idea of a Sailing Console seems much closer!

Thomas, we've been reading a lot lately as you can see. There are some things about VMG that we have learned. The VMG as currently implemented in Dashboard is VMG to Mark or often called VMC=Velocity made Good to Course. I see that we so note it in the Terminology kept under weather_routing_pi User Documentation (Terminology should probably be moved to a more universal location). I think those VMG instruments should be renamed to VMC in Dashboard. If everyone agrees, I will put in a Tracker request.

Then that would leave us with VMG = Velocity made Good for upwind/downwind (using True wind, I believe), which is the data needed for Optimum Sailing Angle (although for heavy keelboats which have momentum, the helmsman should not actually react to VMG upwind/downwind, but should be looking at Target Boatspeeds.

I also understand that when reaching, the better data for the helmsman is a Performance % value= Target Boatspeed/Actual Boatspeed.



Paul,
I agree about calibration of instruments being of key importance. The old Ocham site had some really really good pages about the process, perhaps I saved them and can find them. I found this page on how Ockam calculates good too
I had not seen the L-36.com Leeway page before. It's also very good. Thank you.

Your link to Sailboat Instruments Blogspot Leeway has two links that tom_BigSpeedy might like or be able to use some of it.
Leeway Calibration Part 2 (in C language)
Leeway Calibration Part 3 (an accessment)

By the way, your instrumentation in NavMonPC is very good too, which is a hugely useful swiss army knife for many many reasons! I keep finding other uses for it. Over the years it has gotten better and better. Thank you.

[rgleason]

Looking at the images:

I like the Bearing Compass.

Bearing Compass
predicted SOG ~4.1 knt - Predicted from Polars?
Blue current arrow - Changes length with current speed? Maybe a tick mark for each knot?
Polarspeed - 73% / 5.82kn - Target boat speed? Directly from Polars, with Performance% - nice.
perf VMG - predicted VMG upwind/downwind from Polars?

Laylines image, nice.
Bearing Compass, like the laylines, AWA, TWA, and Marker for Target TWA, and Wpt direction.
Preferences --Manual heel and leeway, really nice for me.

Thank you Thomas for the update.

[rgleason]

There were some other links with good calcs and C code for True Wind, VMG, Current etc that I wanted to add, in case they might help, or provide some further insight:

Sailboat Instruments: True wind, VMG and current calculations

King Tide Sailing: Set and Drift; or, the Speed and Direction of the Tidal Current (NMEA-0183 VDR)

King Tide Sailing: Correcting NMEA-0183 Wind for Vessel Roll, Pitch, and Yaw