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.
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.
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...