Harald Molle's Posts

Ardupilot goes into the water Part 17

Posted by Harald Molle on August 22, 2011 at 7:07am

Some of you may wonder.

Why was there such so long silence ?

Indeed, my last entry dates back to last christmas. And here is the reason why:

http://www.apress.com/9781430231837

I was asked by JD Warren, who is also a diydrones member ( http://diydrones.com/profile/JDWarren ) to help him on a book about Arduino-controlled robots.

JD is a great inventor and maker of various machines that (mostly) roll on wheels. He was also featured on the title of the MAKE magazine in April 2010.
Finally, with a delay of six months, the book was published by mid July and JD, Josh and i are happy now that all the work is over.
If you want things to be moved with Arduino, this is the ultimate Book.

There are lots of hands-on descriptions in it and it is also a good starting point for newbies, that have never had a soldering iron in their hand.It gives also a good introduction to the basics of electronics and computerized control.

Here is an overview of some of the chapters:

Basics of motor-control
Basics of PCB design and fabrication
R/C control and decoding
Autonomous sensor guidance
Frame building from various materials
Instructions for a variety of robot designs, including:

Linus the Line Bot, who follows a line on the floor
Wally the Wall-Bot, who tries to avoid crashing to the wall
The Bug-Bot, who acts a little bit like an insect
The Explorer-Bot, who is strong enough to carry a human and that can work outdoors
The RoboBoat, which is navigating via GPS to predefined waypoints. (this is in fact the chapter written by me and summarizes the building of the catamaran, and the modified ArduPilot hardware that i am using to do the survey of lakes)
The Lawn-Bot 400, who is the first that can do something useful in your garden
The Seg-Bot, which is in truth not a robot, but a Segway (tm) Clone
And finally: the Battle-Bot

The book is available as e-book or in a printed version:
http://www.apress.com/9781430231837 or

http://www.amazon.com/Arduino-Robotics-John-David-Warren/dp/1430231831/ref=sr_1_1?ie=UTF8&qid=1314021806&sr=8-1

Ardupilot goes into the water Part 16 -- X-MAS Special --

Posted by Harald Molle on December 26, 2010 at 10:00am

Criminals often come back to the place of the crime scene. Divers too.

Maybe some of you remember the starting of this blog. In Episode 1, the project started on a small mountain lake in the south-tyrolian Alps more than two years ago. End of september this year we went back to this place to go diving and to survey this lake with better equipment than we had used when we went there for the first time. The this year crew consisted of three persons:

Bernhard, Hermes and me. Thanks to the boss of the local fishing club, this year, we had a permission to drive to the "base" camp, which is situated at the end of a valley in 1800m above sea level. Two years ago, we also went there, but without a permission, there is still some thrill in the air...

So, we started on thursday afternoon to a 5hour trip across the alps with roughly 300 kg of equipment with us.

We arrived at the base camp in the evening and were welcomed by the host of a small alpine bar - Konrad-. We knew him from the last trip, when he managed to fill us up with some kind of a local brandy, that left deep impressions in our brains and livers. This year i was aware of that and stopped at glass #2. Sometimes it is hard to say no, but "failure tells a man how to succeed".

The next morning we prepared for the first ascend to the first lake, which is some 400m above the base camp.

Bernhard, the boat-sherpa

Diving is not really a sport in terms of power, endurance as other sports are - preparing to dive is!

The sunday before, i ran my first marathon and had still some muscles that remembered me on some points of this 42km journey. Anyway, we started the ascend with roughly 20kg per person in our backpacks. We arrived one hour later at the first lake more dead than alive. 2300m above seal level can be really challenging, when no sherpa blood is running through your veins.

The recovery went amazingly fast, maybe by the help of some amount of beer, we carried with us. Arrived on the lake, we assembled the catamarane and first did a "manual" survey to get the outline of the lake. For that purpose, Hermes swam around the lake with a body-board and carried the catamarane and the GPS-sonar behind him.

Hermes, swimming, with the boat

In the meanwhile, i prepared the mission for the ArduPilot. The correlation between the measured shoreline and the Google-Earth data showed, that there was nearly no difference.

The path for the ArduPilot was quickly drawn, converted and downloaded to the ArduPilot.

Launch!

The point of no return

Where the hell does the ship go?

This was the first question we asked, when the boat went off-shore. The path was something like "reversed", but the boat did its job well and after 30 minutes it stoppped the motor - on the opposite side of the lake! -

Fortunately, it stopped in shallow water, and the recovery was done by wading and not by swimming.

What had happened?

I used Google Earth to draw the path for the boat and the map was oriented north-up. Because i am not really a genius in orientation, i managed to draw the path in the wrong direction. The start was located on the north-end of the lake and i thought we were on the south-end. Anyway, the boat did its job and this time i was not the one to recover the boat!

After this (nearly) perfect survey, we took all the stuff to 2500m above sea level to the second lake, which is much smaller than the first one. The weather got worse and the temperatures went down to nearly the freezing point. This time we did no pre-survey and took the shoreline data directly from Google Earth.

Hacking on 2500m ASL , the servo and me, -shivering-

The only thing that made me nervous, was the fact, that the rudder servo shivered heavily, when at standstill. I thought, that there was a loose contact somewhere in the wiring. What to do, when you are at 2500m and you have no tools with you? -Nothing-

So i decided to launch the boat and luck was on my side. It paved its way perfectly and came back to the starting point. It went so good, that i decided to make a second round. Also absolutely perfect. Later analysis showed, that the servo i have used had trouble with low temperatures. Now i use a digital type and this one works also at temperatures below the freezing point. The weather went worse and so we decided to bring all the survey equipment down to the base camp. After a short stop there, we took our backpacks and went back up to the lake, this time with the diving equipment. The plan was to deposit the tanks and all the other heavy stuff on the lake and go further up to an alpine cabin, which should be our second base camp for the night. We arrived there in the night, totally exhausted, but happy. After some plastic cups of beer and some eating we felt into a deep and dreamless sleep. The weather forecast announced rain and i was happy not to hear any raindrops on the rooftop. Sometimes the forecasts are wrong -good-. Early in the next morning i opened the door and then i suddenly realized, why i heard no raindrops...

The whole area was covered with a 30cm thick layer of snow.

A winter-wonderland

This fact put an early end to our dive mission on this day... and this year.

So we took all our bearings and went down to the lake, where we have deposited the equipment. Where the hell has Hermes put the tanks, the regulators and the weightbelts? It took us half an hour to find the place under the snow.

The diving equipment - finally recovered-

After that intermezzo, the sun came out and we had an excellent descent down to the base camp in a bizarre winter environment.

Down on earth, i did a lot of DrDepth-ing and produced this nice pictures from the lake:

The path on Lake #1

.. And the result from Dr.Depth

And in 3D

Lake #2

I have put the Google-earth .KMZ files of the two lakes here:

Seefelsdsee_1.kmz

Seefeldsee2.kmz

That was all for this year so far..

Winter started early and all the lakes in the vicinity are frozen.

Much time for preparing new projects with ArduPilot...

Stay tuned...

Ardupilot goes into the water Part 15

Posted by Harald Molle on November 4, 2010 at 1:00pm

The older you get, the less time you have..

This episode dates back to august of this year, but there are so much projects out, that i can hardly find some time to write.

As mentioned earlier, the project turned from a sea survey one, to a shipbuilding one.

For the ones, that have been waiting for new Dr. Depth pictures i have good news:

A new lake and the story:

After having surveyed my good old diving lake to nearly all of its extents, and haven´t found the 6000m abyss, a new one should be on the list. A friend of mine, is a red-cross volunteer, who is working in his free time as a rescue swimmer on a nearby lake. (there are no familiar relationships to David Hasselhoff - i swear).

So, on one evening of the less rainy days in august, we went to that lake to try out, how the workflow on a new lake would be.

Mission planning by Google-Earth was not directly possible, because the database of GE dated back to 1999. And until now, the lake has received some "modifications" in the form of some pontons and a pier. To avoid unwanted encounters with those objects, we first had to do a pre-survey. For that, we took two kajaks and fixed the catamarane on one of them with a string. With that configuration we made one tour around the lake with little standoff to the shoreline to get the outline of the lake. Then we surrounded the swimming pontons, the pier and the small island in the middle of the lake.

The sampled data was then converted and imported to Google-Earth via KML and then a path of the mission was drawn.
On the early next morning, we went back to the lake with the prepared mission on the ArduPilot.
To keep the adrenaline level low, we decided to follow the boat with the kajaks. A really relaxed survey!
It is nice to see, how the boat behaves when you can follow it on the water! A totally new perspective. All went fine, no crashes and the ship found its path back to the shore after a 30 minute trip. The straight-line behaviour could have been better, but anyway, the measured depth values were more than OK.

The total time spent for this survey mission was less than 5 hours.

And this is the result, that was produced by DrDepth:

Still amazing, what this program produces with not much data.

The KMZ file can be found here:

Schuetzensee_Elchingen.kmz

Next on this blog:

Ardupilot goes into water, episode one -reloaded-
The return to the mountain-lakes.

Stay tuned...

Ardupilot goes into the water Part 14

Posted by Harald Molle on October 8, 2010 at 3:30pm

What happened to the boat and the lake ?

Not really much, there seems to be a kind of stagnation in the air...

I tried the radio-control on the boat several times, but found out, that this is not the solution to the swimming recovery problem. Several reasons for that:

The first try ended up in wading through the mud and recovering the boat, that managed to get stuck in some roots on the shoreline. I tried to get the boat managed by RC, but the diameter of the turn was too big to get it right back to the point, where i have started.

Why that?

The turn diameters were OK, when running in AP-mode.

Seems, that the RC outputs servo pulses only for +- 45 degrees.

The AP can output pulses for up to +- 90 degrees.

To cope for that, i modified the rudder-horn steering to its largest extends so that there was more "angle".

With this modification, the AP still worked and the RC-control of the boat was also possible.

Second, the ESC i am using, can only drive the motor in one direction. So, when the boat gets stuck on the shoreline, there is now way to get the boat shifted into reverse.

The only way to rescue the boat is: still swimming.

Third, adding more technology onto the boat´s electronics makes it more prone to errors than before.

For that reasons (and for the thrill) i decided to dismantle all the RC stuff and turned back to the "old" configuration.

I kept the RC equipment to start some crash-flying experiments with an EASYSTAR, but this is another story...

Some days later, i went back to the lake to do some "long-leg" measurements, to see, how the control loop

behaves on a long trip. (a 400m straight line path and a 180° turn).

The first run was OK.

On the second one, the boat made some weird turns on the opposite end of the lake and crashed into the shoreline, mowing away some reed, until the propeller gets stopped by something hard.

Swimming...

Walking back on the shoreline with the boat in my arms, giving comments to the russian fisherman....

What happened?

It was a windy day and maybe the boat had trouble, moving against the wind, the speed went down and the GPS did not output valid direction data.

This must have been the reason!

I tried again some days later, when it was absolutely still air.

The first run was OK.

The second one...

see above.

This time, the propeller milled away some tupperware housing and the servo had shifted the windmill assembly into an extreme 90° position.

Post mortem analysis of the GPS and control loop outputs showed, that the AP behaved absolutely correct.

hmmm...

thinking...

Bingo!

The following picture shows, what happened:

The Rudder Horn steering was still at its extreme positions, that i had used for the RC experiments. And, in some situations (e.g. a full 180° turn) it could happen that the steering rod acted as a "piston" as we have in internal combustion engines. The assembly kept stuck in a 90°+ position.

So it was no wonder, that the boat made some weird turns.

Next, i reduced the angle of the steering and introduced a "push-pull" assembly with two steering rods.

That was it!

Absolutely perfect straight line behaviour. No stalls, no further swimming.

The world was perfect again...

Not absolutely perfect.

The mounting position of the sonar transducer was still something that should be enhanced. Too much drag, too much irritation.

So i mounted the transducer into the right hull.

I expected a faster boat after that modification, but the inrease of speed was neglegtible compared to the the "old" configuration. Anyway, the boat glides much smoother trough the water and there is no more chance for water plants to hook into the transducer.

In the next episode:

A new lake and new Dr Depth pictures....

Ardupilot goes into the water Part 13

Posted by Harald Molle on September 9, 2010 at 1:04pm

Long time - no sea.

If anybody will tell me about global warming - i will kill him!

We had the coldest (and rainiest) may and june ever.

And August was - the rainiest ever.

Globalization only seems to work in the financial domain, but not for the weather. What about a "weather-transfer" of bad weather to the sahara? They will appreciate the rain there. Despite this fact and the passing away of a close relative, i wished, these months had never happened.

In mid-july, we have seen that this spherical fusion-reactor some eight light-minutes away is still running. I am personally not a fan of nuclear energy, but in this case...

What happened since my last entry?

Not really much.

The new cat has now the same color on both hulls.

The board, that holds the hulls together is now coated with fiber and epoxy to make it more rigid.

The extra battery for the sonar was dropped. The power comes now from the main battery. (-300g of weight)

The cable from the sonar to the transducer was shortened (-100g)

This was really not much, but there are still some challenges out there...

Swimming is not one of my favourite disciplines.

Swimming in bad weather conditions does not even make it better.

Swimming is OK, considering the following conditions:

1. It is summer (I mean that season, when it should be really warm)

2. You have enough time to put on your swimming suit, when the boat starts to react weird.

3. You love swimming

4. No rain

if any of the above is not applicable, staying on the shoreline is the better option.

Swimming is usually caused by:

1. Software

2. Mechanics and Hardware

3. Personal idiocy

4. A combination of the above

To prepare the this year "PID optimization campaign" i decided, to reduce my recovery-swimming exercises to a minimum and thought about Radio Control.

First, i fiddled with my 27MHz RC control from the Jetski model, but found out that this thing is abolutely crappy. Bad range performance, noisy and most of all: no failsafe behaviour. I wanted the software on the ardupilot to decide, whether there is a transmitter controlling the ship or not. And therefore i have to measure the pulses comming out of the Receiver. So far so good, but the 27MHz Rx outputs always some pulses, regardless, if the Tx is on or off (the good old analog era...).

I remembered, that the Ardupilot was originally conceived as a fail-safe

system with an RC option as a fallback for the safe launching and landing

of an airframe.

Why not using this feature for the boat?

Reading the docs and the software showed, that the implementation, which is

in the original version of the Ardupilot was not exactly what i needed.

My requirements were:

1. If the transmitter is OFF or the Receiver is out of reach, the boat shall

be fully controlled by the Ardupilot.

2. If the Transmitter is ON, control shall be passed to the Radio control.

Implementation on the original version was a little bit different,

so i decided to do it my own way.

How to detect if the RF is good or bad?

The only way is to look at the servo pulses, that come out of the Receiver.

Analog RC Systems output always something on the servo channels, even when the Tx is OFF. (see above)

Discrimination between noise and a good signal would be possible by some weird SW algorithms, but i wanted to keep it simple.

A very old friend of mine, who is an RC Dinosaur told me to buy a 2.4GHz RC control.

So i ordered a SPEKTRUM DX5e, which is a fairly priced entry level model.

Reading the manual showed, that the failsafe functionality of the receiver was exactly that what

i needed. Manuals sometimes do not tell the truth, so i oscillographed the servo outputs and found, that

they really told the truth:

1. When the receiver is turned ON without a Transmitter beeing in the air, there is silence on all servo outputs - good.

2. When the Tx is turned ON and the Rx is correctly bound to the Tx, pulses on all channels - good.

3. When the Tx is switched OFF, silence on all channels, but not on the throttle. The throttle channel outputs a pre-programmed default pulse-width. - still good.

From the software point of view, it is very easy to distinguish between silence and "something". So i took the rudder channel to sense the RF.

(Tx ON --> pulses, Tx OFF --> silence)

Technically, all worked fine.

right in the middle: the Receiver.

I have put the code here:

Ardupilot_water_RC.zip

Please note, that the Hardware of the Ardupilot board has to be

modified!

Read the comments in the RC_Control tab.

I have refactured some of the code and added some comments.

WITHOUT testing it. Take the code as a starting point for your own

experiments.

Thats all for today, on the next episode i will tell the experience with the RC control on the lake and why i decided not to use the RC any more.

ardupilot goes into the water Part 12

Posted by Harald Molle on May 8, 2010 at 10:00am

What a week!

Rain, Rain, Rain and sometimes... Rain.

Not a good week for a launch.

Today was the first day to get a glimpse of the sun behind the clouds. So i used the chance for a video session and in depth testing of the new Catamarane hull (with the fins).

I tried various speeds, various payloads and various tracks to see if the new platform is stable.

It was!

1. A new speed-record with 10km/h (running with 8A and a 500g Li Battery-Pack)

2. The big battery-pack with about 1.5kg weight was also OK and had only a slight impact on the speed (about 1km/h slower). With that pack, the endurance of the ship will be around three hours with one charge.

(running with about 5A and a speed of about 6-7 km/h).

3. The straight-line stability on long runs was also OK, but still has some optimization potential.

After that runs, i had enough courage to mount my beloved Sony DigiCam (a DCR P100) with some gaffer-tape on the ship. I made two runs, the first with the cam attached to the front and the second with the cam attached to the aft. The aft-footage gives a nice look, how the ardupilot is controlling the yaw-servo.

All went well.

Despite the fact that the ship had a near-accident with one of the diving teachers of our club, who managed to surface at exactly the moment, i launched the ship.

Maybe we can make a bet, how much lawsuits for "malicious injury" i will have collected until the end of the year.

I have put the footage of some runs here:

ardupilot goes into the water Part 11

Posted by Harald Molle on May 1, 2010 at 8:55am

The Start of the 2010 swimming exercises.

All told about the hardware...

All told about the software...

What´s next?

10A @11.5V for a speed of 5.6 km/h is lousy. The same speed with 5.0A would be OK. This benchmark was set by the Firebrigade-ship, but the catamarane had a much better straight-line behaviour.

OK, let´s improve the catamarane...

In the long winter evenings i googled a lot about catamaranes. Somebody had posted a comparison between different hull shapes / cross-sections. The one with the triangular cross-section as i was using, proved to be the worst in terms of drag. But it was the best in terms of straight-line behaviour and ease of construction. The best in terms of drag was an elliptic shape. Now i knew, where i was.

http://www.rclandsailing.com/catamaran/design.html#hull

When googling for plans of model-cats i found this site:

http://water.resist.free.fr/

This plan looked best:

http://water.resist.free.fr/plans/WRC21.pdf

There are also dxf-files available. A colleage of mine is a specialist for 3D CAD design. I gave him the dxf-files and he made a 3D model of the hull out of the DXF-files. (Thanks Matthias)

Here are the drawings of the segments:

WCR21_Segments.zip

But how getting a hull from the plans with the least effort?

diy-store -> Styrofoam with 100mm thickness --> some cardboard --> 14 cross-sections of the hull printed on paper --> some double sided sticky tape --> a hotwire styro-cutting assembly and three evenings when my wife had to watch TV lonely.

One of the hull-segments is the solution to the "guess-what" picture of the last episode.

This are the middle segments, stacked up.

All 14 segments (each with a thickness of 100mm) were glued together with styro-glue. A little bit sanding and the hull was nearly finished.

The glued segments, before the coating...

To add stability, the hulls were coated with a thin layer of fiberglass and epoxy.

The coating - and sticky fingers...

To connect the two hulls with a styrofoam-board that serves as a platform for the superstructures i used styrofoam screw-anchors and M5 Screws, that were epoxied and glued into the top of the hulls prior to coating.

The styro screw-anchor

To give it a real good finish there had to be much more sanding, priming and painting, but as already mentioned earlier, patience is not one of my strenghts, and so i decided to bring that provisional assembly into the water as fast as possible.

This construction is far from being perfect, but to prove the concept it was OK.

The first launch...

The first launch:

Yipee! I have invented the catamarane-oscillator!

The cat oscillated, but found its waypoints. On the first run...

The second one with decreased P ended up in my first swimming exercise in this year. It was still oscillating, but it did not manage to find anything. The problem seemed to be the lateral stability of the ship´s aft. The new hull had problems with his butt! Back at home i added fins on the backside of the hulls. The size had a triangular shape and went about 100mm below the waterline.

Back to the lake...

The lateral stability was much better, when manually testing it by shifting the ship left and right.

Launch...

Swim!

This was too much of the good thing. The ship went off with absolutely no oscillations, it seemed that it sits on on rails. Finally it crashed to the shoreline after having drawn a very wide circle. The crashpoint was 2 meters away from a russian-immigrant fisherman, who is always there when i had unlucky experiences. I like his comments. "Ahh, new ship ey!", "Ahh, better ship now (grin)". The propeller managed to wrap the end of a small branch around its shaft two meters away from the shoreline. I took off my trousers and waded into the swamp to get it out of the water. Must have been a curious looking picture, because i went to the lake on my way back from the office: A man standing in his undertrousers in a lake with shirt and tie, holding a catamarane in his hands, discussing with a russian-based fisherman about fishing spots.

As a next step, i stripped the fins to one third of their original size. And now it was perfect.

No oscillations, straight line...

The two fin sizes together ( i re-glued the cutted segment to see the difference)

What a difference some square-centimeters make!

The new Data:

current: 5.2A @ 11.5V

speed: up to 8 km/h

Thats all till now, time-lapse is over, with episode 11 we have reached the real-time.

Let´s see what the future will bring!

What about starting a colaborating project for UAVs (Unmanned Aquatic Vehicles) on this site?

(The start will be the finding of a better abbreviation...)

Please comment.

ardupilot goes into the water Part 10

Posted by Harald Molle on April 18, 2010 at 11:35am

Software...

There a several problems, when you do embedded software documentation. The most evident one is, that you don´t have so cute looking pictures as you have when documenting mechanics or hardware.

Despite that fact, i provide one:

This nice plate was photographed in the vicinity of a Buddhist temple on my last holiday in Thailand.

The wisdom of this sentence becomes evident, when you are a developer, especially if you are a software-flavoured developer.

A (now retired) customer of mine, who was specialized in mechanics and optics development once asked me:

"Do you know what´s the real hell on earth? "

I said "no".

"I will tell you: It is water and software combined in one device"

At that time we were involved in the software development for a laser-system that had water-cooling.

He was right!

Bringing the ArduPilot into the water was a bit like that project.

The baseline for the development of the ArduPilot software was the very first version of the ArduPilot, which was published as Version 1.0 and can be downloaded from Google-code. http://code.google.com/p/ardupilot/

The V1.0 zip file should be found here: http://ardupilot.googlecode.com/files/ArduPilot1.0.zip

For the installation of the Arduino platform, please have a closer look to this site:

http://code.google.com/p/ardupilot/wiki/LoadingPage

here you will find a very good introduction, how to get all up and running. I also would suggest to read the whole Ardupilot Manual first, before starting any actions: The Manual can be found here

http://code.google.com/p/ardupilot/wiki/ArduPilot.

The following list contains the modifications and bug fixes that i have applied to the V1.0 code. The list may not be complete, because my book-keeping of the changes was not very accurate, when i was in the hot-phase of the development.

1) Some #defines for constants were added, because "magic numbers" inside the code may cause troubles, when used more than once. All constants are now shown in upper-case letters.

2) The data-structure for the waypoint-list was changed to a predefined array, so the initialization of the predefined array is done by the startup-code of arduino itself. The tab "Mission_setup" was no longer used and was therefore deleted.

The array that holds the waypoints is now located in the "ArduPilot" tab.

The structure for the waypoints looks like this:

typedef struct

{ float lon;

float lat;

}LONLAT;

The predefined waypoint array looks like this:

LONLAT wps[ ] =

{

10.02069619383977, 48.35006621372347,

10.02018762320307, 48.35061609619746,

10.021905, 48.350598 /* Home*/

};

3) The number of elements that are contained in the array is calculated upon startup. (one of my first recovery-swimming actions was caused by an erroneous waypoint, that the ship tried to reach, because the "#define waypoints" directive of the original version did not match with the real number of elements in the array) .

4) All code that had to do with "Return to launch" or "Manual Mode" was eliminated.

5) All code that had to do with altitude control was eliminated.

6) Some unused test variables have been deleted.

7) All calculations in the PID-control are done now on a one-second base. In the original code, the time betweeen the executions was calculated and the value was multiplied / divided by the Integrator and derivator part (the dt variable in the 1.0 code). When using a 1Hz update rate, the factor is one and so, i deleted the code, to avoid unnecessary floating point operations. In reality, the update rate, which is driven by the GPS jitters a little bit, because the NMEA-messages are different in length. But for the practical use, this is of no concern.

Attention, when using a GPS with a faster update-rate, this functionality has to be reactivated.

8) In the orginal PID-control, the "heading_output" variable, that keeps the result of the PID calculations was of type "int". The calculations are done in float. This led to a big inaccuracy, because i used k-values that were below 1.0. Maybe for the first implementations of the Ardupilot nobody noticed that, because for the EasyStar values of around 10 were used for the kp and the integrator/derivator were not used and so, the error caused by that was very small. I changed it to float and all was fine.

9) I changed some suspicious "int" to "float" assignments and did a casting, everywhere i found it necessary.

10) The integrator values are reset upon startup and on each waypoint switch and held to zero for 25 seconds after the switch. This cures two problems:

1. The NMEA-parser has still a bug, that sometimes produces erroneous readings upon startup.

2. after sharp turns, the integrator adds up and causes offset problems. The 25 seconds is the time needed for a full 180° turn of the actual ship (catamarane).

This time is set in the #define WP_TIMEOUT directive.

11) I often use #if 0 (1) directives to switch off or on code or data segments.

i find this more convenient than commenting the parts out.

12) I added #define "model" segments to switch between different parameter sets (catamarane and monokeel in the actual version). note, that only one can be active at at time

For the moment, thats all that can be told about the software. Please leave a comment if you have any further questions or suggestions.

Here is the .zip file that contains my actual code:

ArduPilot.zip

Not much pictures in this episode, but i add here a "guess-what" one.

More about that in the next episode...

Ardupilot goes into the water Part 9

Posted by Harald Molle on April 11, 2010 at 1:01pm

Yes i know!

I am late with this post, compared to the other ones.

Easter holiday is over, back on work.

Had to prepare a presentation and a demonstration of the surveying system, which i held at our local diving club on the weekend.

And i felt in love with the Dr. Depth Software. Real great stuff! After having sorted out the philosophy of operation, it was pure fun, creating new maps. There are good tutorials out in a yahoo group, that make it easier to understand some things.

http://tech.groups.yahoo.com/group/DrDepth/

All this consumed a lot of time which in turn choked my writing organs.

The presentation went good, hope that the spectators were not too confused about the technical stuff.

And the demonstration on the lake busted one of Murphy´s laws, stating that "If anything can go wrong, it will".

Nope!

All went boringly easy:

The ship went off for a 30 Minute ride, did its criscrossing over the lake, came back, switched off the motor 3 meters before it hit the shoreline and glided smoothly back to the launch point. This moments are rare in live! All systems worked as they should. No evil buoys, no panicked swans attacking the ship, no motor switch-offs, no oscillations. I still can´t believe it!

Stop dreaming Harald, back to reality.

I wanted to tell something about the Autopilot Hardware in this episode, here it is:

I think it is of no use, explaining the ArduPilot Hardware in depth on this site, because this has already been done in the ArduPilot manual. I will only focus on the differences to the "original", which are very minimal.

The biggest difference between the original is that i do not use the "fallback" solution for the RC-controlled recovery, because the missions of the ship (in future) will be by far beyond the reach of a (legal) RC system. (And the thrill is much bigger, when you know, that a software error can ruin your day by forcing you into a recovery-swimming action!)

The "fallback" solution is realized by the ATiny processor (U3 in the schematics). The ATiny measures if there is a switch signal from one channel of the RC receiver, and controls the multiplexer (U4). This multiplexer switches the source for the servo-controls. (either the control comes from the ATMEGA or from the RC-receiver).

Normally this should work without problems, because the multiplexer defaults to the ATMEGA (for the RTH / RTL functionality). But in my case there is no RC Receiver connected to the "switch" input. There are no pull-up resistors involved to keep the input level to a default level and i do not know if the internal pull-ups of the ATiny are used. To avoid erroneous readings by EMC effects, i disabled that functionality "hardwired".

This is done by two measures:

1) isolating the "TSCK" pin (pin 7,U3) of the ATiny by lifting the pin.

2) connecting Pin1 of U4 with VCC (Pin 16 of U4) to force the multiplexer to the B inputs, which come from the ATMEGA.

The modifications can be seen in the following pictures.

ard00.pdf

ard02.pdf

This are the only modifications on the Arduino-Board. Maybe this is unnecessary but i wanted to be shure, that nothing inwanted can happen. Maybe Jordi can tell me if this was necessary or not.

The rest of the hardware configuration is fairly easy:

EM 406 GPS connected directy to thec onnector U2,

The ESC ( Electronic Speed Controller) connected to the port "OUT1",

The yaw servo (the windmill turn servo) connected to the port "OUT2".

A DataLogger for Debugging purposes is connected to the Output UART from the ATMega.

The ArduPilot Board is powered by the BEC-functionality from the ESC, so there has to be a bridge between Pin 2 and 3 on the Jumper JP7.

Here is a Block diagram of the whole stuff:

Some of the components:

The ESC..

The (optional) DataLogger...

the well-known EM406

and the battery-Pack, which consists of three surplus LiIon Packs from medical equipment. (12V/16Ah(

Thats all fir the moment about the hardware-configuration.

In the next Episode the Focus will be more on the Software side.

I think one episode for the software will not be enough.

Lets see what future writing will bring...

ardupilot goes into the water Part 8

Posted by Harald Molle on April 7, 2010 at 11:06am

Fighting with Dr. Depth.

No No, i am sorry, no Talk about the Autopilot in this episode, this will be done in the next one.

Yesterday i bought one copy of the DrDepth Software.

The first hour playing with it was frustrating.

Putting the NMEA Raw Data from the Sonar into it was a struggle.

If yo push the convert button, it says "conversion OK", but nothing happens.

After some time i found out, that this function does what it means: It converts the data. But nothing more. You then have to re-open the converted file, then it worked. The next problem were the depth artifacts from the launch-point. They created a real abyss on the launch point (about 6600m in depth)

Which in turn made the rest of the plot very flat ;-)

After having sorted out all buttons and switches, the Batteries of my MacBook went down. (the AC Adapter i have left in the company). Close to the finish and i missed it!

Nearly sleepless night.

In the morning i first did a little bit of NMEA Archeology, to find all the various files i have sampled in the past six months. A pretty lot of files!

Then i manually took out all the artifacts (the times, when i knew all the switches of GREP by heart are long ago and so i did it with a text editor). Where is that copy of this old UNIX manual from ´84 ? Maybe Ken is reading it on my bookshelf, should have a closer look in the cellar.

Then all data converted (and re-opened :-) ) in DrDepth and :

- thats it -

... in 2D ...

...in 3D...

... And the contour lines

Real amazing! It also creates the.kml reference files for the 2D and the contour files with alpha-blending.

It is crazy, what it produces with such a low amount of data! I took only a few criscrossing trips and a better result than all that MatLab crunching.

OK, there are some weaknesses in the Program, but actually im am still in the enthusiastic phase.

Thats all for today, next time something about the ArduPilot Hardware (i swear)...

ardupilot goes into the water Part 7

Posted by Harald Molle on April 5, 2010 at 11:43am

Could this have been the end?

The platform with the fire brigade ship was something like OK.

The vizualization was something like OK.

For the data-collection we could have lived with that solution.

All members of the team have an engineering background (for sure not in ship building).

As an engineer you look always for better solutions (especially if you are a german one).

Grmbl...

Thinking...

Sleepless nights...

Pling!

What about catamaranes?

No bad idea!

Anyone around who knows somebody who knows someone who has ever built a cat? -nope-

So went the discussions in the weeks after the success with the fire-brigade ship.

The last days of summer went away and i was looking for new horizons.

First try with two 100mm PVC sewage-tubes, four PVC 45° fittings, a styrofoam board, meters of Gaffer-tape and countless sticks of hot-glue.

The windmill on top and here we go!

Not bad for the beginning, but looked not satisfying. No pictures left, maybe i can fake some to see, how it looked like.

Next try.

I have found a good material, while physically googling the diy-stores around my hometown: 2.5mm thick PVC hard foam boards.

They can easily be cut with sharp cutter-blades and glued with hot glue. This was the ideal material for somebody who wants to have the results of his ideas realized some miliseconds after the idea hit his brain -me-.

Building the two hulls of the cat in three hours looked quite attractive to me and it was feasible. The simplest form was a V-shaped hull with V-shaped endings.

The three hours turned to six and after that i had the two hulls manufactured. I took a 30mm styrofoam board to connect the two hulls and the platform was ready. The windmill still served as propulsion system.

This assembly will shurely not a candidate for the "Germany´s next ship model"-contest

Tadaa! The new Platform

The first course was a triangular one, starting from the the launch point, turning right in a 90° turn after 100m then 60m and then back to the launchpoint.

Looked good.

The first tries...

In the picture you can see the course of three runs, each one was started with a different launch-angle, to see, how stable the PID control loop works.

The proportional part of the PID was increased by a factor of 5 compared to the firebrigade-ship and the rudder-horn attachments were also altered to give an estimated factor of 2. So in total the proportional part was multiplied by 10! The straight-line behaviour was excellent, the cat went like it was on rails. The radius for the turn was about 10m, which is more than i had on the previous platform, but this is OK.

No oscillations!

I was happy. And it was already december.

On the morning of december the 24th we had our traditional meeting from our diving club on the lake where we drink some amount of hot wine and we have some cookies - nice event-. I wanted to test some new parameters this morning, but we had ice on the lake. Very early in this year... And the winter was long and hard, the ice lasted until mid march this year. A long time, if you are addicted to optimizing! Some years ago, a friend of mine sent me a postcard from a holiday, it was subtitled "The only ice in florida is in the drinks". I thought a lot about that in the past months.

On 25th of March i started the new season with a zigzag-course from north to south with longer legs than i did before.

The ZigZag

In this screenshot we see two trips: the green one was the first one

the blue one is the optimized one. The white is the mission planning path.

Lets have a closer look to the green one:

We can see, that there is a curve with a big radius, when heading from one point to another. Analyzis showed, that the Integrator part was the bad guy. In the past experiences we set the integrator limit to a very high level and the integrator factor (Ki) to a very low value compared to the Kp. Kp is 2.5, Ki is 0.03.

The problem came from the hard (nearly 180°) turns. While turning, the integrator adds up to very high values, because we have a big difference between the setpoint and the actual value. And with this "heritage" of integrator values, i takes a lot of time for the decay of the values.

The Integrator is needed for accuracy and i wanted to keep the ki low, to avoid oscillations.

The cure: When looking at the time, the ship needs to make a "full turn" we found about 20 seconds in every case. We already had a "integrator holdoff" function in the software that cures the NMEA parser startup bug. Increasing this time from 5s to 25s led to the blue track. (The integrator part is not needed for the turn, because it is overriden by the p-part)

This is close to being optimal. The direct straightline (a real zigzag course) is theoretical not possible because the turn itself has a fixed radius. The actual waypoint algorithm always calculates the course to the next waypoint from the actual position. If we take this into account, the result is OK. I measured the maximum lateral deviation from the straight line with about 3 meters (on a leg length of 300m).

Not bad for a pure GPS-based autopilot solution.

All for today, the weekly TV thriller starts in a few minutes and will not miss it.

Next episode will focus on the autopilot system.

ardupilot goes into the water Part 6

Posted by Harald Molle on April 4, 2010 at 7:54am

From the numbers to the pictures.

We took all the NMEA data from 10ths (feeled thousands) of test-drives and concatenated them into one big file, we then converted to the UTM/depth representation as mentioned in the previous episode.

This file was finally fed into a MatLab script, that produced a 3D image, where the depths are represented as colors, ranging from red to blue. Red was 0m and blue the maximum depth of this (shallow) lake with about -11m. MatLab does an automatic adaption of the colors and the axes in this case. In the first run, the x and y data (resp. Easting and Northing of UTM) were also plotted in blue color. The derivated picture looked like that.

This is not very spectacular, because the whole picture is covered with blue lines.

The next one is without them:

This Picture shows the color-of-depth-representation only, and the aspect ratio is now about to be correct. (sorry, these are only screenshots)

This "Pizza Margherita with blue Curacao"-like JPEG will later on be the overlay for the Google-Earth representation.

But first, a 3D view of the lake:

This view is from below, looking up, so the "deep-Spots" in the lake are better visible. The spikes on the right side are depth-artifacts, coming from the launch-point, where the sonar transducer hit the ground.

There are three "deep" holes in the lake, they go down to about -11m, but the rest is in 3-5m range covered with waterplants, which gives a "billowing" effect in the orange and red area.

I think this view can be improved by changing the color scheme and putting a grid over it. (some new project for Jochen...).

Now back to Google Earth.

In GE, there is an overlay feature, that lets you mix the GE view with a picture. Now we have a picture, but how putting it all together getting it matched in terms of size and aspect ratio?

First of all, i activated all tracks, that we have produced in the past (the GPS Vizualizer thingy - you remember?). This will give us a picture like that:

Then, we activate the Overlay function in GE and take the picture with the blue lines as overlay. After adjusting the transparency, we can see both pictures. And then we can tear,push,shove and move the picture until it matches the tracks. This overlay we keep. Then, we do the same with the other picture (The Pizza-view) and take the overlay, we created before as a reference. So we arrange an overlay over an overlay over an overlay. Quite strange, but it works. This last overlay is THE overlay. If we save it as a .KMZ (not .KML!!!). We can distribute it to anybody who wants a quick pizza-service on Google earth.

So it looks like, before the matching of the overlays:

This is the picture it looks like, when all is done.

I try to provide the .kmz file here as a reference. (i splitted up the picture and the depth legend, so the legend can be placed anywhere.

Gurrensee_TP.kmz

Back to reality:

We tried it out on the next weekend-dive we had in the lake. We took the course from the launch-point to the "big-hole" on the leftmost side from Google-earth (the ruler-function), adjusted our compasses to that course and we hit the hole exactly!

Theory and practice in perfect match - that´s rare.

This was the Past. On my first blogpost on this site, a member (Tom) gave me a link to a swedish company which provides a software that does all the above with a few mouseclicks and the 3D representation looks even better. I tried the demo in the last days and it looked good. I think i will spent the 99 Euro-bucks and try it out.

Is anybody out there who has eventually experience with that Software?

It is called DrDepth: http://www.drdepth.se/

This is not the end of the story...

I think there will be another episode. Maybe you remember the oscillations on the plots? The solution to that will be posted next.

Here is a sneak preview:

Fighting with the Integrator, the NMEA parser bug, and a new platform...

Bye bye fire-brigade ship have a nice stay on the cellar shelf with Ken.

ardupilot goes into the water Part 5

Posted by Harald Molle on April 3, 2010 at 8:03am

The Number Crunching Era

After half a year of finding an adequate platform for the surveying system, we returned to the roots of the project: The survey of lakes. Further on, the project was called "Sea-Survey". The reaseon for that name did not arise from gigantomanic phantasies of surveying the oceans but in German the word for lake is "See" and the pronounciation is a little bit like "sea" in english, and this gives the project a kind of international touch :-). And -maybe in the near future- we might use the system for finding reefs and shipwrecks in the mediteranean sea, which is one of our beloved diving sites.

I am also talking of "we" instead of "i", because meanwhile the project attracted some of my colleages, who helped a lot, especially for the data conversion software and the 3d vizualization.

Thanks to Robert, Frank, Uli and Jochen.

One of the key requirements of the whole project was:

-keep it as simple and cheap as possible-

In terms of "workload" and "time-spent-swimming-in-the-lake" it definitely was not!

But, in terms of hardware and software costs, compared to professional systems, it was.

So we tried to use as much as possible "free" Software for the data processing.

The hardware cost added up to under 1.000$ (not counted the the "titaniced" Garmin etrex summit), which i find is still adequate.

The mission-planning tool was Google-Earth.

The analysis and PID-loop optimization tool was Google Earth.

The vizualization and publishing tool was Google-Earth.

The ArduPilot firmware development tool was not Google Earth, we used the Arduino platform instead :-)

The "extract-lat-lon-depth-from-NMEA-and-convert-it-to-something-useful"-tool was done by a PERL-script, written by Frank.

The "convert-the-whole-file-generated-by-Frank-to-UTM-data"-tool was a C-Program, that was written/adapted by me, consisting mainly of a WGS84 to UTM conversion routine that i found somewhere in a corner of the internet.

The 3D Vizualization was done by a MatLab script, written by Jochen. (I was lucky, knowing somebody who had a valid licence). Still working on this issue, because it will definitely be no lo-cost solution if you have to buy a MatLab licence. We tried SciLab instead, a FreeWare tool, which is close to MatLab, but it lacks in some essential functions that ease 3D vizualization.

The NMEA-data conversion to Google-Earth was done via a server-based tool called "GPS Visualizer" that can be found on this site: http://www.gpsvisualizer.com/map_input?form=googleearth

This tool is absolutely great! you can upload up to 3 NMEA Data files and convert it to .kml or .kmz files. The result can be viewed with Google Earth. As an option, you can convert every NMEA sentence to a waypoint, that contains all relevant data like speed, bearing, time and position.

Lets go back to the mission planning:

In Google Earth, we created a path, that merely was a zigzag or meander-pattern for the criscrossing of the lake (we are still looking for an optimal pattern). The path was then exported as a .kml file, that contains the latitude and longitude coordinates covered among lots of XML data. With a text-editor and some "copy-paste-search-and replace" operations we had a "const" data field that was pasted into the ArduPilot code.

Yes i know!

That can all be done much easier with the "ArduPilot config tool", but we are talking about the past!

I still prefer putting the waypoint data into a predefined array instead of the eeprom for several reasons:

- it is easier to handle

- i still use large parts of the V1.0 code of ArduPilot as reference.

- the space left in the Flash and RAM can hold up to several hundred

of waypoints, which is absolutely sufficient for a multi-hour mission, so why bother?

- you have to connect the FTDI-adapter and to disconnect the GPS module anyway, so there is no much difference between loading up the new code or loading up the new mission data into the EEPROM. Hopefully we will have ArduPilot-Mega available soon in Germany, which will surely change my opinion. I personally prefer having lots of UARTs in a system, but this is another story...

Much text, no pictures till now, so here we go:

This is the lake, called "Gurrensee", where i spent lots of hours in 2009.

This is the same lake, polluted with yellow and blue color, how awful!

The yellow one is a path, that was created by Google Earth and converted to a "C" constant array, that forms the waypoints. The blue one is the "real" path, the ship took. The oscillations are a special case, that will be addressed in one of the next episodes. The circle on the right side came from a collision with a buoy, that was there (the only one in the lake and i hit it...)

The data from the sonar system was sampled with another data-logger, i mentioned earlier. This one had the advantage, that the RS232 drivers are already on the PCB, so the output of the sonar´s NNMEA data could be directly fed into the datalogger. Anyway, if had known earlier, i had would have used the SparkFun one, because it is half the price and the firmware is open-source. The NMEA data from the sonar, which contained the GPS position and the depth information was converted with a perl script to a simple text file, which contains only three fields: latitude, longitude and depth.

In the first approach we had a simple "lat/lon-to-something-like x/y" conversion, but it lacked in accuracy and the picture was distorted.

For a 3D-representation, we converted the the latitude-longitude values to an UTM projection, which is better to handle.

I found some C-code fragments in the internet, which does this calculation. After this second conversion we have a file that contains the northing and easting values and the depth in meters.

so in short, we got the NMEA file, that looked like that:

$SDDPT,2.7,0.0*52

$SDDBT,9.0,f,2.7,M,1.5,F*0E

$GPAPB,,,,,,,,,,,,,,*44

$GPGLL,4821.0295,N,01001.2870,E,064449,A*2D

$GPRMB,,,,,,,,,,,,,*66

$GPRMC,064449,A,4821.0295,N,01001.2870,E,1.3,257.0,060509,0.6,E*7F

$GPGGA,064449,4821.0295,N,01001.2870,E,2,7,1.20,476,M,,,1,0*0B

$GPGSA,A,3,11,,20,14,19,17,28,,120,,,,2.30,1.20,2.00*32

$GPGSV,3,1,9,11,78,274,45,32,74,238,,20,42,245,42,14,35,53,39*78

$GPGSV,3,2,9,19,33,171,40,17,18,317,40,28,16,281,41,3,5,165,*43

$GPGSV,3,3,9,120,29,212,35*4F

$SDMTW,14.4,C*05

$SDDPT,2.9,0.0*5C

$SDDBT,9.8,f,2.9,M,1.6,F*0B

after the first conversion it looked something like that:

10.0214716666667,48.3505433333333,2.7

10.0214683333333,48.35055,2.9

10.0214633333333,48.3505566666667,2.7

10.0214583333333,48.350565,2.3

10.021455,48.350575,2.1

10.0214566666667,48.3505816666667,1.9

10.0214566666667,48.3505916666667,1.8

and after the UTM conversion it looked like that:

575685.808035, 5355782.793725, 1.100000

575685.064694, 5355782.969104, 1.200000

575684.321354, 5355783.144484, 1.300000

575683.580482, 5355783.134613, 1.200000

575682.713664, 5355783.308347, 1.100000

575681.599888, 5355783.478792, 1.100000

Please note: This fragments do not correspond, i took it out of the converted files arbitrary.

This file was finally fed into a matlab-script, that does the 3d visualization.

And this will be the story in episode 6.....

ardupilot goes into the water Part 4

Posted by Harald Molle on April 2, 2010 at 9:18am

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.

Ardupilot goes into the water Part 3

Posted by Harald Molle on April 1, 2010 at 9:13am

I love Body-Boards.

They are poor man´s surfboards for for non-hawaiian non-californian or non-seaside residents like me.

A Body-board should be the ideal platform for carrying all that electronics.

How was i wrong!

The only thing which was missing is an adequate propulsion system.

The first try was an electric bilge pump. As already mentioned above, i don´t like propellers in the water, because they will easily fall in love with water-plants.

A bilge-pump seemed the ideal solution, because it has a shielded propeller, which is well adapted to the motor by a gear.

The outlet of the pump was connected to a silicon tube, the steering was done by a servo that bent the tube to the right and the left.

Yes it worked - in principle -

But the thrust of the pump was not high enough to get an adequate speed and the tube-bending assembly had not enough "angle" to make good turnrates.

Sorry, no pictures are left from that assembly.

Still the idea with the body-board.

I skipped the idea with the bilge pump, anyway a model with a better throughput may have done the job....

Till this point all assemblies have been very very crude ones, stucked together with gaffer-tape and hot glue. The only purpose of this assembles was to prove, if the concept is OK.

Till then it obviously was not.

Then i went in a more serious phase, when i entered again the local RC retailer shop and left it with a BLDC Motor-propeller assembly from Multiplex.

It was a kit for pimping the Park Master from Multiplex, the "Power drive "ParkMaster 3D" #332638". See /http://www.multiplex-rc.de/ for details.

The Parkmaster pimping kit.

This kit was mounted on an alumnium plate, which was recycled from an old 19" rack. The steering was done by an air-rudder, which was made from a PVC foam board. It looked a little bit like an oversized side-ruder of a model plane. Thrust was OK now, but the steering was not. In principle it worked, but the air-rudder had not enough "power" to give a good steering quality. Additionally, the left and right curve radiuses (or is it radii ?) were different, because the simple "steel-wire-rudderhorn-servo-coupling" was not symmetric.

And, most of all, the body board had no keel, which makes it very instable. Holding a straight-line course is like juggling with three balls (and i hardly can do that with one). Adding a few stripes of PVC-foam-boards on the bottom of the board made it better but not good enough.

This is the Body-Board with the air-rudder. Still with telemetry, still RC controlled.

Next Try: I mounted the BLDC Motor with the propeller on a PVC Tube and put it on a PVC pivot so that the whole assembly can be turned by a servo. Looks a little bit like a windmill. This led to better results for the control of the Body-Board, but the stability for driving a straight line was still not satisfying.

The first approach was to connect the PVC tube to the servo by an an O-Ring. Worked, but was a little bit sloppy when the tension on the O-Ring is too low and gave to much force on the shaft of the servo, when the tension was OK. So i decided to connect it "classically" with steel-wire and rudder-horns.

I kept this propulsion-approach for all further platforms, because it proved to be very robust.

The Windmill assy with O-Ring connection. Sloppy...

The Windmill assy with steel-wire and horns. much better..

Thats all for today, next episode will focus on a more serious hull, the introduction of ArduPilot and the black day.

Ardupilot goes into the water Part 2

Posted by Harald Molle on March 31, 2010 at 9:00am

You asked for it.

Here is the part 2 of my experiences...

(still fiddling with the Rich text formating on this page)

The first steps:

In spring of 2009 when the ice from our training lake, which is in the vicinity of my hometown, melted away, the idea, that was born on that mountain lake half a year before, manifested into a project. It should be an easy-going project with not too much workload, one to two weeks or so...
That were my plannings. Reality showed, that it was not that easy.

Step 1 (The jetski era)

What i needed first, was a swimming platform, that was able to carry the sonar system.

The Sonar i bought one year earlier was ideal, because it had a GPS and a sonar combined in

one device. And the NMEA output via the RS232 link also provided the depth below the transducer as

a separate NMEA sentence.

The one i used was a an EAGLE CUDA 350. I think it is still available for an affordable price.

http://www.eaglenav.com/Products/Fishfinders/CUDA-350-SMap/

Next, i went into our local RC retailer shop and bought an RC-guided Jetski model boat.

The jet propulsion system seemed to be and ideal choice, because it will not interfere with the water-plants as normal water propellers.

No good idea.

The model was to small to carry the Depth sounder, batteries and the other stuff.

The current drawn by the (brushed) DC-Motor was horrible (about 16A @ 12V).

The water inlet of the jet drive was rapidly clogged with algae and other stuff swimming arround.

Then i built a styrofoam platform which was fixed in front of the jetski Boat with sticky tape and hot glue to get the Sonar transported. Better having a bad platform than none :-)

This is the Jetski- push assembly. The Sonar is mounted on the styrofoam in front of the ship, the transducer is below the styrofoam. The Telemetry assembly is in the Tupperware-like box on top of the Jetski. The Barbie-Ken type guy who sits normally there was taken off. (Sorry Ken, no fun this time, enjoy sitting in my cellar on the shelf).

The next problem was the visibility of the ship.

You can´t hardly control the boat when it is some 100m away, even with binoculars.

So i decided to transmit the GPS Information via a telemetry link to the shore and control the ship remotely with a realtime display of the GPS TrackMaker Software. ( http://www.gpstm.com/ )

The Radio Link was excellent , but the realtime response of the Software was not realtime enough to steer an instable assembly.

For the telemetry link i used an evaluation system with a "true R2323 to air" solution from Radiotronix, so i could remotely connect the RS232 NMEA output of the EAGLE Sonar to the Laptop on the shoreline, that served as a ground station.

Here is the link to Radiotronix:

http://www.radiotronix.com/products/proddb.asp?ProdID=13

This is the "Ground Station" running GPS Trackmaker on Windows XP in a virtual machine on a MAC. On the left side is the Evaluation board with the Radiotronix module on it. The connection to the MAC is done by an FTDI-type USB2serial adapter. (quite weird configuration, but it worked!)

Next, i tried to pull a Body-board with the jestski-model. The Depth-sounder was mounted on that body-board.

Nope.

The jetski is a glider boat and with that payload in the aft, the boat refused to glide and the guidance did not work very well.

Fortunately i have no pictures from this assembly (it looked too curious).

Thats all for today...

in the next episode i will tell more all about the "Body-Board era"

To be continued...

Ardupilot goes into the water Part 1

Posted by Harald Molle on March 30, 2010 at 12:00pm

Hello everybody,

this is my first blogpost on this site.

In the following i will describe my experience, my ups and downs while

developing an ArduPilot based depth surveying system for lakes.
I know, this site is primarily for flying platforms. Please leave a comment, if you think that this is not the right place. Maybye, some of my findings are also interesting for flying platforms.

The Beginning:

If you are a scuba diver, depth is one of your major concerns.

If you are one an unknown divespot, depth is the major concern.

Two years ago, those were my thoughts, when we went diving in a mountain lake on the North Italian side of the Alps, where nobody had been diving before us.
How deep will it go ?
What will be the structure of the ground ?
What about the slope ?

On this lake, the story started.

The native people only had speculations and stories about the lake, but nobody could tell us what we really wanted to know.

Discussion with the native people, with every beer, the depth went deeper.

So the idea was born to survey the depth of this lake prior to submerge our bodies into the unknown.

The equipment consisted mainly of a Depth sounder with GPS (aka Fishfinder), a Body-Board, a GMR walkie-talkie and me, swimming with all that stuff criscross around the lake.

The „Ground-crew“ stood on the lakefront with the second GMR, writing down my „depth-and-waypoint-readings“ .

In the evening, all the waypoint data was collected and put manually into the laptop, running an old Version of the FUGAWI software. The depth profiles were manually drawn on a few sheets of paper.

The result was not very spectacular, the profile of the lake had mainly the shape of a bathtube, filled to one third with mud.

Here i am mounting the Sonar to the Body-Board.

surveying the hard (and cold) way...

But, what lasted, more than the result of that action, was the idea of automating that process.

To be continued...