The Infinite Zenith

Where insights on anime, games, academia and life dare to converge

Kanata no Astra and Building the Software Components to the Can-U-Eat-It Kajigger: An Exercise in Application Design

“Man can live about forty days without food, about three days without water, about eight minutes without air, but only for one second without hope.” –Hal Lindsey

The latest round of Jon Spencer Reviews’ #AniTwitWatches event came to a close earlier today, and this time around, 2019’s Kanata no Astra (Astra Lost in Space) won the popular vote for the anime that the community. I thus embarked on the journey with the other participants, and swiftly found myself blown away by how well-executed this series was. A routine planet camping trip goes pear-shaped and the students, Kanata, Aries, Quitterie, Funi, Charce, Luca, Zack, Yun-Hua and Ulgar are made to survive and make their way back home. Along the way, the crew come to know one another better and deduce that theirs was no accident; there was some sinister plot to use a school trip as a convenient excuse to bump everyone off. Through this experience, however, the Astra’s crew come to develop as a team, cooperating and using their expertise to help advance survival in their own way. Kanata no Astra‘s themes of teamwork, the idea that everyone brings something to the table and that solutions come from the most unexpected sources were particularly strong, and the anime has taken a particularly strong approach towards its presentation of the sciences. Evolutionary biology, ecology, bioethics, sociology, climatology, space travel and engineering are several topics that Kanata no Astra make use of during its run to create a compelling and believable story. Information from every discipline is accurately presented, and to the appropriate level of detail such that viewers can be convinced of the world’s authenticity, without burdening them with excessive detail. There is no denying that Kanata no Astra is an exceptional anime, striking a balance between comedy and growth, as well as mystery and enigma. Episodes often swing between light-hearted exploration, grim survival, and the ever-present threat of a hidden foe amongst the group, as well as the lingering question of how chance brought everyone together. The sum of these elements in Kanata no Astra means that the anime offers no shortage of materials to talk about, and indeed, each and every episode provides a topic that could be explored in a paper. However, precisely because Kanata no Astra is so expansive in its breadth, I could be here for the next year outlining all of the science and history that Kanata no Astra gets right, from the ecosystems on Shummoor, to the accurate portrayal of life on the tidally-locked Icriss, the implications of cloning and the significance of never forgetting history. This would be to the readers’ detriment, and so, I’ve opted to go with something a little different this time around.

After the shock of survival wears off at the end of the second episode, Zack constructs a device called the Food Component Analytical Device (FCAD), known informally as the Can-U-Eat-It Kajigger (or for simplicity’s sake, TESTER), to determine whether or not the various flora and fauna they find are edible. This little contraption is only a secondary part of Kanata no Astra, but its importance to the series cannot be understated: Les Stroud has previously indicated that in a survival situation, people typically place a great deal of effort into finding food and go into a panic when rations dwindle, despite the fact that the average human body can go for three weeks without food. While Stroud places an emphasis on finding water (the body cannot last more than three days without water), it makes sense that the Astra’s crew are concerned with finding food: it’s a process that keeps the mind focused, and in a survival situation, being proactive and busy prevents one from wallowing (in turn reducing the risk one loses the will to live). However, Kanata and the others face a large challenge: since they are landing on alien worlds, each with their own unique ecosystem, survival is not assured even if there was a decently-sized biome. After all, alien physiologies and composition could differ greatly than our own. It is here that Zack’s TESTER becomes important: it is able to identify whether or not something is edible, safe for consumption, and while such a device might seem like the work of a prodigy (Zack is highly brilliant) who has access to future technology, the reality is that a device like TESTER could actually be constructed using the technology and resources that are currently available to us. In this post, then, I will walk readers through the implementation of TESTER, from a computer science and software engineering perspective. This post assumes that the hardware elements are already taken care of: as I’m not a computer hardware specialist or electrical engineer, I cannot readily speak to what parts would be needed to assemble the device. However, having spent the past decade in software, it is not out of the realm of possibility to go into detail what the software layer behind TESTER would require to work.

  • Kanata no Astra is an anime that gets virtually everything right, from character development and pacing, right down to science and society. There is something to talk about in each and every episode, as the combination of mystery and comedy drives a cast whose experiences become easy to become invested in. Shortly after they accept their situation and take stock, the first thing that comes to everyone’s mind is food and water. Consequently, Kanata no Astra‘s early episodes are yet another situation where Les Stroud’s Survivorman is relevant.

  • In Survivorman, Stroud constantly points out that keeping out of the elements and securing good water is a top priority: the body can last up to three weeks without food, and as such, it is not quite as important to always top off when other needs must be attended to first. With this being said, survival also entails keeping busy, and under Kanata’s leadership, the Astra’s crew are able to occupy their minds by finding food early on, although alien flora and fauna make it difficult to know what can be safely consumed, or what shouldn’t be touched.

Preliminary Considerations

Chemical Analysis

The underlying technologies behind TESTER is likely a refined combination of Infrared Spectroscopy (IRS), Mass Spectrometry (MS) and Nuclear Magnetic Resonance pectroscopy. I know these methods best for their application in organic chemistry, where they are utilised in tandem to identify chemical compounds. IRS involves passing an infrared beam into a specimen and record the resulting absorption patterns. Different functional groups have specific characteristic absorption freqnecies (i.e. they produce specific patterns when subject to IR), and thus, can be used to identify common structural units in a chemical compound. MS entails vapourising a specimen and rendering it as a gas such that it is ionised. The molecule is broken into fragments, and these fragments have different mass-to-charge ratios. Plotting the mass-to-charge ratios on a graph gives the distribution of positive ions that are unique to each compound. Finally, NMR is used to observe localised magnetic fields around the atomic nuclei. By passing radio waves through a sample, the magnetic field around the nucleus causes a change in its resonance frequency (and corresponding energy level), which releases electromagnetic waves based on the atomic arrangement in said molecule. Nuclei in close proximity will shield one another from the magnetic field, and this in turn produces a plot of chemical shifts characteristic to the arrangement of the nuclei in the molecule. NMR is often conducted by dissolving a sample in a solution (such as deuterated chloroform) to allow for the atoms to be subject to the magnetic fields.

These three methods can be used in conjunction to very precisely identify the chemical composition of an unknown agent, and as such, are invaluable as the first step for retrieving what’s in a substance. IRS allows for chemical groups to be identified, while MS and NMR are useful in determining a sample’s molecular structure. With these techniques, we end up with a rough understanding of what a substance consists of: knowing the structure and any distinct functional groups thus allows for the overall molecular structure of compounds in a specimen to be determined. Because Kanata no Astra is set in a world with FTL-travel and appears more technologically advanced than contemporary human society, we will allow ourselves a hardware sensor that can carry out chemical analysis with high precision, employing more refined and accurate methods than is currently available built upon similar principles. In this exercise, then, we suppose that we have access to a sensor that carries out IRS, MR and NMR without destroying the sample while at the same time, properly identifying the chemicals 99% of the time. For this exercise, we also will suppose that the sensor comes with an SDK such that it is easy to properly send data into the software layer.

  • Besides the Universal Edibility Test, where one can determine if a plant is safe for consumption by first coming into contact with it and then waiting eight hours to see if a rash appears (indicating the presence of toxins), Les Stroud also gives three general guidelines for whether or not a given animal can be eaten: the animal cannot be brightly coloured, smell bad or plod along; all three indicate the presence of some sort of toxin-based defense, rendering it unsafe to eat. These methods do come with experience in the bush, and for the Astra’s crew, this is time the students do not have.

  • As such, Zack’s assembling of TESTER becomes an elegant and efficient way of sorting out the problem of acquiring food. Were this simple device not built, it may have slowed survival sufficiently as to render the remainder of Kanata no Astra poorly-paced, since Kanata and the others would constantly be dealing with low morale and energy from lack of food. Devices like TESTER are usually consigned to the realm of science fiction, but in this case, having worked with the components involved, and having seen similar technologies around, I became curious to see if TESTER could actually be built.

Data formats and databases

We will make use of the Simplified Molecular-Input Line-Entry System (SMILES) notation will be used to store strings representing the chemical compounds that TESTER uses. SMILES was designed in the 1980s to provide a means of defining expressions to represent how chemical compounds are structured using strings, which can then be parsed using a context-free parser. There are programs that allow for chemical compounds to be drawn (such as PyMol), after which the produced drawing can be interpreted as nodes in a graph and converted into a spanning tree (a tree where every node is included). From here, the string is produced based on a set of rules and returned. This makes it easy to quickly carry out string operations such as pattern matching on the chemical compound. With the SMILES standard, it becomes straightforward to now take data from IR, NMR and MS, and run queries against a database of known compounds to determine if something is edible or not. As such, the combination of chemical identification and line notation provides us with the foundations we need to begin designing the software behind Zack’s TESTER.

In order to carry out some of the functions in TESTER, it is useful to utilise a database of known chemical compounds and reactions. PubChem is an excellent asset for searching for chemicals by a range of properties, from its common name and molecular formula. Similarly, we can use a tool like the Beilstein database, which possesses around 22 million known reactions, and run queries against this. For the purposes of this discussion, we suppose that these handy functions are a part of the same SDK that accompanies the sensor units to simplify things.

Other Requirements

Having identified the main hardware component of what is required in order to ascertain the molecules inside a substance in order to test for edibility. Before continuing on, the definition of what is edible must be defined. We suppose that something is edible if it introduces no harm to an individual upon consumption and produces an appreciable amount of food energy for said individual such that they are able to sustain essential life processes. Generally speaking, the minimum requirements for something to be edible is that it must be safe to eat, but in the context of Kanata no Astra, it is not sufficient for something to simply lack poisons or toxins: some things can be consumed safely, but lack anything in terms of digestible energy for humans. Grass is one such example: while we can eat it without causing harm to ourselves, grass contains cellulose, which we cannot digest in a meaningful way to extract the nutrients out of. For the purposes of this discussion, edibility is not simply the absence of things that make us sick, but must also include the condition that it provides an appreciable amount of nutrition as to make it worth consuming.

  • There is a certain cleverness in how Zack designs the user interface for TESTER: there is a simplicity about it that makes the apparatus extremely easy to use. For operators, then, it’s a matter of jabbing the probe into a substance and then waiting for the chemical analysis to complete, then display the results back to the user. As a bonus touch, the device will also speak the results out. The hardware component of TESTER is beyond me, but aside from a battery, some sort of microprocessor, display and speaker, along with the sensor probe, I don’t imagine constructing the device would be too hard.

  • The fun part for me would be the software layer; I’ve been doing this sort of thing in industry for a shade over five years now, and previously, I was deeply involved with not just implementing apps, but also drafting out user stories, converting those into use-cases (along with fallbacks), and testing everything. While I do this as a part of my occupation, sometimes, it’s fun to use those skills and then apply them in a setting where the object is simply to share stuff. Thus, instead of writing thousands of words on why Kanata no Astra is an anime worth watching, I can write about how I’d go about building TESTER, and how this meant Astra’s crew were able to keep moving forwards with survival.

The Software Layer

High Level Workflow

This application is designed to analyse a particular substance for edibility. The user holds the device’s sensor close to the sample, and then the device returns a response indicating whether or not that substance is safely consumed. For instance, if the user were to analyse a sample of Agaricus xanthodermus (yellow-staining mushroom) tissue, the device will indicate that this cannot be eaten (with a frowny-face icon and the corresponding audio cue). Conversely, running tissue sample from Gallus gallus domesticus (domestic chicken) should return the result that this can be consumed (with a smiley-face icon and again, the corresponding audio cue).

  • Figure I: Basic workflow for the TESTER application. In this exercise, I’ve made numerous assumptions about the hardware, the existence of certain components and the fact that the resultant will have limitations (such as being unable to determine how certain compounds react when heated or mixed with other compounds, which is typical of the cooking process).

Conceptually, the workflow behind TESTER’s software component is described in Figure I: after the user submits a sample for testing, the sensor will return an array of SMILES strings representing all of the molecules identified within the sample. Then, the application will take this array and query a database of known molecules. An array of data transfer objects (DTO) is then produced and made into a model for the application. The application steps through this array to determine whether or not the combination of compounds in the sample might undergo any metabolic processes that create compounds deleterious to the body: a query is made to a separate table of reactions, and then a table join is carried out between the reaction table and known molecule table, with the latter being returned as DTOs. This second set of DTOs is returned as an array, which can be merged with the first array of existing molecules from the sample. The app takes this array and then reads it to determine whether or not there are any compounds harmful to an individual, as well as the total nutritional value of the compound. If certain thresholds are satisfied, the app returns that the entity is edible (otherwise, it is deemed inedible).

  • For this thought experiment, I chose not to design my own chemical analysis SDK or database: this post has been in my head since #AniTwitWatches’ second week, and initially, I figured it could be fun to do a little bit of database design and then write the SQL queries that produced the objects that could then feed into my app. However, working out how to organise the chemical compounds and reactions in a clear manner proved quite tricky: while I studied SQL back in university and know the basics of queries, it’s been a while since I’ve worked with more complex use cases.

  • Similarly, to prevent this post from veering off into a more implementation heavy discussion, I’ve opted not to actually write any code for the parts of my proposed system. This discussion is, in short, the equivalent of a napkin sketch of how I’d go about putting an app that can test for edibility and architect things out in a way that’s somewhat maintainable and modular.

Application Design

While this is a simple application, the model-view-view model (MVVM) pattern is a good choice for this, allowing for a reasonable separation of concerns in the app (Figure II). The view represents the UI, including anything that is rendered to any display. The view model facilitates communications between the view and the model, and the model itself represents the data. MVVM is an industry standard for mobile applications when the team size isn’t too large, being a balance between satisfactory modularity for development without being too segmented (other design patterns, like VIPER, are better suited for larger development teams and highly complex applications). The overall application architecture is described in Figure II using the MVVM pattern. All user interactions are sent from the device hardware, which informs the view model of the action that needs to be carried out. The view model will contain an adaptor class that handles communication with the chemical analysis SDK (Figure III). Information from the view model is sent to the adaptor which will make the required calls for running queries, and the results are returned. The adaptor pattern is useful here, allowing our application to make use of an existing code base and writing on top of it, creating a cleaner implementation that can be changed later to suit the application’s needs (or reused elsewhere) without tightly coupling the view model to the chemical analysis SDK. Results from the adaptor are stored in the model.

  • Figure II: MVVM design pattern for TESTER. Users interact with the view controller, which also manages the drawing of UI elements and handling user input. The view model contains an instance of the Chemical SDK Adaptor, which is the piece that will communicate with an external framework. I’ve chosen to create an adaptor that encapsulates functions TESTER would commonly use because this ensures my view model isn’t tightly coupled with the chemical analysis library (otherwise, the code would be quite challenging to maintain, especially if one were to make a more sophisticated TESTER from this starting point).

  • Figure III: speculated relationship between the TESTER app and an external library for chemical analysis. Note that the adaptor is the point of contact between the application and the external library, which we’ve supposed will hold all of the database entries, and relevant queries. Such a library would likely need to be provided with the sensor that TESTER uses, since this would make it easiest to take sensor data, convert it into a corresponding SMILES string and use this as the basis for analysis.

For this application, we will have two models (Figure II). The Substance model describes the results from a scan. It will have an array of compounds and two Booleans representing whether that substance is toxic and nutritious, overall. A compound model contains the SMILES string, compound type as a string, and two doubles representing the amount of toxin and energy value. From here, the substance stored in the view model is passed to the adaptor for analysis, and the adaptor returns a Boolean indicating whether or not the analysed substance can be safely eaten. The Boolean value is sent back to the view controller, which determines what to display to the view. In Kanata no Astra, TESTER displays an icon and plays a sound to indicate edibility, so the view controller can store a pre-set icon for edible and inedible substances. Similarly, two sound files can be stored and then played back in response to the results from an analysis. The UX TESTER provides is remarkably simple and well-designed: a more complex view isn’t needed because the goal of such an app is to denote whether a given substance can be safely consumed, so displaying an icon and playing a sound provides the user with all the information they will need to tell if something can be gathered and stored, or if it’s better to leave a certain species alone and go for pickings elsewhere. With this, we have determined the starting point for building the software layer to a real-world equivalent of TESTER.

  • Armed with this starting point, I’d be ready to actually begin building the app out. This typically means I’d go about preparing the project, laying out all of the views, view models, models, any services and interfaces the app might need, plus helper classes. I’d estimate that, assuming that the chemical analysis library was already there, it’d take me about about a week to fully bring a prototype of TESTER to life in iOS using Swift, assuming I’m working on things part time (the simplicity of the code-base means implementation would be fairly quick, and the rest of the time would be user testing).

  • Altogether, this was a particularly fun exercise to carry out and also serves to show just how much thought went into Kanata no Astra. I ended up choosing to write about TESTER because the software piece was something I am familiar with, but other topics in Kanata no Astra include ecology, evolutionary biology, astronomy, history and sociology, all of which are worth exploring. Kanata no Astra weaves everything into the story and ensures that enough detail is presented to viewers so they know what’s going on, whereas viewers with a more extensive background in something will immediately spot the connections and appreciate the work that went into creating a believable story.

Closing Remarks

  • Kanata no Astra is an A+ (4.0 of 4.0, or 10 of 10); despite being shorter, Kanata no Astra manages to fit everything elegantly into this space without ever feeling rushed, and in doing so, gave me reason to look forwards to each and every episode. From a thematic perspective, the anime covers everything from “everyone has value” and “teamwork makes the dream work”, to the implications of cloning being an ethical grey area, and the importance of preserving history to prevent future atrocities. This is easily a series I could’ve written about in an episodic fashion, since there is plenty of breadth and depth in the series to accommodate interesting discussions, and it goes without saying that Kanata no Astra has a strong recommendation from me.

The resulting Can-U-Eat-It Kajigger/TESTER application we have described here required considerable abstraction and simplification: what I’ve described above would be the equivalent to napkin sketches, a conceptual description of the TESTER device. This little apparatus appears simple on the surface, but it becomes clear that Zack’s device embodies Apple’s design philosophy, “It Just Works”; the simpler something is, the more is occurring underneath the hood per every button press. TESTER’s simple user interaction belies the complexity of the application’s underpinnings and speaks to both Zack’s skill, as well as the sophistication of technology in the future. Despite being utilised for the mundane purpose of helping the Astra team to find food, TESTER’s contributions to Kanata no Astra are nontrivial. However, while the device is a complex one, this exercise also shows that constructing such a device is entirely within the realm of possibility with existing technology, and in fact, devices like handheld narcotics analysers utilise the same underlying spectroscopic methods to quickly identify drugs in the field. We have therefore shown that devices like TESTER can easily be manufactured and produced in reality; however, a cursory glance shows that no such device exists, and moreover, testing for edibility typically falls upon more traditional methods (e.g. the universal edibility test, which includes touching a plant to see if it causes skin irritation after eight hours). It would therefore appear that there is an open field for such a device, so this raises the question of why a company like Raman, who manufactures handheld narcotics analysers, have not already expanded their product line to include edibility testers. The answer isn’t terribly surprising: beyond hunters, outdoorsmen and survival experts, ready access to food means that edibility is typically a non-concern. Moreover, survival experts and outdoorsmen are unlikely to place too much emphasis on devices that depend on a battery, as their failure in the field could prove costly. While there isn’t a present market for devices like TESTER, however, Kanata no Astra suggests that exploration of alien worlds, especially those with life, it may become important to have a means of quickly and easily determining if something is safe to eat. In a time where interplanetary travel becomes increasingly widespread, devices like TESTER could prove immensely valuable in helping astronauts to understand the nature of life on the worlds they visit. Of course, under such an eventuality, this would mean that demand for a TESTER would go up considerably. This little device is therefore the MVP of Kanata no Astra, and as I hope to have demonstrated, the Can-U-Eat-It Kajigger isn’t a conceptually difficult system to put together, providing the Astra’s crew with the ability to reliably solve for the problem of food and therefore turn their focus towards issues, resulting in an anime that was uncommonly captivating and engaging.

One response to “Kanata no Astra and Building the Software Components to the Can-U-Eat-It Kajigger: An Exercise in Application Design

  1. Pingback: The Otakusphere: Wonder Egg, Dino King and can anyone stop Goku – In Search of Number Nine — An anime blog

Were we helpful? Did you see something we can improve on? Please provide your feedback today!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: