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...
Comments
My result in short:
Use an EM406 if possible. It is rock-solid
Others may also work, but this one is proven on nearly 100 missions.
Each module has its specialities.
some refuse to update the data, when you are running at low speds ( e.g. the MTK in NMEA mode)
some freeze the heding information when the speed falls under a 5 km/h threshold.
The EM406 is not newest one, but it works.
Ihve never tried the uBlox, but it is also a renownned module.
Update rate: i use 1hz (the EM406 is a 1hz only one) and it is sufficient if your boat is running at speed below 10km/h.
Anyway, the actual software libraries from diydrones can easily be ported to support binary mode.
thanks for this tip, i did not realize, that jordi has already made this board. (or i forgot). The one, Jordi is using has no tilt compensation, therefore the price is one third of the SparkFun Board. The HMC6343 is a more sophisticated one, with integrated Accelerometers and a uC for tilt compensation. If you do not know the attidude of the "tiltless" sensor, the readings are quite inaccurate. My old, beloved Garmin etrex summit (which is now on under water) had also a compass in it. For accurate readings you have to hold it to the level. By tilting it, the readings did differ for tenths of degress compared to the leveled ones.
it seems like the same honeywell HMC5843 - Triple Axis Magnetometer breakout board sold by diydrones is better as Jordi has installed pullup resistors, level shifters, and 3.3 volt power supply in the same board which you might need to do if you used SF board.The SparkFun board does not have pullup resistors, level shifters, or 3.3 volt power supply. You can get by without level shifters, but that leaves the issues of the power supply and the pullup resistors. The I2C interface will not work without pullup resistors as per experts who are testing it.
http://www.xumba.scholleco.com/viewtopic.php?t=1272
http://www.xumba.scholleco.com/viewtopic.php?t=215
I wish I could. Although I've written code, I've never written a driver nor done anything with Ardupilot (yet).