I'm using Fritzing by the way. I like its ability to describe physically the breadboard, so when capturing schematics, I first capture the breadboard, and then arrange the schematics. This is one more step than capturing schematics (or say half a step, since components and relations between them are captured already), but I found it less error prone than going directly from the breadboard to the schematics. Furthermore, laying out the schematics is an additional chance to catch a missing resistor or two.
A comparison of RockBlock 1 and RockBlock 2 wirings.
|Signal||Description||Rockblock 1||RockBlock 2||RB 2, separate connectors|
|-||Do not connect||1|
|5V||5V Power supply||2||4||A4 (as Vcc)|
|8||B2 (as 5v In)|
|TX||Iridium 9602 TX||3||3||A3|
|RX||Iridium 9602 RX||4||2||A2|
|CTS||Iridium 9602 CTS||5||5||A5|
|RTS||Iridium 9602 RTS||6||1||A1|
|SLEEP||Iridium 9602 On/Off control||7||12||B6 (as OnOff)|
|RING||Ring Indicator||8||10||B4 (as RI)|
|NET||Network available||9||11||B5 (as NetAv)|
|5v Out||5V regulated output, for powering external Arduino host||9||B3|
|LiIon||3.7V Li-Ion power supply||13||B7|
The basic Afro ESC doesn't support enough voltage for my needs (the solar panel can deliver as much as 22V). I tried the Spider ESC, but it doesn't support reverse and I can't flash it (furthermore, it's a bit too hot for my taste). Luckily, there's a "high voltage" (8s) version of the afro ESC, astutely named afro_hv. I got one of these, but it ships without reverse_pulse, that is the ability to go forward and backward, enabled. So I had to flash it, which was very easy using RapidFlash and the AfroESC USB programmer.
On a totally different matter, I tried several frequency for the power sampling loop, and after a few problems and Fourier transforms, I settled on a 1kHz frequency: I'm using an ACS 712 based breakout for current measurement and a voltage divider vor voltage measurement. I had a very unstable measurement with the motor running, that I first thought was provoked by uncontrolled noise (magnetic ?) around the ACS 712. However, when calibrating with a resistor, I had a very stable measurement, thus leading to the evidence that the "noise" is actually the commutation of power inside the ESC / motor pair. I sampled at different frequencies, and got something stable around 1kHz (initially, I was using 10Hz...), which coincidentally is the sampling frequency of the ESC.
Seacharger crossed the Pacific Ocean from California to Hawai. Clic here to read everything about this great achievement.
For the Almabraxas boat, I dropped the idea of using a rudder in favor of a differential thruster system, because I think the rudder control mecanism is too complex, both from the mechanical and waterproofing point of view. However, since I had selected some components, I built a control card, just for training. We can see the result is quite simple.
I gave a first shot at prototyping with a teensy, R78 for power regulation, an Attopilot voltage + current sensor and an Olimex LCD display, everything powered by a 100W polycrystalline solar panel (some pictures to come).
I had first naively assumed that I wouldn't need a UVLO (remember that the whole idea is to have no battery, no sun = no power), but I realize this is not a realistic proposition, since each circuit has a different undervoltage sensitivity, I can't assume they would shut down and (mainly) reboot gracefully when power is restored if this isn't done in a controlled way.
For the same reason, most likely, some circuits will be reset on a regular basis.
It's about 100x70 cm, weight about 9 kg (although it feels lighter when I carry it). It's a polycristallin one, and graded 100Wc for a cost of 99 €. Connectors are MC4. It's encased in aluminium, and the box is "bad weather" grade, although I doubt very much it's "underwater" grade, so something will have to be done here.
The on-board computer as of 2015, July the 20th (click to get a full-size image).
My thoughts have oscillated between two shapes / materials: a styrofoam torpedo shaped boat, or a catamaran.
The altitude is taken from the GPGGA GPS message, and the on-board computer was using field 10 (altitude of geoid above mean sea level) instead of device altitude (field 8).
I've taken advantage of my training flight yesterday (I try to fly once a week) to take the on-board computer with me. Here's the run.
And yet another lesson learned from this test (the more you test, the more you get something): the GPS altitude doesn't make its way to the data server ! I haven't found the bug yet, the code seems ok in the MCU.
Speed and vertical speed are computed on the web server side using the GPS coordinates, time and python geopy for the distance computation (which implements the Vincenty formulae).
On the on-board computer side, almost everyhting is ready, but the resilient-to-something-stop-working is still to do. I'm still considering using ChibiOS (the alternative being using various libraries with timeout in all the serial / I2C / SPI communications). But then, I would rather compile from the command line, and although having tried many (arscons, sonsduino, ino), I still haven't found a make or scons approach that allows the easy compilation of the zillions of files necessary.
I had stupidly assumed the values from the GPS were decimal while they really are DDmm.