First Commit

This commit is contained in:
2024-12-02 15:11:30 +01:00
commit 031f6004de
4688 changed files with 441558 additions and 0 deletions

View File

@@ -0,0 +1,55 @@
---
aliases:
- BMS
---
# Research
A [battery management system](https://en.wikipedia.org/wiki/Battery_management_system) (or BMS) is a system that manages a rechargeable battery (could be a single cell or multiple cells as a battery pack). It's main goal is to keep the battery in its safe operating area, which is usually defined by a temperature range, a voltage range and a current range that cannot be exceeded. Additionally, it might measure data (voltage, current, state of charge, etc.) and report it externally, and oftentimes it also makes sure that a battery pack remains balanced (difference in cell voltages should be as close to 0 as possible).
## Important Properties
- [Voltage](https://en.wikipedia.org/wiki/Voltage "Voltage"): minimum and maximum cell voltage
- [State of charge](https://en.wikipedia.org/wiki/State_of_charge "State of charge") (SoC) or [depth of discharge](https://en.wikipedia.org/wiki/Depth_of_discharge "Depth of discharge") (DoD), to indicate the charge level of the battery
- [State of health](https://en.wikipedia.org/wiki/State_of_health "State of health") (SoH), a variously defined measurement of the remaining capacity of the battery as % of the original capacity
- [State of power](https://en.wikipedia.org/w/index.php?title=State_of_power&action=edit&redlink=1 "State of power (page does not exist)") (SoP), the amount of power available for a defined time interval given the current power usage, temperature and other conditions
- State of Safety (SOS)
- Maximum charge current as a [charge current limit](https://en.wikipedia.org/w/index.php?title=Charge_current_limit&action=edit&redlink=1 "Charge current limit (page does not exist)") (CCL)
- Maximum discharge current as a [discharge current limit](https://en.wikipedia.org/w/index.php?title=Discharge_current_limit&action=edit&redlink=1 "Discharge current limit (page does not exist)") (DCL)
- Energy [kWh] delivered since last charge or charge cycle
- Internal impedance of a cell (to determine open circuit voltage)
- Charge [Ah] delivered or stored (sometimes this feature is called
- Total operating time since first use
- Total number of cycles
- Temperature Monitoring
- Coolant flow for air or liquid cooled batteries
# Development
A great overview on the important characteristics when designing a BMS can be found on [monolithic power's website](https://www.monolithicpower.com/how-to-design-a-battery-management-system-bms).
The system consists of an analog front end (AFE) and a fuel gauge section.
## Analog Frontend
The AFE handles the following:
- cell balancing
- main low-side sense resistor for current measurements
- main high-side mosfet control to connect/disconnect the battery. Can we use this as an on/off switch?
## Fuel Gauging
Article used: [chapter 3](https://www.ti.com/lit/ug/sluuco5a/sluuco5a.pdf?ts=1698826671597&ref_url=https%253A%252F%252Fwww.google.com%252F)
This expression comes from the car industry, where they tried to measure the remaining fuel available in the tank. In modern times, we use much more batteries as power sources and the term fuel gauging survived the ongoing transition. For batteries it means how much energy is left that we can safely take out of the battery?
Texas Instruments has a technology called Impedance Track (IT) that models the battery and estimates the remaining state of charge.
The main factors are:
- measuring Qmax
- measuring cell impedance
- calculating capacities
### Factors
**Aging**: every cell has aging effects. Qmax and cell impedances can account for ageing effect as the cell is cycled.
**Temperature**: the temperature is an important factor of the available charge left in the battery
# Glossary
| Definition | Meaning |
| ---------- | ------------------------------------------------ |
| Qmax | amount of charge available in fully charged cell |
| SoC | State of Charge (in %) |
| OCV | Open circuit voltage |
| DOD | depth of discharge: during no load condition |
| | |

View File

@@ -0,0 +1,43 @@
I think the best development and documentation approach is the following:
- README: detailed documentation of everything, version controlled with iterations. We can also have multiple .md files instead of just one.
- requirements
- design decisions
- components search (IC comparison, connectors, etc.
- Bringup instructions
- soldering instructions
- debug instructions
- reference to design documents (e.g. from TI) in resource folder
- Software needed to use the pcb (maybe link to board software package repository)
- gitlab:
- track possible requirements for future iterations as issues tagged with `requirement`
- track issues during reviews --> also acts as discussion for design decisions --> when decision is taken, the issue should be referenced in the README
- confluence: We can also track this in gitlab as CONFLUENCE.md and then import it into confluence
- have a summary of the README that is focused solely on the usage of the pcb.
- should look like a datasheet:
- min max voltage, min max current, etc.
- minimum connections needed
- if needed instructions on how to flash software or use software to program correctly
- Should have a small troubleshooting guide that links to more detailed instructions in the README
- should have a dos and donts section: what not to do at all costs.
- Finally the google drive should be used solely for [[PCB Testing|test tracking]] and detailed test documentation with the templates that we have for development

View File

@@ -0,0 +1,46 @@
# Process
Generally speaking the review process happens twice, once the schematics are finished, before the design starts and then once the actual PCB-design is done.
## Schematics Review
1. Component selection: do all components fulfill their requirements?
## Board Layout Review
This review happens after the placement of the components is finalized and before routing. The step file of the pcb including all component 3D models should be integrated into the CAD of the device. Also include cables in the mechanical review.
This review should happen between the mechanical team, the assembly team and the electronics team.
1. Is the general shape correct
2. Does the mounting system work?
1. including accessibiliy to connectors or other interfaces when mounted?
2. including stack height when cables are connected
3. are the major subsystems at the correct location on the pcb?
1. Are connectors at the correct location to minimize cable length
4. Revisit component selection: does the component size make sense? Do connector sizes make sense?
Once this review passes make sure that all components are ordered and available.
## Design Review
This review happens after the PCB got routed and is ready for production.
1. Create a PCB Design Review Google Sheet from [this template](https://docs.google.com/spreadsheets/d/1-4jNAzJX_8TotVCinnkB4rk5VresIWIjQV7i3lEITDk/edit).
2. Open the 3D view in Kicad (alt + 3) and review the mechanical properties
1. mounting holes? Stacking height of connectors? Does it fit at the place where it is intended to fit?
2. overlapping components?
3. Does the Silkscreen look right? Is it clear what pad is what? and what connector is what? Polarity?
3. check main ICs first:
1. split PCB into several sections, one section per main IC.
2. double check datasheets and their design recommendations for every IC. and check if the recommendations are applied as accurate as possible
4. Then follow generic checklist for the rest of the pcb review (see google sheets linked below.)
### Production Files Review
Finally the gerber files, drill files and any files that are shared with the manufacturer should be exported and reviewed as well.
# Tools
## Gitlab
We use gitlab, git and Kicad for the design process. This allows us to have a versioning history of the PCBs and collaborate easily across the globe. Gitlab is also a great way to track open features that we need to implement, possible issues we come across or future ideas that might want to be added to a certain board. Within the gitlab issues we can have conversations about a certain decision and they are always in one place to understand the reasoning for a decision even later on. Slack can be used to discuss issues and we can link discussions between the two tools.
Every gitlab project should have a README.md which is the main landing page if someone wants to work with that specific PCB in more depth. (Could we sync the readme with a Confluence article? - [seems possible](https://github.com/zonkyio/confluence-sync/blob/master/README.md) - this would allow non-technical users to have documentation).
## Diff Tool
Since KiCad is open source there are people that build tools to improve the development process. The tool for version comparison that we use is [KiRi (Kicad Revision Inspector)](https://github.com/leoheck/kiri) and we're using it for reviews of later versions to see what has changed since the last iteration.
![[Pasted image 20240129105628.png]]
## Test Tracking Tool
## Google Sheets

View File

@@ -0,0 +1,6 @@
The drone company Freefly has [published extensive testing documents](https://freefly.gitbook.io/freefly-public/products/alta-x/testing/test-documentation) of their drone Alta-X. Basically they have a google sheet that summarizes all tests and some high level information about those test and then there is a detailed test report linked to the main sheet.
![[Pasted image 20240130152623.png]]
I have created a template for both the [overview sheet](https://docs.google.com/spreadsheets/d/1ZVGZX8_EhPCgwdFf9EMEJC3kuFvgf5XS2nXmJZtcvYs/edit#gid=0) and the [detailed test report](https://docs.google.com/document/d/1f-5OXSd6dn2Ha0qU43wb2jsbQDjBMwj65kqMBwrAo80/edit#heading=h.qi86e7v7x1qw) for PCB testing, which can be created at the start of every project. Whenever the designer has an idea of what should be tested, it should be added here immediately.
Obviously this concept can be extended to the the mechanical hardware, the software as well as the entire drone as an integrated test.

View File

@@ -0,0 +1,6 @@
# Dos and Don'ts
- Every [[copper]] patch on the PCB must be electrically defined (and thus mostly grounded). If they are left floating, they can act as
# Examples
## Heatsinks and Grounding Strategies
- It is recommended to ground heat sinks, because if they are placed above high frequency ICs (>100MHz), parasitic currents can build within the heatsink making it act just as a huge antenna and thus creates electromagnetic radiation (EMI). This might cause the entire product to fail compliance tests or might cause problems in other sensitive circuits close by.

View File

@@ -0,0 +1,26 @@
The servo used in the Payloadbay behaves quite weirdly. Currently we use the standard PWM signal at 50Hz with a on-period between 800-2200 microseconds. As is visible in the scope-shot below.
![[Servo_no_noise.png]]
Whenever there is a load on the servo it becomes acoustically very noisy and the current draw goes up significantly, which makes sense. But even if I stop the servo at a certain location the noise continues. In the scope on the signal line you can clearly see spikes at roughly every 2.7 milliseconds.
![[servo_noisy.png]]
___
# Experiments
## Current draw
When making the sound the servo draws roughly 0.5A.
## Voltage Drop of the Supply
In purple we measured the power supply of the servo, while it was making the sound and in yellow the signal. We can observe a voltage drop of roughly 0.5V in the power supply at roughly 370 Hz.
![[SDS00002.png]]
![[SDS00003.png]]
Since both the power supply and the signal are affected it can also be the ground reference that has changed, even though the voltage drop is smaller in the signal than in the power supply.
# Possible solutions
- just turn the servo off
- program the servo (torque limit, PID-values)
- a flyback diode across vcc and gnd
- a large capacitor across vcc and gnd
- power supply that is not powerful enough.
- use the commanded signal to overshoot quickly (to pull it further) and then back to the desired value. This would help to imitate a larger P value to overcome the friction.
- use feedback signal (ideally from the servo itself, or from an additional sensor)

View File

@@ -0,0 +1,15 @@
---
aliases:
- Buck Converter
- Boost Converter
---
# Buck Converter
A buck converter, also known as step-down converter, converts a high input voltage into a regulated lower output voltage, by switching the supply on and off at a high frequency and filtering the output.
# Boost Converter
A boost converter, also known as step-up converter, converts a low input voltage into a higher output voltage by leveraging the stored energy in an inductor to increase the voltage (because no large current can flow).
![[Pasted image 20231120095014.png]]
Screenshot from [this video](https://www.youtube.com/watch?v=9QM55r5fnUk&ab_channel=TheOrganicChemistryTutor).
# Resources
http://www.runonielsen.dk/Buck_with_subharm.pdf

View File

@@ -0,0 +1,36 @@
# Glossary
| Name | Meaning | Name | Meaning |
| ---- | ---- | ---- | ---- |
| Ambient Temperature Ta | Temperature of Air around IC | Junction Temperature Tj | Highest temperature in a semi-conductor |
| Thermal Resistance \[°C / W] | Ability to dissipate internally generated heat. Increase in Tj per dissipated Watt of Power. This value in the datasheet is usually empirically determined. | Case Temperature Tc | Temperature of the case |
| Maximum Junction Temperature Tjmax | device must be kept below this, else it stops working | Power dissipation Pd \[W] | Power consumed during operation |
| | | | |
# Introduction
Junction Temperature Tj is affected by:
- ambient temperature Ta
- Airflow / or other cooling methods
- IC packaging material and technique (flip chip vs wire bond)
- PCB material
- Heat from other sources
The junction temperature can be decreased by adding airflow or heat sinks but it will always be above the ambient temperature.
# Cooling methods
All cooling methods basically reduce thermal resistance.
The most effective way to transport away the heat is to have a large via array below the IC to move the heat through the pcb copper to the opposite layer and distribute it into the entire board. From there it will then go into the sourroundings.
# Modeling
A good explanation can be found in [this video](https://www.youtube.com/watch?v=RV6b9horB-I&ab_channel=PowerElectronics) by Martin Ordonez.
![[Pasted image 20240220154606.png]]
Heat transfer happens as conduction, convection or radiation, whereas in PCB design its mostly conduction that is important (convection is important for heatsink calculations, but those can usually be found in their datasheets).
A thermal resistance is used to model the process (just as an electrical resistance):
![[Pasted image 20240220154835.png]]
The thermal resistance depends on the material, the length and the area of the conduction path.
Towards the end of the video you can find details on how to calculate the final junction temperature in different scenarios (no heatsink, heatsink, forced airflow).
# Sources
- [Infineon Guide](https://www.infineon.com/dgdl/Infineon-AN4017_Understanding_Temperature_Specifications_An_Introduction-ApplicationNotes-v11_00-EN.pdf?fileId=8ac78c8c7cdc391c017d071d497a2703).

View File

@@ -0,0 +1,8 @@
# Feedback Servo
Feedback servos have a fourth wire that sends the position information of the sensor back to the controller. It is the same feedback information that the servo uses internally to do the PID-position-control.
# Programmable Servos
Programmable servos
# Reasons
1. Initialization: when we start the Flight controller it will initialize the servo signal to the PWM value specified in the `PWM_MAIN_5_DIS` parameter. If the servo is physically at a different location during startup it will slam the servo to the correct position which is a large strain on the system (servo as well as mechanics) and will result in a large vibration.
2.