Finally real success! I got back out there this week with a fully waterproofed servo, an added lidar sensor and a major code overhaul based on Test Flight 1's test data. Observations were:
1) Pitch control is now much better. While I still think the control loops could be better tuned, I am now getting long runs with very good pitch stability and no more porposing as you get with the wand-based systems. In lighter air, I suspect that the lack of paddle / wand drag will allow me to fly more easily as well.
2) Servo waterproofing worked great. 20 knots of wind and lots of spray and crashes and the servo never blinked. This was a big victory and only involved some grease and spray urethane.
3) There is still some servo chatter / oscillation. It is minor and doesn't affect performance much but it is bothering and inefficient. I will comb through the data and see what code changes could be made to maintain the low latency reaction while smoothing the servo reaction.
Two and a half hours of good foiling and 5.5MB of data taken. Great day out there and lots more data to pick through! In another few flights it might be time to think about the follow on to this prototype. Lighter, smaller, sleeker and more awesome!
I got out Monday for a first flight for my digital flight control system. Overall it was a big success! The one thing I cut corners on to get out there was fully waterproofing the servo. I felt that the likelihood of a turtle capsize was low (my last one was months ago). Of course, what did I do after 90 minutes out there? Turtled the boat and killed the servo--HAHA! But still a great day with lots of learning and successes:
1) Being able to "arm" the system at the press of a button was a major convenience. When the system is "not armed" it is as if the wand is all the way up and in non-foiling mode. In the armed state, the boat will try to fly at the desired altitude set point. Sailing off the dock and around the marina where you really don't want to foil is super easy. No more swimming out to the spirit to adjust ride height! Furthermore, adjusting altitude and other parameters was easy with the key fob switch. The LCD could have been easier to read, but it worked.
2) The electronics enclosure really is waterproof! After a tough turtle recovery, the electronics survived DRY after 3-4 minutes submerged in about 12 inches of water!
3) The servo is NOT as waterproof. After the same submersion the servo continued to work for another 5-10 minutes before water ingress fried the circuit board in the servo. Thankfully these are $40 parts and available with 2-day shipping. There are lots of tutorials on how to waterproof servos. I plan on doing so prior to my next flight test.
4) Control loops need tuning. Things worked out on the water but the control loops felt like they were always behind where they should have been. I can see it in my data collected and it can be seen in the videos (below). After an hour of tuning with the wireless key fob, I was starting to get close to the performance I wanted. Thinking more about the wand if it were a PID controller (Proportional, Integral, Differential), it will have a P = infinity and I = D = 0 (yes, I know I'm ignoring the mode where the wand is just fluttering on top of the water, but let's keep this simple folks). That leads me to believe, I will need to really crank up my P constant (currently set at 9.0). I think the I and D constants will be helpful for improving performance beyond the wand, but I'd like to duplicate what I have first.
5) Epic data collection! After 90 minutes of floating and foiling I have 5MB of CSV data on heel angle, pitch angle, altitude, smoothing params, PID params, acceleration in X, Y and Z axes, battery cell voltages, etc. This data will help me tune control loops on shore. My first guess at constants was made by watching our UFO videos frame-by-frame and estimating elevation and rise/sink rates. My new data is at 20ms resolution and will give me a much better shot at getting things very close on shore before I head out next!
6) Battery life will NOT be an issue. After 1.5 hours of foiling I had better than 85% of the battery left. On prototype #2 I will definitely go with a smaller battery to cut costs and reduce size / weight). Either way, I have hard numbers on cell voltages vs. time and will accurately be able to calculate how much battery capacity will give me how much time on the water.
7) I need a hard-reset switch on the boat. The ultrasonic altimeter I am using is a cheap one from a car bumper. Occasionally it gets noisy and needs a reset. Having a way to do a full power cycle on the water short of taking the lid off the enclosure would make resetting the altimeter easier. In the long run, I will be looking for a higher reliability part for prototype 2.
Electronics module and servo now fully mounted on spirit and actuating the flap with torque to spare! First flight in mid June is on track! Last steps are some linkage adjustments and test tank time (in my hot tub)!
Another update from the land of digital flight control systems!
I now have all sensors talking to the Grand Central board and the algorithms (PID loop, ultrasonic sensor filter and smoothing, etc.) performing as designed. The wireless remote is also working and allowing the user to adjust PID Parameters, Altitude Setpoint, and Smoothing coefficients. The LCD is putting out status messages and feedback when the user is changing parameters. I am also collecting all the data from accelerometers, gyros, ultrasonic sensor, battery cell voltages, etc. and storing it to an SD card (sample data and charts below). The data gathering ability will be a major feature in itself. We will really get to be data-driven about what sorts of tunings make the boat go fast. For example, comparing nose up vs. nose down pitch angle, fastest ride height for different points of sail, etc.
A simple battery management system is also now working indicating battery State of Charge as well as cutting off power to the servo when the battery gets too low to avoid damage to the cells.
Last, the integrated PCB and battery have been installed into the waterproof housing and a gland has been installed to allow for a waterproof cable passthrough.
I am planning on doing some more testing of the integrated system in the “test tank” (aka my hot tub with the jets going). I may throw my 5-year-old in there and tell him to do some cannonballs. The goal is to ensure that the ultrasonic sensor is reading turbulent water well and that the default IIR smoothing filter settings are correct. In particular, the smoothing needs to be set to smooth water ripple and wake without paying too bit a price in lag. The smoothing coefficient is tunable using the wireless remote so the goal here is just to get the default setting close. Final tuning can be done out on the water.
A lot of progress for 6 weeks.
The other fun side-project is analyzing data from all of the sensors and graphing things. I am able to gather data every 10ms which gives very good granularity. Currently I am collecting the following data fields:
1) Raw ultrasonic range sensor altitude (cm)
2) Filtered ultrasonic range sensor altitude (cm)
3) Smoothed ultrasonic range sensor altitude (cm)
4) Vertical acceleration (m / s*s)
5) Heel Angle (degrees)
6) Roll Angle (degrees)
7) Commanded servo position (0-100%)*
8) Battery cell 1 voltage (Volts)
9) Battery cell 2 voltage (Volts)
*Rotary servo position (0-180 degrees) is converted in software to linear servo position using the proper trigonometric functions. In the code, the servo is commanded between zero- and one-hundred percent representing percent of total linear throw.
I have attached some screenshots from excel where you can see the value of visualizing the data and how different filtering techniques and filter combinations affect altitude readings. Great to see that the outlier rejection (orange line) and IIR smoothing (gray line) are doing what they are supposed to do!
I am also curious as to how fast the battery drains during foiling and monitoring cell voltages should give me a good picture of battery life.
I have also purchased Clickbond studs which will be bonded to the sprit. The mounting plate will then be screwed on to the Clickbond studs. The mounting plate still needs to be designed but it should be pretty straight forward. It will hold the enclosure, and mount the waterproof servo and ultrasonic range sensor. I am currently experimenting with perforated aluminum as it is strong and easy to work.
My last step is designing the linkage to mate the servo to the existing flap control rod. Thankfully, there is already a bell crank on the sprit. I will not use the existing bell crank because it is not shaped correctly for my purposes, but I will use its pivot pin. I have to do the calculations to determine the correct length of each side of the bell crank to ensure the mechanical advantage and throw are correct. Additionally, I need to measure the total actuation length of the flap. Time to get out the calipers.
Until next time, stay flying.....
Good news! I just received PCBs back from the fab house and all parts fit. This simply means I know how to be very detail-oriented with a pair of calipers and my CAD software. I mentioned in a previous post that mounting all of the modules to a single PCB was easier and more electrically sound than using a "base plate and flying wire" approach. The PCBs are back and everything fits mechanically.
As you can see from the photo, I have added 0805 inline footprints on every trace. The idea here is that if the trace is correct, I install a zero-ohm resistor and carry on. If a trace ends up being incorrectly connected (because of a design or fab error) there is no need to break out the razor blade and cut PCB traces, just wire up some jumpers to the 0805 pads and connect correctly. Hopefully everything goes smoothly....
Electrical checkouts have gone well and no issues with power or ground planes were found. I have started soldering parts to the PCB and am about half way done with the full assembly. The next step is to run software with all modules integrated into the PCB and running on battery power (as opposed to power supply or USB power). The integrated PCB will look like a stack up of boards, so I plan on referring to it as "the stack." I'm looking forward to seeing all these modules work and play together!
First flight could happen this spring!
A few more updates on the project with the selection of a servo and battery.
I decided to actually measured the torque required to actuate the flap. I did my measurement out of the water and therefore I only measured the resistance of the linkage and the resistance of the rubber "spring" that mates the foil flap to the mainfoil. I did the measurement using a pull scale attached to the wand 6 inches from the pivot point of the wand. I found the required torque to be ~32 oz. at 6 inches -- or 192 in-oz's. Converting this to kg-cm which is how servos are spec'd, we are looking at 13.8 kg-cm for the linkage and rubber "spring" resistance. Note: I did this experiment without the paracord attached as it will not be necessary once the servo and linkage is installed.
As discussed earlier, determining the amount of force imparted by water rushing past the flap is a complex fluid dynamics problem however there are several great calculators for RC aircraft servos online. I used the one at the link below:
I had to make a few assumptions regarding servo deflection as I have not fully designed the linkage but all results were within a pretty tight range. If we were foiling through air we would need ~0.2 oz-in of torque to operate our flap at 18 knots airspeed. Given that water is ~825 times as dense as air, I will assume we need to multiply by 825 to get 165 oz-in of torque in addition to the 192 oz-in to overcome the rubber spring force. This gives us ~356 oz-in required or 25.6 kg-cm.
Therefore, our total theoretical torque required to actuate the flap will be 25.6 kg-cm.
The other feature we will need is self-locking. Looking at my GPS logs, even on high wind days, I am spending about a third of my time not on the foils. On lighter days, it can be over fifty percent. During this time, the main foil flap is at max lift when the boat is moving forward and the wand is being pushed back. This does add more drag but allows the boat to enter foil-assisted planing modes. But having to provide constant servo torque even when not foiling will likely kill the battery pretty quickly and seems wasteful.
To be on the safe side, I have selected a 32 kg-cm part that has metal gears and is self locking. Some waterproofing will need to be done but there are countless tutorials on how to do this online. This part should have plenty of torque to actuate the foil flap and the self locking feature will save battery juice.
With all parts now chosen, it's time to choose a battery that will meet our needs. As the battery is likely to be the physically largest component of the system, the battery size will drive the enclosure sizing as well. My power budget is below and the result looks ugly!
Servo (Stall Current)
2S LiPo Operating V
The largest 2S RC battery I could find was 8Ah max. There are bigger batteries out there but options are few. The 800 pound gorilla in the room is the servo. While we might be able to get away with a smaller servo, having the torque headroom makes me feel much better especially on a prototype. Not to mention that worm gear, locking servos aren't too common so choices are limited. A linear actuator might also be an option but they typically respond much slower than rotary servos and are heavy and expensive--I will do some research in this area.
The other design difficulty if we try to mimic the current mechanical system, is that even while not trying to foil, we will constantly be using servo torque / battery power just to fight the flap's rubber "spring" to max out flap deflection on the main foil. Soooo.....this leads me back to insisting on a self-locking servo so that we aren't using battery charge to max out flap deflection even when in irons.
If a suitable self-locking servo was not able to be identified another options is to use a GPS to determine boat speed over ground and assume that it is equal to boatspeed through the water. Yes, I know that doesn't take ocean current into account, but I think it's a small price to pay right now to extend battery life. Ocean current could be taken into account at a later date with tide charts built into the firmware as well as heading data from the GPS or IMU. We could also implement a button on the tiller extension that allowed the sailor to activate the foiling system when ready to fly. My worry with a button is placement and wiring / cable harness. Any thoughts here from the peanut gallery?
If we limit current draw to the servo until we are actually trying to foil, an 8Ah standard battery will give us about 90 minutes of foiling time under (close to) worst case power draw. I would still like to see more battery life, but 90 minutes of time actually on the foils is quite a bit. Hopefully, real world testing will tell us that we don't use as much power and can get closer to 2 hours of foiling time--we'll see.
Sampling and Filtering of Ultrasonic Sensor:
While out foiling a few days back it occured to me that simply using the sonar to look at current elevation is not really what we want. We want to know what the "average" elevation is over a ~1m stretch of water. This reduces the effect of wavelets or even small boat wake (big boat wake is a different story). The other thing we need to be cautious of is false readings. When looking at the sonar sensor output, I occasionally see 0.0cm readings. Clearly, these erroneous readings need to be filtered. As a result, I have decided to take 5 samples over a 1m distance (assuming 12 knots of boatspeed). My code then takes the median value. This mid-level vote (MLV) system comes close to the average of the readings and automatically eliminates outliers. MLV systems are often used in redundant aircraft altimeters for this very reason. The code is pretty flexible and if sample size or sample frequency needs to be updated it is not hard.
Last thought of the post: we will probably need some data logging for the prototype phase. Specifically, it will be useful to understand the delay between commanding a deflection on the foil flap and seeing the boat actually pitch up. Understanding control loop delay will really help in tuning PID loops and eventually allow testing of algorithms to deal with more complex and challenging wave terrain. I have put zero thought energy into how to implement the data logger, but it needs to be on the tech roadmap. Thoughts?
Time for another blog installment of the Digital Flight Control System for my UFO. I have been busy at work on the project and making good progress toward a first flight in early 2020! Also attached is an updated block diagram with details on various subjects below:
In my last blog post I mentioned that we needed some sort of data logging to really get into the meat of how well our control and filter algorithms are working. Post processing data after getting off the water will also allow us to see if there is data being generated by sensors that could improve control. For example, I received a suggestion that I take vertical acceleration from the IMU into consideration and use it to derive vertical position. This vertical position would then be fed into a Kalman filter along with the ultrasonic range sensor's vertical position measurements to determine a better estimate for boat altitude. Logging and crunching data after getting off the water would allow us to take these types of ideas into consideration easily. Datalogging would also greatly improve troubleshooting of all types. To this end, I have added an 8GB micro SD card to the design as well as written some simple code to log data to a CSV file for post processing. My current code logs speed (GPS), acceleration (XYZ axes), attitude (XYZ planes), and servo control input. Any other thoughts on datalogger inputs?
PID Loop Tuning:
It has also occurred to me that tuning PID loops while on the water will not be possible with a laptop. As such, I have integrated a wireless, 4-button, key fob (in a waterproof bag), a wireless receiver and an LCD screen. This will allow for wireless adjustment of PID constants and LCD feedback to the user. This setup should allow for easy adjustment while out on the water between foiling runs. The enclosure chosen also has a clear plastic top to make reading the LCD screen possible.
Mounting, Wiring and Power Distribution:
The Arduino board I am using only has so many pin outputs for 3.3V and 5V. While my sensors easily fall within the max current output of the board, I am short on pin space. I also have a 3D model of the enclosure that requires at least one mounting plate made from plastic / metal / fiberglass / FR-4. It occurred to me that rather than mess with mounting plates and a wiring rat's nest, I should just burn a simple PCB to handle mounting and power distribution. This PCB may also contain some custom circuitry--we'll see. The PCB will minimize the wiring mess and be a mounting plate in one shot. Many PCB shops will burn custom sized, one-off boards for ~$150. It's probably a small price to pay for much better reliability and maintainability (not to mention the time saved on creating a mounting plate(s) and hand wiring all of the modules).
Now that I have selected a battery (2S LiFePo, 8000mAh) and all other components, I created a 3D CAD model of how the boards will lay into an enclosure. It appears that a 4x6 inch case will fit everything we need to hold the system (see photo of selected case). This enclosure will mount onto a mounting plate (probably custom fiberglass or carbon fiber) that will bolt on to click bond studs bonded to the spirit. The servo and ultra sonic sensors (both waterproof) will live outside of the case and be mounted to features on the mounting plate. This section of the design is the most open at the moment and will certainly require more CAD work.
That's all for now. Comments are welcome!
With much of the code and working and sensors talking to my Arduino board, it was time for some real world testing this past weekend. I always try to find as much information online regarding sensor characteristics or what has worked for others, but at some point there is no substitute for empirical data.
At the heart of the feedback loop is our ability to measure altitude. We will be measuring altitude with a waterproof sonar sensor similar to those used in automotive bumpers. There is lots of data online about sensing all sorts of items including still / non-turbulent water. There is very little data online however, about the sensor's ability to accurately measure range to turbulent water. Not wanting to take my laptop out on the UFO for a live test, I decided to use my hot tub (jets going full throttle) to simulate very turbulent, moving water like we might see on a rough day on a UFO.
The results were good news / bad news. The good news was that the sensor seemed totally unbothered by the turbulent water (vs. flat water). The bad news is that the sensor's ability to give accurate readings drops off a cliff as the sensor becomes off perpendicular from the turbulent water. Some of this can be solved with filtering and throwing out values that are clearly nonsensical on the high or low side. But reality is that we will need multiple sensors mounted at different roll angles. We will then choose which one to read based on the heel angle of the boat. Luckily, we have a good IMU on board with accel's and gyro's that should help us pick.
I chose three sensors based on a +/-20 degree field of regard for the sensors and a max roll angle of +/-30 degrees for the UFO based on boat dimensions and a 1m ride height. Additionally, if the altitude sensor function in the code does not return a sensical value, I will have the PID loop operate under the assumption that elevation is unchanged or perhaps just max out flap camber. Typically, when heeled to windward, you want all the lift you can get and if you are heeled far to leeward you need to bring the boat back down off the foils and start over anyway.
Last thought, if the multi-sonar sensor approach seems too impractical a radar or laser/optical altimeter could also be used. These sensors are more expensive but tend to have much wider fields of regard. There are a few available with good documentation for Arduino and that operate at K or Ka band. X-band is impractical as GPS carrier signals are in the X-band and we may run into RF co-existence / self-jamming issues (should a GPS ultimately be necessary). As a bonus we could use a doppler radar / lidar to also get boat speed through water.
Thanks for reading!
Another quick update,
A productive weekend ended up with an IMU (BNO055) and a waterproof sonar range sensor (JSN-SR04T) being integrated to my Arduino Mega board. Both are yielding good data and easy to work with. I also am able to write commands successfully to a spare servo I from an RC Tricopter. I am still in the process of selecting the correct servo and identifying the correct attachment point(s) for the servo to flap linkage (please see and comment on servo math below).
Additionally, I now have a PID library running giving servo commands based on the measured elevation. Tuning the loop gains will take some tweaking and I am beginning to realize a few buttons and a display of some sort may be necessary. I am trying to avoid scope creep but tuning control loops will most certainly need to be done on the water and doing so on a laptop will not be possible. More fun to come on UX...
Lastly, it's time to think about packaging and power. The whole system runs on 5V and would be easy to power off of a set of AA or C cells. Eventually a lithium battery would work well and be rechargeable. I may need to add a power distribution board as the Arduino Mega won't provide enough current for the servo I am guessing. We'll see once the servo is selected.
Servo Math Section
Speaking of servos, my thinking here is to calculate how much torque is being imparted by the wand and using that as a minimum value required for servo torque. Being conservative my math is as follows:
Calculate force on paddle:
F = ma from Newton
Paddle will push flap down at minimum boat speed of about 3 knots or 1.55 m/s -- below that boat speed the flap rebound spring overwhelms the paddle drag.
Therefore paddle must accelerate oncoming water from 0 m/s to 1.55 m/s. I am going to assume that this acceleration takes place over the course of 0.2 seconds. I have no scientific basis for this duration of acceleration. In reality this is probably a very complex fluid dynamics problem, but I think 0.2 seconds is a safe and conservative number.
Therefore a = (1.55 m / s) / 0.2s = 7.75 m / s^2
The paddle is around 4 square inches (~2 x 2 inches). (The wand also provides some drag that we will ignore for simplicity -- hopefully this isn't fatal =) Assuming that the amount of water accelerated from 0 knots to 3 knots is 4 square inches and 1 inch deep (yes another assumption), we have a total volume of water decelerated of 4 cubic inches or 65.5 cm^3 or 6.55e-5 m^3.
The density of luke warm seawater is nominally 1027 kg / m^3. Therefore
m = 6.55e-5 m^3 * 1027 kg / m^3 = 0.06726kg
Putting it all together total minimum force on the paddle to push the flap down is: F = ma = 0.06726 kg * (7.75 m / s^2) = 0.52 Newtons
To be clear, this is the minimum force it takes to push the flap down when traveling slowly. As speed increases, it will take more force to actuate the wing as the speed of the water rushing by the wing is faster and will increase resistance to movement. Not to fear however, we can use the same approach to calculate the torque imparted on the wing by the paddle at higher speeds by varying a. At 18 knots (about as fast as my GPS has ever recorded me traveling) and assuming acceleration takes place over 0.2 s, our formula becomes
F = ma = 0.06726 kg * 46.3 m / s^2 = 3.1 Newtons 18 knots = 9.26 m / s ; (9.26 m / s) / (0.2s) = 46.3 m / s^2
Putting it all together to get torque, I assume that we are operating on the end of a 1m arm (our wand length). Therefore our torque values would be between 0.52 N-m and 3.1 N-m.
A few caveats -- I made a lot of assumptions here and tried to be conservative. I also notice that at high foiling speeds (18 knots) the paddle depresses the flap with extreme ease indicating that while it imparts 3.1 N-m, a far smaller value would be sufficient.
The last consideration comes with how to mount the servo and how many meters of moment arm we will use. I am thinking the servo will be mounted close to the fulcrum therefore our moment arm will likely be 0.2 m or similar. Therefore torque will need to increase by a factor of 5 to deal with the fact we only have a fifth the lever arm as the paddle.
With all this math out of the way, I want to say that I am not a fluid dynamics or mechanics expert. I intend to take some empirical measurements next time I'm out foiling to verify my math. Please check my work and shoot holes in it wherever possible.
Ok team, here goes my first blog post. My goal here is to build a Digital Flight Control System (DFCS) for my UFO using a sonar range sensor as opposed to the wand. The design needs to completely mimic the performance of the wand system currently in the boat. The system needs to be fully removable to allow for One Design Racing if desired.
A few design guidelines...
Improvements to current control system:
1) Sensing wave terrain out ahead of the boat
2) Not engaging the mainfoil flap until the boatspeed hits 7 knots to reduce drag while floating
3) Toggle settings for upwind vs. downwind (maybe a button press?)
4) Data acquisition
5) Auto rear foil rake adjustment (this is a maybe feature, this would be lots of extra hardware for limited improvement)
Questions to answer:
1) Do I need a GPS to get good boat speed or is the accel, gyro, magnetometer IMS good enough?
2) How and where will I couple the servo to the flap control push rod
3) How big a challenge will marinization be? Is enough to buy waterproof parts and a waterproof box?
4) Is it useful to have more than two sonar sensors to create an accurate map of oncoming wave motion? Does wave motion traveling orthogonal to the direction of the boat matter? Or are waves going so slow compared to the speed of the boat that it doesn't matter?
I will endeavour to use parts that have excellent tutorials available online.
I will be concerned about the cost of my time even when it costs a bit more money to buy parts that are easier to integrate.
Basic Block Diagram Below: