This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Route second waypoint issue
#21
(2020-07-30, 04:28 PM)jamos.tan@gmail.com Wrote:
(2020-07-30, 01:59 PM)rastam4n Wrote: I am jealous you can use the GPS mode in the Pypilot Plugin... I still have not got passed that challenge...

Hope that Sean is able to help looking at the log you posted before. Maybe you can try other filters in the pypilot connection, to only use the EC@@@ sentences in stead of the APB and see what happens if you activate the route. And, uncheck the checkbox for nmea forwarding in the Pypilot OpenCPN plugin. I really feel that Pypilot in your case does not work because it doesn't receive valid sentences.

Also, does it work without activating a route? So, just GPS mode?

Have you made any more progress with APR plugin? I now have working GPS mode and I have installed the APR plugin... but when I activate a route, pypilot switches from compass to gps and sets a course 180 degs away from the first point... even when I am kilometres away from the the first point and all other points are further away yet. 
I am using the settings you posted, wondering if you have anything to add?
Reply
#22
Hmm, I had some issues like this as well.

If you can test on land (rather than sailing out every time) I suggest that you test with a GPS simulator (Francon GPSgate). It's a windows programm, in there is a little program you can put a list of coordinates, and a speed, and an outgoing (TCP / UDP) connection. Maybe a bit of a hassle to set it up, but if you have it, it will save a lot of time. If you let OpenCPN listen to this, it will then visualize your course and speed with incoming GPS sentences. This made it really easy to troubleshoot my problems.

I think I have solved this by looking at the OpenCPN connections mostly:

- Reverse the OpenCPN connection priorities, if you had Pypilot primary, put it secondary. And put Signalk primary, or the other way around, then test the autopilot route (I would suggest with and without the route plugin, to test if the plugin itself causes it)
- Make sure the Pypilot connection is both incoming and outgoing, no incoming filters, only outgoing (in here, test if it works with only APB sentence, or with combination of EC@@@@ sentences also) and then again test both routes with and without plugin.
- Check Signalk if you have NMEA converter active for some of the mentioned sentences, in my case it made a major difference when I just disabled the NMEA converter plugin.
- If you are using a magnetic compass (I know GPS route has nothing to do with it) make sure it is calibrated. Even though a GPS route is used for heading, the ship icon in OpenCPN might be pointing in the wrong direction.

Also, what I noticed, about your problem with 180 degrees away, (i guess you mean the green line Pypilot GUI overlay) I seem to remember that this only happened with the APR plugin, and only when being far away from the route. And, this only happened when not having speed, or testing without GPS simulator. In a real situation it did work, and it seemed to make a difference when configuring the APR plugin for waypoint bearing directly, with small error margins.

I still need to test the APR route plugin in open water, but I have a newborn baby so some of my developments take a little bit more time now. Smile But, it is very very hot today, so I think we need to be on the water anyway. It is unbearable inside!
Reply
#23
Another example doing GPS simulation, with route plugin (but IMU with magnetometer is still being read, so boat icon heading is wrong)

Test 1: route position bearing

I have had best success with this one. Shows pypilot green line GUI in the wrong direction, but, the GUI overlay of Autopilote route app is correct. Maybe, pypilot GUI shows the green line overlay because it directly tries to look at the ships heading. Because the heading of my magnetic compass is that direction, the green line is plotted in that direction as well, eventhough the GPS heading is totally in the other direction.

I guess, in a real life situation this would work.

[Image: 2020-08-08-13-13-36-Aye-Aye-Systems-2-op...Viewer.png]

Test 2: waypoint bearing

This configuration is based on waypoint bearing, my route is in a loop and it is confirmed that in this case the direction of the route is ignored.
The position of the ship seems to have a major influence on the autopilot heading being chosen, also the moment of disabling and enabling the route again has influence. In the mean time the position would have changed and another heading is calculated. I did not have luck with this configuration. Also, the heading that are projected by the GUI seem totally wrong. This is corrected when choosing another mode?


[Image: 2020-08-08-13-20-12-Aye-Aye-Systems-2-op...Viewer.png]

Activating the route and starting from a little bit further shows this:

[Image: 2020-08-08-13-24-34-Aye-Aye-Systems-2-op...Viewer.png]

Test 3: Standard XTE

This mode kind of gave the same results as test 2.

[Image: 2020-08-08-13-26-26-Aye-Aye-Systems-2-op...Viewer.png]

Conclusion:

So now, what to do to troubleshoot. I know a few things:

- I know that the standard route feature of OpenCPN works (tested in real life)
- I know that the APR plugin works best for me, with looped routes and waypoints close together. (only tested in simulation)
- I know that GPS simulator has different results from real life, this is because of the fact that the simulation does not forward IMU readings and OpenCPN 
will overlay either it's last received IMU heading on OpenCPN GUI. Either it only visualizes / presents it and does correct thing in real life, or the plugin "looks" at this data and calculates based on graphical overlay, which I doubt. 


I think, that various route types have different outcomes. If you are navigating in a harbor with closeby waypoints and 10knots speeds, or are you sailing gently on a large ocean crossing. If so, I think that we need to combine all our experiences and improve and collaborate on documenation and help Sean a little bit.

I also think there are still some bugs in the plugin, but Sean is now aware of these. But, I also think the issues that we are experiencing are part of a larger picture we do not understand yet. Maybe the plugin can be enhanced so users are properly aware of this, or guided to a "personal" configuration that works for them. 

Either way, I hope my tests are valuable enough, so we achieve these goals. Next tests will be on water again.
Reply
#24
I have not worked on this plugin for more than 2 years but it worked for me then, and worked well. I only did testing underway and tried to activate the route when the boat was near the route. I'm pretty sure you are hitting this with cases I never tried, and who knows it may even have problems in the other hemisphere (east of 0)

I do intend to fix this plugin. There is so much more it can do, like following a route in wind mode and computing tacks/jibes and displaying future tack predictions.
Reply
#25
Thanks Sean, and don't get me wrong, we are very very happy with this plug-in, and all of your other work for that matter. Just trying to contribute by doing the field work. Wink
Reply
#26
(2020-08-08, 02:30 PM)seandepagnier Wrote: I have not worked on this plugin for more than 2 years but it worked for me then, and worked well.   I only did testing underway and tried to activate the route when the boat was near the route.    I'm pretty sure you are hitting this with cases I never tried, and who knows it may even have problems in the other hemisphere (east of 0)

I do intend to fix this plugin.   There is so much more it can do, like following a route in wind mode and computing tacks/jibes and displaying future tack predictions.

Thanks for all your efforts Sean, without Pypilot I would be much shorter on cash and I would never have brushed up on my linux and soldering...Smile

When you do get around to working on this plugin, I think this would be the perfect place to add in precanned (but configurable) turns for trolling? 
say 4 options 90 deg turn port/starboard and 180 deg turn port/starboard. the configurable part would simply be the turn radius.
Reply
#27
would the plugin generate the route to do this and then just follow it? This would be a simple solution and also plot on the chart the intended course.
Reply
#28
Yes, exactly!
Reply
#29
Some time ago, I was successfully able to follow a route:

[Image: 2020-09-13-11-36-38-REALVNC-and-4-more-p...t-Edge.png]

The loop where I disengaged the route was because I started sailing from that point.
Still have some issues, usually I have to enable a route two times before it will actually steer to it.

When motoring out of the harbor I usually want to engage the AP as soon as possible so I can walk around the deck, but engaging isn't always that straight forward. So, what I usually do is enabling the route when still at the dock (because then I have time and concentration enough to right click on the route and enable) and when out of the harbor I open Pypilot's webapp enabling the GPS autopilot. All the while OpenCPN is on and should follow the route, but somehow I always have to disable and enable again which can be a hassle when there is a lot of ship traffic and waves and handling the sails etc.

Will keep trying... but suggestions are welcome.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)