The Fire-Brigade-Ship era
The time came, when i left the idea with the bodyboard and turned to something more „ship-like“. A colleage of mine got the RC-model of a fire-brigade-ship on ebay. This monokeel-hull, was the new platform for the further testings. I kept the windmill-propulsion system for this ship for two reasons:
1. No trouble with water plants and algae that will clog the propeller
2. The air-propellers coming from the RC-model scene are better engineered and tuned to the motors than the ones for RC-ships.
This is a picture of the fire brigade ship before the violation.
First i ripped off all the superstructures of the ship. (The hardcore scale-model enthusiasts will kill me someday for this sacrilege).
Then i put the windmill assembly on the aft of the ship and about 1.5 kg of lead in the keel and tried this assembly with the RC. This approach seemed to be a better solution than all that fiddling-around wirth the body-board. Very stable straight-line behaviour.
Around this time i stumbled over the ARDUPILOT on the diydrones.com homepage when googling for a GPS module. I looked at the schematics and the software and one hour later i ordered the ARDUPILOT board and an EM406 GPS trough a German reseller of the SparkFun products.
Thank to god, my wife was on a wellness trip on the following weekend, so i had enough time to get the Arduino enivronment running. I took the V1.0 Software from ARDUPILOT, as a starting point, because it was simple enough to control a ship. First i got it running on the Jet-Ski Platform to prove, that it works.
And it worked! (1000 Thank-yous to Jordi, you have done a very good job!)
It was fascinating to see the little ship oscillating to one waypoint and comming right back to the shore. It was kind of an electronic water-boomerang.
If i look back to this first try, it must have been pure coincidence, that the ship managed to find the waypoints. Afterwards i found some bugs in the software and in the conception of the ship´s mechanics, that i still can hardly believe that it really worked on the first hit.
After the violation
A look inside (and on my shoes)
From now on, the really hard times started.
I moved the whole assembly to the „violated fire-brigade ship“ and tried the Software. Not bad for the beginning, the ship oscillated, but found its waypoints.
Thinking, i had the breaktrough was false at that time, but i did not realize that.
In the following i describe the setbacks and the successes.
The optimization of the PID parameters started.
Meanwhile it was plain summer and the temperatures of the lake were OK for recovery-swimming actions.
Optimizing is frustrating, but good for your body-fitness. I stopped counting the times i had to swim to the ship, that managed to crash to the shoreline on the opposite side of the lake, or to stop the motor in the middle of the lake, because my timeout-security mechanisms fired too early.
By the way, the body board turned now into a "recovery-device", which makes it easier and faster to swim if you have fins on your feet.
The project started to turn from a „Survey-the-lake-and-draw-a-map“ to a „build-a-ship-and-optimize-an-Autopilot“ one. But the journey is the reward.
The main objective was to get the ship driving a straight line from one waypoint to another. The waypoints should form the edges of a mesh to get a kind of a x/y/z grid of the lake.
The Problem was the straight line. Sometimes it was OK, sometimes not. In rare cases the ship made absolutely crazy figures on the lake, which i first supposed to be GPS malfunctions.
After a couple of weeks, the course of the ship was very stable and then i mounted the GPS-Sonar assembly on top of the ship. The NMEA output of the GPS/Sonar was stored on SD card of a Datalogger, which i bought some weeks earlier.
Here is the link of the manufacturer: http://www.engelmann-schrader.de/usbstick.html
Horror of Horrors. The ship started oscillating very heavily, the behaviour was unpredictable. If i was lucky, the waypoints were hit after loitering around some times, but often it happened, that he ship circeled around a waypoint without finding it. My swimming skills went better and better in this time. First i thought, the PID parameters had to be optimized again, but theory and practice were quite different at that time.
Inreasing the differentiator part helped a little bit but not much.
The process of optimization of the PID is very time consuming if you make it by the try-and-error method, but it was the only one that worked.
It worked like this:
#1 Driving to the lake in the early morning (before work)
#2 Starting the ship with the new parameter set.
#3 Regarding the behaviour of the ship.
#4 Sometimes swimming for the recovery of the ship.
#5 Thinking...
#6 Changing the PID parameters by reprogramming the ARDUPILOT
Restart at point #2
Go to work, think about why that f...ed ship does not behave as it should.
Discuss with colleages.
Everybody had his own theory.
„Increase P, „decrease I, no D, because it will make it unstable“
„no, no, increase D, this will make it more stable“
#7 Go back to the lake after work and restart at #2.
After three weeks i found the problem:
Very simple.
Very Very simple.
Too simple to tell.
The center of gravity has been slightly shifted to the fore by the weight of the Sonar assembly (about 1.5kg)
Shifting it 20cm more to the aft and into the ships belly cured the problem.
Then there was the black day.
On one of the test-drives, all peripherals (batteries, sonar, autopilot) were on the top of the ship, lousily attached with some sticky tape. My beloved handheld GPS (a Garmin etrex summit, which i used as a data-logger) lied on the deck without any attachment. The ship went off for some 100m and, in in a sharp turn, the battery-pack went off-board and the attached cables teared the whole ship upward down. It was pure coincidence, that the ship did not sink. The etrex summit GPS was gone, the whole electronics and the motor was under water an i broke the world record in recovery-swimming. After some hours of air-drying, the electronics still worked, even the GPS module! Only the servo was dead. Afterwards we made some dives around the waypoint, where the disaster happened, but the etrex summit was gone forever, covered by a bed of water plants.
From this time on, i kept the electronics sealed in a plastic box and the battery-pack was attached inside the ship.
One of the unlucky test-drives. The short straight line on the upper left corner is me, swimming back.
Then another failure became obvious:
The fine tuning of the PID-Parameters turned into a nightmare. Nothing behaved as it should in theory. We made tenths of test-drives with exactly the same parameters, but every time. the ship took a slightly different path. Changing the PID parameters did not really cure the problem. To see, what happened, i bought a second datalogger from SparkFun to look at the debugging-messages, we inserted into the ArduPilot code.
The link to the Sparkfun datalogger: http://www.sparkfun.com/commerce/product_info.php?products_id=8627 (very stable and well priced product)
After long research, we found some obvious errors in the PID control loop (some float to int conversions), but the main problem still persisted. Then one day, we found the cause for The strange behaviour: Sometimes, the NMEA parser yielded erroneous values on startup. So it could happen, that the course over ground value was some 50.000°, which obviously gave a very huge error, which in turn led to very high integrator startup values. This high integrator values led to an offset in the yaw-rudder values, which made it hard for the proportional part to compensate.
We have not found the error in the NMEA-parser yet, but as a workaround, we hold down the integrator value to zero for some seconds after each waypoint switch. (More of that story in a later episode).
Going better and better. The blue line is the path. the ship shall follow, the red lines are the real missions. What you can also see, is me, walking back to the car and reprogramming the Ardupilot with new PIDs.
With this final tuning, we made lots of criscross-maneuvres on the lake to collect as much depth data as possible.
Thats all for today, in the next episode i will tell something about
mission planning, data conversion and 3D vizualization.
Comments
SJ, this is the ship i am dreaming of! (more about the catamarane in one of the next episodes)
Marc, no problem, i live some 7 km away from Ulm, send me an e-mail. The lake i am using is in the vicinity. ideal for testing, because we have lots of divers there, this will be especially usefull, when recovering subs :-)
Troy, Order it!, it is worh the price:
I used the Ardupilot PCB, the EM406 GPS, which is still very accurate, anyway, the uBlox is a more recent one, but i have no experinece yet (actually sold out in Germany). Thats all!
One of my objectives was to have a system, that is solely controlled by GPS. No IMU, no Gyros.
The achievable accuracy is in the 5m Range (absolute).
You are making me excited to get an Ardupilot for my boat! One question before I start ordering stuff. What sensors are you using? GPS is obvious but is there anything else used for heading? Gyro, Magnetic?
Troy
thanks for your great report!
It seems, some people habe the same idea combining sonar and GPS... me too :-)
My approach for the vehicle is actually coming from under the water as I also built model submarines.
A mold was used to produce a body fitted with two thrusers. Tests in the bath showed that a control of direction is possible. This was done in the winter so now when it gets warm tests in a lake will follow (in case I also need to swim...)
Here is a picture of the parts:
After the manual tests, an autopilot needs to be included. After your report this could probably be ardu...
Regarding the sonar I´m using a simpler model which can be read directly by a microcontroller, the Humminbird smartcast transmitting sonar. There are some tips about using that in the net. The nice thing is the price of only 25€.
Probably we should consider meeting at a lake around here in southern germany... (maybe in the middle between Stuttgart and Ulm?)
This could also be interesting: http://www.acroname.com/examples/10071/10071.htm
Marc
I can hardly wait until Episode V...