Biosystems Engineering Blog (Posts about python)

Using Running Averages in Python to Validate Sensor Data

Kurt Kremitzki — Thu, 05 May 2016 10:09:04 GMT

Handling Signals

If you are writing code to respond to sensor data, you should use a bit of logical abstraction to have clean code that doesn't become harder to work on with time. For example, at a low level, you're getting some signal, likely a voltage, that is supposed to represent another physical signal (in an abstract sense), like a distance or temperature. However, the signal you are actually accessing in the code is just a measurement, e.g. a voltage and not the true distance. At some point in the code, hopefully a well-tested library already written by someone else, this voltage signal has some math done to it and becomes a number that is hopefully pretty close to the measurement we care about. Later on in the code, in regions we are usually responsible for, it would be nice to treat that number as the real thing, and make whatever system we're designing to respond accordingly. Going in blindly, though, can be a recipe for disaster. Why?

Trust, But Verify

Sometimes physical components fail. Maybe someone's skin oil, left behind during setup or installation, is changing some overall resistance and invaliding our assumptions, and math, about a voltage signal across a wire. Water, rust, rot, and an infinite number of other failure mechanisms can plague the best-designed system, so a good rule of thumb is to trust, but verify.

Primer on Python Projects

Kurt Kremitzki — Sun, 10 Apr 2016 12:58:54 GMT

I'm helping all the teams in my BAEN370 class robotics competition (essentially our final) since I competed in the ASABE Robotics Competition last year in New Orleans. This post is advice mainly targeted at everyone in the class. Here are a few useful snippets when starting your first big Python project.

Imports

If you're working on a file, e.g. code.py, and it's getting large, you can break off some of that code (usually functions) into another file. Let's say you name this file functions.py. Then, in your original file, you would add to the top:

from functions import function1, function2 # etc
# if you have a lot of functions, you can use something like
# from functions import (function1, function2, ... ,
#                        functionN_minus_one, functionN)

An example of how to use this, in the context of BAEN370, would be using the following project structure:

baen370/
├── run.py
├── navigation.py
└── sensors.py

Then, those files' contents would look something like this:

Equation Solving with Python & SymPy

Kurt Kremitzki — Sun, 10 Apr 2016 11:12:16 GMT

In engineering applications, the same equation will be solved over and over with different values or measurements as inputs. Anticipating this, we can either write one function for each variable which inputs all other variables, or take a much easier route using SymPy.

The following example is a simple implementation of Manning's formula:

\[ v = \frac{k}{n} {R_h}^{2/3} S^{1/2} \]

with \(k = 1.49\) since we most often work in English units in American hydrology. Note that the variable mannings_eqn is actually the above expression set equal to 0, so that we see a \(-v\) term.

The following code creates Sympy Symbols for each variable in the expression. In general, if we have \(n\) variables in the expression, we can pass in a dict with \(n-1\) key-value pairs (equations) with known values to solve for the \(n\)th variable. We can create dicts with keys, the set of knowns, and pass in any (independent) combination of \(n-1\) variables from our expression to get a number.