Almabraxas/Roadmap

"Creativity is intelligence having fun"

This is the roadmap for the Almabraxas project. The aim of the Almabraxas project it to fly high altitude balloons, have robotic boats cross oceans, and may be other stuff, for the purpose of fun and (my) children inspiration.

Initial thoughts

• Keep It Simple Stupid
• One new feature at a time
• Software occupies no space on the PCB, it has no weight and no power consumption, but is actually the most complex part (certainly the one you spend the most time on).
  • Corollary: use the same on-board computer (and software) for everything, in particular the balloons and the roboats, instead of rewriting / redesigning everything everytime.
• Power management is difficult, use different power sources each time necessary.

Computing

For more details and timely advances, see Almabraxas 2 engineering notes and log

Initial on-board computer

Arduino, brain storming, and Teensy 3.1

The problem with Arduino (Uno), is that, for the boat, the MCU should have at least 2 serial links (one for GPS, one for modem), preferably one more for debugging, and the ability to drive a servo (PWM) for direction at the same time. After several efforts to have multiple serial ports on the Uno at the right speed (using a combination of AltSoftSerial and my own driver), I dim the task too complex for the Uno, and decide to drop it in favor of another MCU. Now there are several possibilities. An obvious one is to use the Arduino Mega, but whatever the choice, I lose the mechanical compability with Arduino (Uno) shields, so we can use an entirely different board.

Furthermore, for a moderately complex system, it may be easier to go with my own PCB rather than trying to assemble several modules, thus an MCU that fits easily on a PCB is a nice to have feature.

Last, for both crossing the Atlantic and high altitude ballooning, satellite communication seems easier to achieve than radio (like in APRS) communication. The device I found is the rock 7 rockblock. It can exchange kind of short text messages ("Short burst data").

After having considered all that, since Teensy 3.1 has all the needed capabilities, is very powerful, cheap, and compatible enough with the Arduino so I can test it in a matter of hours, I go for the Teensy 3.1 as of May 2014.

Furthermore, using such a powerful card opens the door for a more sophisticated organization of the software, i.e. using an RTOS for running different tasks rather than a "hand written" scheduling of operations.

Software organization

Basically, there are the following tasks:

• read the position from the GPS
• read some sensors (like altitude, temperature, battery level, humidity)
• (for the boat):
  • Compute new course
  • Set course correction
• log parameters on local storage
• log parameters on telemetry, if enough time has passed since last report

The communications between the MCU and the other components take place on today's electronic links (serial, I2C, SPI, you name it). We must keep in mind, that any component may fail to respond. This is particularly true for the balloon, since it may be exposed to out-of-specifications environmental conditions (temperature below -40 C, possibly quite high level of ultraviolet radiations and so on), so we must plan for failure here: every communication call between the MCU and other components must take timeout possibility into account.

Two possible refinements to the task list are:

• Ability to change programming on the fly (at least the planned path for the boat)
• Ability to react instantly to message sent to the on-board computer, that is processing of the "RING" capabilities of the modem. This is not possible with a single (untasked, uninterruptible) loop.

In conclusion: although implementation seems possible with a single loop, we may have to switch to a more sophisticated environment at some time, that is a RTOS.

New conclusion (2015/09/15), actually, the prototype software is very advanced with a single loop (see the engineering notes), so I'll stick to it, even if things are a bit tricky (you have to check for timeout in every module), and timeout isn't managed everywhere yet.

The MCU programming *** we are here today ***

(done in normal font, to do in bold)

• General organization of the software
• Reading both UARTs (GPS and modem) in parallel with no glitch
• Uing a "clocked queue" to talk to the modem (so as not to send a command if the modem hasn't answered the previous one)
  • done, but doesn't give good results, in particular with the modem. A different strategy's needed there).
  • With timeout
  • Process answers from the modem (like signal strength query)
  • Process "RING" messages
  • Pass commands sent to the modem to a module for action (remote control of the program)
    • With digital signing (to avoid someone sending a command to the module)
• Reading from the BMP180 pressure + temperature sensor (it's on the I2C bus)
  • without blocking UARTs reading
  • Robust to sensor stop responding
• Logging to SD card
  • (using DMA so as not to slow UARTs reading writing)
  • without blocking UARTs reading
  • with one directory per year+month and a file per day
  • with a monotonic time (the file used must be the last one, even if the MCU was reset and the time, taken from the GPS, isn't available yet / at all)
  • Robust to the SD module / SD card stop responding
• Encode the report message to fit into an Iridium SBD, see 2/Transmission frame format
• Send the message through the modem !
  • Done ! Although more work is needed on the scheduling of communication with the modem, a first transmission was successful

Modem messages reception

Nothing special here, the satellite provider's gateway calls a web script through https.

It's very fast by the way (about 1 sec between message emission and script call).

Web site display

Is at http://tronche.com/almabraxas/

• Panel part
• Time series
• Map display
  • Trail of previous points
  • Window (display of data in a rectangle)
  • Symbolic display of heading and speed
• Display engine
  • Pull and display data
  • Ticker (the data that have changed appear as inverted video)
  • Pull previous data, so when you go on the page you get the all serie of data

Tests

Field test

Done, see first field test.

Rotation test

The point here is that the balloon has a tendency to rotate along it's Z (vertical axis), so we have to be sure this doesn't prevent the GPS and (especially) the modem from working.

In flight test

Done, see in flight field test.

High altitude Balloon

(to check on-board computer)

Power

A single 6F22 battery should be enough to power the on-board computer and associated devices for the typical duration of a balloon mission (a few hours), but we have to save energy when possible.

Most electronic circuitry can be powered with 5V, so by starting at 9V, we don't need a boost machinery or something, and can extract all the battery juice before it dies. Energy savings are important, so we favor a switching regulator over a linear one.

Two caveats:

• the rockblock satellite modem can draw as much at 450 mA when charging (!), so the battery / power subsystem must be able to deliver it, without the MCU going brown.
• The balloon works (potentially) at very low temperature.

Having considering all that, we go for lithium batteries, both for their ability to deliver (relatively) high intensity and perform better than other kinds of batteries at low temperature.

The first field test suggests that two batteries in parallel are necessary for having a security margin.

The camera(s) are powered by their own batteries.

The capsule internal heating is achieved by the way of chemical means, like "glove heaters".

Roboat

Power

We have at least 3 methods:

• Sailing
• Gasoline (like a traditional cargo)
• Solar powered

Sailing is certainly a proven method, with the ability to convert large amount of energy into propulsion. However, it's (in my opinion), prone to capsizing, and,always in my opinion, it's not easy to build un-capsizing capabilities into a robotic boat. Furthermore, navigation is a bit more complex, since you have to control at least two parameters (direction and adjustment of sailing), while with a power boat, only direction is of real concern. So we'll save this option for later.

Gasoline is another proven method, with a power superior to what you can get with sailing, however it's also the more costly, so again we save that for later.

Having excluded more exotic capabilities such as wind power (in the sense of a wind turbine) because I don't master them, and am not sure they could deliver enough power, we're left with solar power. Although photovoltaic conversion doesn't provide much power, it should be sufficient. After all, even planes like Solar Impulse are powered this way nowadays.

Power constraints the hull in some way, but since I made my mind on power, this has to be taken as an input for the hull.

Hull / structure

Must be a multihull for easy stability (catamaran or trimaran).

Must be self-stable and able to get afloat if capsizing by the only virtue of its shape (most difficult part, but I think is achievable with a large floater on the upper part and a weight on the lower part.

• as of 2015/05/26, I'm revisiting this idea. A torpedo-shaped polystyrene hull, keeled by a trolling propeller could do the trick, given it has fins to stabilize along the rolling (longitudinal) axis. However, there's a space problem with this design: if the solar panels are 150x100 cm (and weight about 10 kg), we need the roboat to be more than 100cm large, thus either we're constrained to small beam-to-hull ratio (something like 2:1), which I feel is not enough, either a long hull which would be to difficult to handle and move in dry conditions.... Still need to give more thoughts.

Cross The Channel field test

(to check for bad weather endurance)