PT3 PCB Design and Discussion

[Kellan_C]

PT3 PCB Ideation

As we begin on the next round of PCBs for project quiver, I thought it would be nice to consolidate some ideas to inform our future development.

Here are a few thoughts I have had from my experience assembling and testing version 1.

Contents:
[[#1. Multiple Board Architecture]]

• [[#Modular Advantage]]
• [[#System Divisions]]
  [[#2. Notes from Assembly]]
• [[#Harnessing]]
• [[#Observability]]
• [[#Multiple Assembly Methods]]
• [[#Fault Tolerance]]
  [[#More to Come]]

1. Multiple Board Architecture

A single board architecture is great for a fully refined end product. In our case we may actually gain more advantage by dividing our system into modular boards to handle individual functions more efficiently.

Modular Advantage

There are a number of approaches to take in dividing the whole system into modules, which we may look at later. First, I would like to highlight some of the advantages in doing so, regardless of the approach to creating sub-systems.

1. Modular Improvements: In the prototyping phase, we should expect to have some parts that do not work, or perhaps do not work as well as we intended. This is perfectly normal. If we find that we have some issues with our CAN or pre-charge circuits, we will need to completely redo the PCB with those challenges. However, if we split our system into signal and power boards, we would be able to make an adjustment to one while still testing and validating the other in our system. This would give us faster iteration cycles, as we would not need to wait for a “major version” revision to implement changes to a given sub-system.
2. Parallel Collaboration: Similar to in software development, by designating responsibility for sub-systems to different contributors, we can have multiple engineers working on modules simultaneously. Also as in software development, this requires a contract on how these systems interface with one another.
3. Open Source Work: Part of the ethos of Arrow Air and Project Quiver are the contributions to open source drone hardware work. I would predict that having more “modular” boards and systems would have a greater positive effect on the community. A single monolithic board might be performant and functional, but a modular system will give future creators more freedom to build.
   1. Perhaps a user needs a hexacopter instead of a quad. They may then only need to exchange the pre-charge ESC power board for one with six power outputs and they will be on their way.
   2. Or perhaps a builder is deploying a submarine, and needs inspiration for connecting signals and actuators. They would only need to borrow the signal PCB, leaving the more overtly drone-related PCBs alone.
   3. Largely, this has been the advantage that has propelled Pixhawk to such stardom in the drone world. It is not opinionated. It allows a user to build a system around it as they see fit, which means it can fit into more systems. Especially given Project Quiver’s intention to be multi-purpose, this flexibility should be central to the architecture of our systems.

System Divisions

If you have been convinced of the utility of a modular hardware system, we still have plenty of room to argue about how the modules are defined. Generally, we would expect to define sub-systems that share a meaningfully similar scope. As you may expect, there are many ways to do this. Here are a few starting examples. Each of these may be sub-divided further as the engineers see fit.

1. High and Low Power: One system which cleanly joins our ESCs to our battery, with requisite pre-charge circuitry. A second board may handle “everything else”, including all systems 12V and below, and the CAN and signal communications.
2. Power and Signals: there may be legitimate reasons to isolate our signal lines from the power applications of our drone. One board could contain all of the power from the direct battery, the 12V, and then the 5V lines. The second board would be responsible only for the routing of signals to different systems.
3. Core and Peripheral: if we anticipate users developing their own custom attachments or peripherals for our system, we may want to allocate a separate board for helping them accomplish this. The core board would handle everything that is strictly necessary for the drone to operate independently. We would then add a second board with power, signal, and auxiliary functions to make development as easy as possible. Think of an Arduino.

These are, of course, not the only ways to divide the system into different modules, and they are not mutually exclusive.

I am partial to the idea of having the ESC’s and the full pre-charge circuit dedicated to their own board. Especially given some of the challenges with in-rush current and shorting that we have had, I think it makes sense to try to make that robust and isolated from the system.

Of course, this would not mean that we could not also have a separate board dedicated to managing peripherals for later users. Again, if there is an established contract to interface between these different modules, we should be able to iterate over each of them independently.

2. Notes from Assembly

After taking some time to work with and assembly the PT1.5 board, I have some quality of life suggestions for our next one.

Harnessing

Nobody seems to agree with this one, but I am going to ride for it regardless. I really would like to see our next prototype have the fewest possible cables that we need to hand build or assemble ourselves. Naturally I don’t expect every single cable will be something straight off the shelf, but I would like to see some organization that helps us leverage the most pre-built cables that we can.

We spent a few hours debugging a faulty system that occurred due to inconsistent contact in a cable that I had created. Heartbreaking. In my experience, creating cables is one of those things that looks like it will be fast and easy, but ends up taking a lot longer than we may expect, often with results that are hard to verify.

A possible change for a future board might include looking for a standardized connector interface. DroneCAN has published some guidance for two in particular that look interesting:

1. JST GH: The connector with which we are all familiar.
2. M8 B-Coded Connector: screws in, reasonably compact, standard usage, can can be panel mounted. I might not necessarily advocate for it over the Euro screw terminals, but if we had some CAN cables we did not know how to terminate, this might be worthwhile.

We can read more about that from the DroneCAN site, old UAVCAN site. Because it is a 5-pin connector, we can also include power lines for peripherals that need it (such as our ESCs).

Observability

This is an important but often overlooked part of a PCB. Especially in prototyping, We want to be able to quickly and correctly surmise the state of our system. Could include using led indicators which is quite common, and also exposing pins for an oscilloscope or multimeter reading.

PCB Test Points: These can help make it easy to observe the state of our PCB without needing a permanent fixture. Highly recommend getting a few of these. Read more

Status LEDs: Allow a user to determine a fault state or active state without needing any additional hardware tools.

Multiple Assembly Methods

I am not aware of specific language to describe this idea. I have seen it referred to as “Dual-footprint design”, “hybrid assembly layout”, or maybe “selective population”. The major idea here is that an end user can elect to populate their board with either SMD components or through hole components based on their technique for assembly. If the board is being fabricated with components, then it will require SMD components. However if we are doing small batches or hand assembling them it will almost always be easier to use through hole components.

Our future designs can accommodate both of these approaches with this hybrid assembly layout. Read more.

Fault Tolerance

Last one needs no introduction. In our efforts to successfully assemble our PCB, we have run into a number of challenges with faults causing failures in critical components, setting development back a few days until replacements arrive. We should hope to design systems that are resilient against user error.

More to Come

These are just a few thoughts from my time working on our last hardware efforts. I would like for us to use this thread to share other ideas for future iterations of our hardware, and possible concerns that may not have been addressed here.