Almabraxas blog and engineering notes.
As a reminder, the point is that the solar panel gives ~ 22V, while the motors are rated 14.4V.
I thought a lot about it, and in my views, many strategies of reducing the voltage (like using a switching DC DC converter), will defeat the MPPT tracking using the motor as a load, one of the important point I want to check with the prototype.
So I thought even longer, and concluded: who gives a damn to the motor voltage rating ? They're running in water (a dense medium), so at a much lower RPM than in the air, and with a very efficient water cooling.
So I just ran them at 22V for two hours. Everything went perfectly well.
Bad luck, I started with a dead ESC (which I was convinced was working), and, since it was my first shot at PWM with ChibiOs, it took me a few hours to understand where the problem was exactly. However, it's working now. The 1st motor is a Turnigy DST 700. I'm using a Spider ESC for now, but I'm gonna get a few Blue Robotics Basic ESCs (they're working out of the box).
By the way, the DST 700 can only absorb 14.4V, while the solar panel can go as high as 21, so my plan is to use switching regulators (!) between the solar panel and the ESCs to lower the voltage to 12V. I just hope that regulators will degrade gracefully (that is, will output power with a lower voltage) when the voltage goes below 13V.
- SPI for radio communication (the circuit is Adafruit RFM69HCW for now) => needs SCK MOSI MISO CS + 1 GPIO for reset and 1 GPIO for interruption
- SPI for flash card communication (super high speed) => (same ?) SCK MOSI MISO + 1 CS
- I2S for the magnetometer => SCL SDA
- Serial port for the GPS => TX1 RX
- Serial port for the satelite modem (not on the prototype, but at least we count everything).
- 2 PWM for the motors
- 2 ADC for sensing the available power coming from the solar panel (voltage and current).
Thus we have
Resulting in at least 18 wires (+power).
Let's use corresponding Arduino pins on the Nuxeo board, thus using
- PB8/PB9 for I2S
- PA5/PA6/PA7/PB6 for SPI
- PB10/PB4 for the PWMs, but I'm planning to use STM32F4 TIM5 (to have 1 MHz basic clock, more on this later), so may be I'll have to switch to other pins
- PA0/PA1 for ADCs.
I'd like to keep PA2/PA3 for the satellite modem, so we'll see for using TX2/RX2 for the GPS.
For the PWM, my understanding for now is that the Afro ESC is using a 1MHz cycle (their center impulse is defined as 1000 microsec), with a 50 Hz PWM repetition. Actually, they say they have "400 values" (the PWM width going from 0 to 2000 I think), so they could actually use something like a 200 KHz base clock for their PWM, may be I'll do that, because I could use then a 16-bit prescaler and timer instead of a 32 bit counter.
I'm restarting the project and building a scaled-down prototype first to solve all the software problem on a cheaper model.
I've settled on
- STM32F4(46) for the mcu, because Chibios is well supported on it, unlike on Teensy 3.2 (and it's very cheap)
- 433 MHz radio communication to be able to have free 1-10Hz data during tuning, something impossible with satellite communication. I'm hoping a 2-3 km range, because this is the size of the pond where I'm planning to do the tests
- 25 W solar panel (instead of 2x100W)
- Hull made of EPS polystyrene, with a plaque of acrylic to assemble the components
- About 120 cm length, to have at least a 1:3 ratio, beam to hull, but it fits in the car trunk (unlike the full-scale model which is 3 meters long).
- Cheap motors (needing maintenance between each test, but that's ok)
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.