Modularity

Modularity

Modularity is an important concept that was one of the primary focuses of HAL. It can be applied both to hardware and software.

Hardware modularity is applied to a high level, where boards could be designed to account for multiple actuation types (supporting future liquid systems) and conform to a standard size and shape. At the intra-board scale, modularity can cause serious issues, primarily when dealing with high frequency signals. Instead of making individual components replaceable, it may be better to replace larger sections of components or be able to break them out without messing up all the other components. For example, since many components on Hal-1 were both tiny and grouped together, heat-gunning components sometimes caused multiple others to be blown away or misaligned, disrupting other functions of the board. This problem is easily avoided by an experienced electrician, however not everyone is perfect. When duty calls and only one or two people can complete soldering fixes, the project can stall, as it did during the midterm season of a spring semester. It is best for ALL members to be trained and capable of completing all soldering fixes. To accomplish this, it may be prudent to do experiments on HAL, as there is working code for it. Modules on HAL can be soldered and desoldered by team members as practice.

Software modularity is arguably simpler and refers to the capability of libraries and high-level program loops to work the same way on any framework and any microcontroller. As simple C code, most sensors, math, physics, and science libraries are interchangeable between projects. One can copy an IMU library, for example, and paste it into a new project with all the code already working. Many IC designers account for this and will supply libraries on GitHub or on their website. Bosch Sensortec does this; their libraries are almost all available online. However, for other modules such as the E22 radio used last year, a custom-written library was needed. This code can be found on LRI’s GitHub. In most cases, one should not need to worry about finding a library online. If there is one, great. If not, programming a library start to finish can take as little as 2 weeks, following the device datasheet and STM32 HAL’s functions.

Hal-1.0 Modularities

Hal’s modularity initially focused on purely antennae, wiring, and IC component modularity. The LRI definition of modularity at the time was limited to physical modularities and included AV bay modularity as well. After the second flight, it quickly became apparent that such considerations were not necessary; parts could be printed or manufactured easily and extra designs for detaching components, replacing, etc. were overcomplex and could be removed. Instead, an engineer can safely prioritize efficiency and effectiveness based on technical aspects, including RF considerations, physical space, and safety.

Hal’s original modularity considerations at a low level are as follows.

AV Bay Modularity

• Detachable and replaceable segments
• Separate power, board, and RF segments
• Detachable wiring for each component
• All segments of AV bay were re-orientable and could be positioned in any rotation or order in stackup.

Hal Modularity

• ICs on Hal were spaced very far apart such that they could easily be desoldered
• Antennae could be snap-off detached

There are a couple of rather apparent weaknesses that were induced by these modularities. The first is how antennae were wired out of the board instead of attached directly. This was originally missed during the link-budgeting process, which was one of the primary reasons why the initial launch lost the board and rocket. The distance traveled by the rocket became too large, and the radio signal disconnected (an executive summary of the first and second launches can be found in the launch pages in this wiki).

Another weakness was the structural weaknesses by implementing detachable segments. The segments initially lacked a locking mechanism, as midway through the design it was decided that the segments would be fused together with heat, and epoxied. Note that if the segments had been detachable, they would have posed a separation risk in flight.

The third issue describes the lack of space caused by single wires, where for example servos with four wire input/outputs meant there would be four free wires hanging from the board. The original reasoning behind keeping wires separate was just because of prior habits. The previous avionics team used screw terminals for all wire outputs, as did the Telemega COTS avionics board. In retrospect, a better option would have been to simply solder on standard 4-pin connectors, which could hold easily and simply. Having all the wires separated did not really have any benefits during debugging beside being easier to probe with multimeters and oscilloscopes. Future teams should keep connection points safe, standardized, and common. Avoid loose wiring when able.

The final large issue was the placement of ICs on the board. Hal was an exceptionally large board, nearly twice as large as the Telemega board. This was due that all ICs were placed relatively far from each other. In order to reduce the size and impact of Hal, it would have been better to space ICs as close to each other as possible while still preserving signal integrity. The devices in use on Hal have been proven to gather good data, thus they can be placed with little worry about failure and replacement. In general, any device you’ve tested, verified, and validated on a board before can be confidently placed without test points if possible. New devices with high risk of failure or bugs can have test points drawn out for them. In an emergency, traces can be scraped to expose their copper for a multimeter or oscilloscope, but this should seldom be needed unless no other method of diagnosis is available. Keep in mind that test points take up a fair amount of space on the board and you should plan for them. Keep boards small, but don’t compromise integrity for space.

Ideas for the Future

Board Stacking

One idea for better modularity going forward is to separate the flight computer into different “suites” each housing their own dedicated systems. For example, Hal-1 may be split into four boards:

• Control algorithm computation
• Sensor reading and attitude/orientation calculation
• GPS tracking, radio send/receive

… which may be placed in areas of the rocket where they are most efficient.

This is an industry-standard method called board stacking. Splitting up boards introduces potential signal degradation, of course, but if consciously designed and accounted for then the risk may easily be minimized. Some ideas for securing inter-board connections are by utilizing RS-485 connections for long distance communication (this is explained in depth in its own section), direct board connections for short range (board-stacking, PC/104 stacking style [explained in its own section]), or simple ethernet cables for short to medium range. Of course, in-depth calculations will be needed in the consideration of each of these methods, and considerations for physical space are a must. Though space ended up not being a huge issue in the launch of Control Freak, one may desire to allocate less space for avionics in favor of fuel subsystems, pumps, and other large components. Thus, board stacking is extremely important, one could space over 4 inches of airframe space by packing avionics into a disk rather than a square board. Board stacking can significantly speed up the overall cycle time by allowing many things to be done in real-time, even blocking tasks.

Boards do not have to be stacked. Sometimes, you must send data across the rocket to a separate subsystem, and in this case, the RS-485 standard should be followed. Because it relies on voltage differential and is nearly unharmed by external noise and interference, it is extremely effective when it comes to sending data. Therefore, instead of tangling with wires, one should aim to separate board functions, especially to increase overall computation speed and/or separate actuation outputs. This is talked about more in the next subsection.

Routing Long Connections Down the Rocket

Regardless of how the board is designed, often an engineer will find themselves having to route wires to electronics from one end of the rocket to the other, such as when integrating control surfaces. If the avionics are located in the nosecone, but you need to control ailerons at the base fins, you will need to route wires down the rocket. Let’s suppose we have four ailerons, one on each fin at the base. We want to control their servos with the main computer, located at the nosecone. Each servo has four wires that need to be connected, so how do we avoid having to pack in 16 cables into the airframe?

At first thought, one would think either to ziptie everything together and route it along the walls of the airframe. But how do you solve the issue of sorting the wires? There are only so many colors, and keeping track of that many is difficult. Another thought is to use a communication protocol like UART, which is simple and easy to wire up. But how do you address potential signal degradation and data corruption?

One of the best and easiest ways to solve the problem is using RS-485 standards. The section explaining this protocol is explained in its own page. UART is not a good choice here, as are any other complex communications protocols; high speed data does not survive well over long distances. Using direct wires is not a great idea either. It’s inefficient and uses a lot of wire. RS-485 is a clear winner in this case due to its ability to be used over very long distances, often well over hundreds of meters. It is also extremely cheap and easy to implement, with components like the MAX485 easily able to be placed at both ends. To solve this problem, the best solution is to create a separate tiny board, placed at the base of the rocket. A board as small as a postage stamp could be produced, little more than a microcontroller, MAX485 chip, four 4-pin terminals, and two 2-pin terminals for power and RS-485 voltage in. This is the recommended solution for the problem of controlling ailerons.

In future, consider that fluids systems will also require a lot of wiring around. Using RS-485 allows a total of four wires to be made for components, covering power and data. Instead of controlling so many components across the entire rocket each using their own cable, an engineer can condense it down to two.

[[Images for this page will be implemented soon!]]