I just booted up the sailboat SITL simulator to check, in MP’s mavlink inspector (ctrl+f) i’m seeing message 168 at 2hz.
I’m not sure which of the stream rate param it’s under, but it should not need and changes. The only requirements should be that your a rover and have wind-vane enabled.
I’ve got a project update!
After encountering a persistent, pernicious segfault originating somewhere deep in my hacked-together Raspberry Pi port of Ardupilot, I threw in the towel and invested in an F765-Wing flight controller. So far this has produced zero segfaults!
Because I didn’t want to shell out for a quality transmitter, I found a nifty PPM transmitter/receiver library for the Arduino Nano and NRF24 and I 3D printed a controller. I modified the receiver code to work on the Teensy 3.2, which resulted in much more consistent PPM output.
The windvane library hasn’t given me any problems yet, but I may switch to the AS5045 chip instead of the AS5048 because I hooked the AS5048 up backwards and let the magic blue smoke out I’ve found that 14 bits of resolution is far too accurate.
My next step is going to be to get the F765 talking to the GPS on the Raspberry Pi stack. After that, I’ll try to set the Raspberry Pi up as a companion computer. Luckily, the F765 is positively crawling in UARTs so I’ve got plenty of options to hook them up. My stretch goal with the Raspberry Pi is to hook it up the Internet with video so that my friends and family can drive the sailboat from across the country during my next regatta.
In a parallel effort, my school project team with Jane and Alex is going well – we got a particle filter for true wind estimation to converge and we are working on a UKF. The jury’s out on whether these filters will provide a lightweight, significant improvement over the current implementation – they might be better suited for an optional ROS node.
Thank you all for your help and I’ll keep you posted on new developments!
Tim
Hi! I’ve encountered some sort of bug in the I2C handling of the AS5048B sensor. The driver worked just fine on the Linux board, but on the new ChibiOS F765-Wing I’m getting the following line repeatedly printed to the console (visible in MAVProxy):
I2C: not owner of 0x4109 for addr 0x41.
The angle is not ever successfully read and updated into the AP_Windvane frontend. The cryptic message above is sent by AP_HAL_ChibiOS::I2CDevice.cpp when the I2C library cannot verify the ownership of a bus semaphore. I can’t figure out why the bus semaphore would not be owned in ChibiOS when it was in Linux.
I suspect it’s not a peripheral hardware error because I’m able to query the I2C registers from MAVProxy manually. The following block is a successful attempt to query the most significant byte of the magnetic field angle from the AS5048B while executing mavproxy.py.
devop read i2c '' 1 0x41 0xFE 1
HOLD> Operation 10 OK: 1 bytes
0 1 2 3 4 5 6 7 8 9 a b c d e f
f0: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 36 --
Does anyone have an idea of what could be causing the driver (available here) to fail? I’ve checked in with the ChibiOS gitter but haven’t had any responses, and I’m not quite sure where else to ask.
Thank you!
Solved! It turns out I had misused the WITH_SEMAPHORE macro, and I needed to explicitly surround any code which used I2C resources with
if(!_dev->get_semaphore()->take(0)){
return;
}
// ... my code
_dev->get_semaphore()->give();
I’m working on an ArduPilot sailboat, based on a Horizon Hobby Ragazza. I’ve been having some issues getting good navigation performance, as illustrated by the map below:
The performance especially seems to degrade in low wind. Obviously, sailboats need some wind to function, but I am observing that the boat starts turning in circles and otherwise misbehaving (see right before waypoint 3 in the above map) in low winds that are definitely still sail-able.
Even in higher winds, I still see lots of swerving (not tacking), which can be seen between waypoints 4 and 1. I tried increasing NAVL1_PERIOD, but even at what high values (20) this did not solve the problem.
I’m having a hard time determining what part of the navigation system is at fault. Earlier, I was having some issues with stiction in the wind vane preventing accurate readings at low wind speeds, but I believe I have solved that by setting WNDVN_SPEED_MIN. The steering rate controller seems to work okay in acro, but I’m not really sure what to look for. I have noticed rudder oscillations which I think are caused by a too large P gain.
Here is the log from the run shown in the map above: https://drive.google.com/open?id=1Zfhucv20Fj6UGc8B5eHllzKCGKA8iVrh
Here is a log from another run where I just gave rate step inputs in acro mode. The wind died completely pretty soon after I started, so only look at the first few minutes: https://drive.google.com/open?id=1WbDC1ZjfaPoJVKYjuEAO06KjbOUBbmHb
I would appreciate it if someone could take a look at these logs and offer any suggestions.
Also, it would be helpful to see the parameters from someone who has a well tuned boat, to use as a baseline to compare against mine.
Hi Ben, Welcome,
The default sailboat params are based on my IOM, that also used the defaults navigation gains basically because I never got round to tuning them, they should work fine for the most part.
I think your issue is a ‘sticky’ or inaccurate wind vane. This is your calculated true wind direction for the second log. (SAIL -> WindDirTrue)
Its a little hard to tell due to the wrap at +/- 180 but your seeing a big swing in wind direction, >90 degrees. (it looks better toward the end)
For comparison this the true wind direction from my boat for about a hour.
Again we have the +/- 180 wrap, but its probably staying within +/- 20 deg.
I never had a huge amount of success with the analog vane, at least the one I made. It took quite a lot of wind to work well and would still be out by a tens of degrees. You should still be able to get it to work OK tho. You can set the boat up pointing north so true wind = apparent wind and use the wind direction number reported back to mission planner to test it. If you have a dead zone try and get so that is when the wind is from behind.
Interesting that it gets so big, I guess it must be due to always turning in one direction.
I did some more analysis, this is a normalized histogram of true wind direction from my log (red) and the second log (blue).
I have never done this sort of analysis for wind before, its quite interesting. The blue is showing more or less a random distribution. (of course that in itself does not mean its wrong, but we can probably safely assume the wind was from a constant ish direction for the duration of the log). My log in red shows a better ‘grouping’. In my log you can clearly see a change in direction when the boat switched from up wind to downwind. There are probably a couple of additional factors. Compass accuracy makes quite a big difference to the true wind calculation (although it should not make any difference to how well we manage to sail as that is done using apparent wind). Also when going downwind the mast and sails must affect the wind vane differently.
Thanks for taking a look at my logs. I agree that the quality of the wind data looks pretty poor. I was hoping WNDVN_SPEED_MIN would solve the issues I was having with wind vane friction, but I am still noticing cases where it is obviously sticking.
In the second log, the wind vane direction was actually ignored most of the time because the wind speed was too low. The sudden swings in true wind are misleading because they are caused by noise in the boat velocity measurement. The histogram below from the first run looks closer to yours, but there are still lots of outliers.
The plot below shows a case where the boat’s yaw is obviously coupled with the wind vane measurement. I normalized the apparent wind to minimize wrapping, and placed it in earth frame so the flat spots where the measurements are ignored are clearly visible.
I have noticed that sometimes low wind causes the vane to stick while the boat is turning, but the wind speed sensor doesn’t drop below WNDVN_SPEED_MIN in time and the boat will be stuck with a wildly inaccurate reading until the wind comes up again.
I am currently using a Davis Anemometer mounted on the top of the mast. This sensor is fairly heavy, and the Ragazza has a pretty tall mast, so it makes the boat prone to excessive heeling in strong winds (see this video: https://drive.google.com/open?id=14EOcr_fgoNZZJVpGwup6MCte562vk-zC). This exacerbates the problem with the wind vane, because I can’t sail in conditions that would make the vane work well.
I’m planning on trying a custom wind vane with a larger area, as well as moving the wind vane part way down the mast to reduce the moment without hopefully compromising wind flow.
Hi Pete,
Hope all is fine.
just sharing some of my experience with the Wing sail on the RC Laser.
Cut the story short,
If the motor is enabled then, I would expect the motor to do help on tacking, keep the boat speed up in auto modes etc,
but if the motor is disabled (sail only) , then I would expect it to do nothing at all.
Maybe I got this wrong? Reason for asking, please have a look at the video.
Sailing to waypoint 1 feeling good.
Getting to WP1 great!
Then the problems start - please don’t worry much about why it can’t find WP2, maybe its because I did not turned throttle all the way up from all the way down. I have no idea.
But what my concerns is that the motor starts engaging 3 times in hovering around WP 1 trying to find WP2. Why did the motor do that? I was expecting it to do nothing.
After allowing it a long time to maybe sort things out (including going backwards with reversed rudder), I decided that it will go no where so I switched to RTL mode.
Then motor engage again and unfortunately ended the sail for today.
Of course, it should not stay capsized for so long so I need to do some change to the design, however that’s another topic.
My takeaway for today, was the good feeling I had as it was sailing and reaching WP1 
p.s.
Can I be sure the motor is not doing anything by applying the RC4_(31) E-stop?
d.s.
Yeah E-stop will stop the motor in all modes and at all times, do you have a log? I the motor coming on in RTL is probably it trying to assist with a tack, you should see a message in the messages tab if this is the case, you can always playback the t-log and see.
Thanks,
Good, then I have a fool proof way to make sure motor is never engaged.
Yes, the telemetry log show a message “Sailboat: Tacking”, that is the confirmation the motor was engaged in trying to complete the tack right, it was in RTL mode.
I am easily confused so please help sort this out for me.
RC9_(74) Motor 3 pos is set like this:
Min
Mid
Max
So, I should assign
right?
I know before I learned the flight modes had preset intervals that has to be matched from the the radio transmitter.
Is it the same here? will this interval be enough for the SW to discriminate all the 3 modes?
I don’t see anyway I can test it understands the modes 1 2 and 3?
Best
Yes
yes, for switched its less than 1200 for low, and greater than 1800 for high and in between is middle, so your switches should be fine, although the min is quite close it might be worth lowering it a little.
There is no feed back if it got the message, although it is something that would be easy to add if you think it would be useful.
Clear!
Na, no need add feed back as long you are answering questions here 
Just a thought, if we have a mode called Always sail, is it not misleading that this mode will still engage motor to help to tack?
The motor should only be engaging to help a tack in the middle switch assist position. You lower PWM only is only 4us lower than the limit so its quite possible that on that day it was not switching all the way off.
Thanks a lot for clearing this out!
I will set up the switch with more clear distances.
This is what I have set up now,
I am afraid I can’t separate it more than this from my transmitter.
I hope it will work when I get a chance to test it.
Min
Mid
Max
K
Last weekend I had a chance to sail and the new setting seems to work. Motor is not kicking in when its in Always sail mode.
Also, I redesigned the wing rig (from the one that capsized and stayed down), it was was stronger than the first one but heavier and therefor needed more ballast. This one is both stronger and lighter so it do not need more ballast.
From this:
To this:
And it works better sailing:
I will need to build a smaller size wing for winds over 10 knots.
Furthermore,
I sailed around to learn more about how to tack and get best speed and angle to the wind using the wing control tab.
It seems to me the thing that worked best was to first turn the control tab over to the next tack and then turn the rudder to tack. That seems to help pull the boat over to the next leg.
I will post some clips showing manual tacking here:
Now, during this ~1 hour sail, I did not try Auto like last time, just manual and Acro.
During all that time it failed every time to tack in Acro, except once. Thats good since I think it confirms the code is good and it just have an issue in tacking.
I will post some clips showing failed tacking attempts in Acro here (not lacking wind):
Then the one time it (barely) succeeded tacking in Acro here:
Question Pete,
. the tacking switch function, that only works in Auto, RTL etc modes and not in Acro right?
Could it be made to work in Acro as well? It could help figure this out.
. when a tacking in Auto mode (with the wing sail), first rudder is turned and then the code is waiting for the wind direction to change before it flips the wing tab? That might be a problem.
…
b t w
Going with the wind topped just over 3 knots.
Boat front is getting low in the water.
This wing has the same area as the default sail of a laser, but different shape of course.
Nice!
I’m Jealous that you can go out testing, still in lock down here.
The tack switch does work in acro, but its a little different, it takes your current true wind angle and targets the same angle on the opposite tack. So you can use it down wind for gybing too.
I would be interested to have a look at the log, we should be able to tell if it was trying to get all the way round and failed or if it had the wind direction wrong and succeeded in pointing in the wrong direction.
Yeah, I know how that feels, done two 14day rounds.
Interesting with Acro-tack switch. I tried it but nothing seemingly happened (I was expecting it to swop the wing tab over to the other side.
Yes, I should have a giant log file on the SD card. will tty to download it and upload somewhere.
