
In order to handle the photographic challenge, the program uses the same approach as the original Nadar: following a script

To deal with the simultaneous issue of datalogging, the program uses a similar system of “timed events”. The same loop that handles waiting for the next timed camera command also checks if, for instance, two seconds has elapsed since the last pressure & temperature logging – if it has, it logs the current pressure/temperature, and resets this timer as well. This same process occurs (with varying timed intervals) for engineering data, heater checks, etc. There’s no reason to do these in multiple parallel sequences… after all, most of the time all these would be just sitting around “waiting” for the right time to elapse. So instead, they all sit in the same loop being checked in series. This means the program can execute faster as well. The internal temperatures and the state of the internal heaters are also handled by this “timed event” strategy, so the program is fairly easy to troubleshoot – most of the sections are working the same way.
There’s a lot of data to record as well: ambient pressure, three different temperature sensors, external light level, the angle (or pitch) of the platform, NXT battery voltage, when each picture was taken (& if it was a picture or video), when the platform angle is changed (& how loud the motors sound during this event, as well as the background noise level, and how loud the NXT “Beep” sounds at this point as well), the two-second average acceleration and sound level, etc. To put as much as possible into the datalog, all this information is “compressed”, using a very simple data compression scheme coded up in NXT-G, that packs information about twice as dense as a text file “normally” would. The bit that does the datalogging and data compression is all in a self-contained My Block to make things easier – you wire in the information, and it handles writing it to the file, opening a new file if the old one is full or flawed, timestamping it, and compressing everything.
On top of all this, the program can switch to a different photoscript just by changing a single variable. Taking advantage of this, when the program detects a free-fall event (like when the balloon bursts), it will switch photographic scripts, as well as change the frequency of datalogging certain variables, so it can adjust its behavior under its own control during the mission (hey, otherwise it’s not a robot, right?).
How big is this complex, multi-tasked program? Remember, I need to save as much space as possible for datalogging all the information from this multi-hour mission as well, so size is critical. Well, it turns out on the NXT it occupies only about 20k – under 20% of the available memory. The “secret” (if that’s the right word) is that I simply reuse code – I do not follow the more common “string of Motor blocks” style that often gets used in many NXT-G program I’ve seen. The result is a program with 25 different My Blocks, interconnected and repeatedly calling each other on multiple levels

Please note this is not because I’m a genius, or that I’ve deep insight into the minds of programmers (I’ve never had a programming class in my life), or anything like that. I’m just following where a modular language like NXT-G leads me… and curiously, it’s led me to write code that is far more modular and compact than I ever ended up doing in text-based languages.
OK, that’s it – tomorrow is the launch, and we’ll see what works (hardware, software, etc.)… and what doesn’t. Cross your fingers… and watch the tracking links on the HALE website to see where these payloads are going "as it happens". I'll also be blogging on this tomorrow during the actual mission.
--
Brian Davis