Last updated: 2021-06-17
Checks: 2 0
Knit directory: VSA_altitude_hold/
This reproducible R Markdown analysis was created with workflowr (version 1.6.2). The Checks tab describes the reproducibility checks that were applied when the results were created. The Past versions tab lists the development history.
Great! Since the R Markdown file has been committed to the Git repository, you know the exact version of the code that produced these results.
Great! You are using Git for version control. Tracking code development and connecting the code version to the results is critical for reproducibility.
The results in this page were generated with repository version fe8f4b0. See the Past versions tab to see a history of the changes made to the R Markdown and HTML files.
Note that you need to be careful to ensure that all relevant files for the analysis have been committed to Git prior to generating the results (you can use wflow_publish or wflow_git_commit). workflowr only checks the R Markdown file, but you know if there are other scripts or data files that it depends on. Below is the status of the Git repository when the results were generated:
Ignored files:
Ignored: .Rhistory
Ignored: .Rproj.user/
Ignored: renv/library/
Ignored: renv/local/
Ignored: renv/staging/
Note that any generated files, e.g. HTML, png, CSS, etc., are not included in this status report because it is ok for generated content to have uncommitted changes.
These are the previous versions of the repository in which changes were made to the R Markdown (analysis/design_notes.Rmd) and HTML (docs/design_notes.html) files. If you’ve configured a remote Git repository (see ?wflow_git_remote), click on the hyperlinks in the table below to view the files as they were in that past version.
| File | Version | Author | Date | Message |
|---|---|---|---|---|
| html | 712914d | Ross Gayler | 2021-06-17 | Build site. |
| Rmd | efc80b8 | Ross Gayler | 2021-06-17 | WIP |
| html | efc80b8 | Ross Gayler | 2021-06-17 | WIP |
This notebook records the thinking behind implementing altitude hold in VSA.
Limit the initial problem to altitude hold because this is one-dimensional (as opposed to fully general flight control). This is done to simplify the problem as much as possible.
Treat the VSA components as drop-in replacements for standard control circuitry.
This reduces the probability that we will hit an obstacle requiring us to completely reconceptualise how altitude hold is done. On the other hand, it means that we will parallel the classical altitude hold computation, so we may miss seeing some (hypothetical) VSA-centric solution that has no classical analogue.
The data floww diagram represents the desired calculation for altitude hold.
The data flow diagram is derived from AltitudeHoldPidController.
Each vertex in the diagram represents a value and the computation that calculates the value.
Each directed edge in the diagram represents a value flow from one vertex to another
Think of the data flow diagram as specifying an electronic analog computer where the vertices correspond to function blocks and the edges correspond to wires.
Data flow diagram goes here
Data flow table goes here
There is a very minor technical question of whether it is better to represent the external signal sources and sinks by vertices in the data flow diagram or whether those data flows should be represented by edges with only one vertex.
VSA values are very high dimensional vectors.
The values in the classical implementation of the data flow diagram are very low dimensional vectors (typically scalars).
The surrounding machinery of the multicopter simulation assumes that the inputs to and outputs from the altitude hold are classical values. Therefore interfaces are need to convert between the classical and VSA representations.
The interfaces between the classical and VSA are essentially projections between low and high dimensional vector spaces.
Replace all the edges in the data flow diagram with VSA equivalents.
Leave all the vertices in classical form.
The edges are equivalent to wires. A value is inserted at one end and retrieved at the other end. This would require a classical to VSA interface at the input of the edge and a VSA to classical interface at the output end.
This would seem to be an almost pointless thing to do. However, the classical values are assumed to absolutely accurate as mathematical idealisations. Different physical realisations will be inaccurate to some extent. A software implementation would likely represent the values as double-precision floating-point. A very constrained computer might represent the values with 8-bit integers. An analog computer might represent the values as voltages in some constrained range and with noise present in the signal.
Analogously, there can be range, distortion, and noise effects present in VSA representations. There can also be implementation noise, for example if VSA representations are implemented with simulated spiking neurons.
Such a model might have advantages depending on the implementation technology.