Yep, 4.0. If your playing with the code I would recommend working off master, everything has to go via master to get in so it just saves moving the features between branches that can sometimes be a big job depending on what other stuff has changed.
1 Like
I’m working on an I2C WindVane driver so I can interface my wind instruments via Arduino (there’s no ADC on my board), and I’d like to be able to troubleshoot by observing the measured values from GCS telemetry. However, I haven’t been able to find settings on QGroundControl or APMPlanner2 to view the windvane output channel. Do you know if that is an option?
Sorry, no idea about APMPlanner ot QGC. In mission planner you can set the status to display or view a live graph via the tuning tick box.
@playertr QGC has a “mavlink inspector” view which can plot live telemetry:
APMPlanner2 can also plot mavlink streams:
2 Likes
Thank you for your responses, Mark and Pete. I got the plotter up and running.
I got a functional driver for my AS5048B I2C magnetometer, but I’m not sure that I’m handling semaphores correctly. I haven’t worked with multithreading before – should I use blocking semaphores for my I2C calls? Should I use that funky macro, WITH_SEMAPHORE?
You can view the source code I have up and running at the link below. After testing and validation, I’d love to submit a pull request to give other folks access to 0.02 degree wind resolution for $20.
Great work!
I have not done a huge amount with semaphores myself, but my understanding is you can use the WITH_SEMAPHORE macro when you enter the function, it will take the semaphore and return it when you leave the function. This means you don’t have to add the giving back the semaphore to the various places your return from the function.
Have you considered having the driver in AP_WheelEncoder, then our friends with wheels can benefit from this driver. You could have a Wheelencoder wind-vane back-end just as we have rpm and airspeed ones.
Any recommendations on where to get a encoder? I’d like to get one to play with.
1 Like
Good idea about associating this with AP_WheelEncoder. Looking at the library, it appears that WheelEncoder is used for rover odometry and therefore WheelEncoders are tasked with maintaining a cumulative running total of angular distance, which is a slightly different use case than a raw angle sensor. It looks like @rmackay9 and @peterbarker have been quite involved with AP_WheelEncoder, do you have opinions on where an AS5048B magnetic rotary position sensor driver belongs?
Pete, you can get a sensor from Digikey for $17. If you want to 3D print this compatible windvane design, then you should add two axial neodymium magnets to your order for another dollar.
2 Likes
I have just hit this error in SITL, you need co change to use Mavlink2 for your telemetry serial port protocol.
Yes, thank you - it works now 
Hi Peter
in post Sailboat Support you gave me the hint for id 168.
We have the wind sensor connected and configured as described and working great using MP.
(WindSensor-PixRacer - RadioLink - Raspbi(MavProxy) – WLAN – Laptop with MP)
Our plan is to replace MP by an App and to parse the incoming messages with our own software. We see many messages with plausible ID’s, but we do not get any message with ID 168.
We have set the stream rate (SR1_xxx) for all available messages.
Is the ID 168 somehow capsuled in an other message?
Thanks a lot
Mat
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
2 Likes
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();
1 Like
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.
1 Like
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.
2 Likes