Dominik Winecki

a(13)-a(22) for A279860

Tue, 08 Apr 2025 00:00:00 +0000

Here is the definition of A279860 from OEIS:

a(n) is the first n-digit substring to repeat in the decimal expansion of e.

There is ongoing competition[1, 2] to find such repeated sequences in π, A197123, so I took a crack at the second-most-famous transcendental constant.

I searched the first 250 billion digits and found a(1)-a(22). a(23) was not found (I only had a 26.8% chance of finding it). I used a HashSet but would probably switch to a bloom filter for a(24) or higher. Rather than partitioning by prefix, I used the least significant bits of the sequence as a hash and used modulo partitioning.

Here are the sequences and their positions:

n	a(n)	First Position	Repeat Position
1	2	0	4
2	18	2	6
3	182	2	6
4	1828	2	6
5	98793	478	494
6	987931	478	494
7	4349076	170	2731
8	82549802	11449	23544
9	450388721	9832	29424
10	5291493974	35210	159929
11	72883660263	55704	172254
12	476539957100	685615	947487
13	2557556217677	696773	4212711
14	45820090256930	937385	11527854
15	441340408673681	16824283	64070443
16	4413404086736815	16824283	64070443
17	04490816865108378	305179147	305519388
18	044908168651083787	305179147	305519388
19	3369635849169468729	3493534312	4849639160
20	29845348176416445308	15006890876	15441233099
21	561387588857094780748	33340537999	55184810049
22	8238609087161769234440	161691630698	176191766517

My workflow for plots in research papers

Fri, 06 Sep 2024 00:00:00 +0000

When writing papers, managing evaluation data and plots has been consistently troublesome. While getting to the first draft of a plot is often quick, the challenge arises during the inevitable subsequent revisions. Here’s the workflow I’ve been using to speed up my iteration time.

Issues & Inconveniences

There are two categories of issues/inconveniences that my previous bespoke Excel-based workflow had:

Manual updates:

Loading data was manual (even from CSVs).
Every plot had to be created from scratch.
Plots had to be manually exported one by one on each change.

Reproducibility issues:

Spreadsheets had to be versioned and tracked separately from code*.
I often forgot which evaluation run was loaded in any given sheet.
- Especially when returning to a project after a few weeks/months.
There was no record of label/name updates.
Excel subtly changes chart sizes when you save/load a sheet.

Most of these issues are different forms of excess user-managed state.

*While spreadsheets can be version-controlled like any other file, no merge algorithm will resolve conflicts, forcing this task on the user.

My workflow

TLDR: Code → data.json → duckdb → ggplot2 → plots/<name>.pdf → LaTeX
(where duckdb and ggplot2 are one-liners in an R Jupyter Notebook cell)

Evaluation Code: Any benchmark outputs metrics as individual lines of JSON, which can be written to a file. For example:

import time
import json

def fibonacci_recursive(n):
    if n <= 1:
        return n
    return fibonacci_recursive(n-1) + fibonacci_recursive(n-2)

def fibonacci_iterative(n):
    a, b = 0, 1
    for _ in range(n):
        a, b = b, a + b
    return a

n = 12
start_time = time.time()
_ = fibonacci_recursive(n)
rec_time = time.time() - start_time
print(json.dumps({"fn": "fib-recursive", "time": rec_time}))

start_time = time.time()
_ = fibonacci_iterative(n)
iter_time = time.time() - start_time
print(json.dumps({"fn": "fib-iterative", "time": iter_time}))

$ python my_benchmark.py >> data.json
$ cat data.json
{"fn": "fib-recursive", "time": 3.695487976074219e-05}
{"fn": "fib-iterative", "time": 3.337860107421875e-06}

If there are multiple benchmarks to run, I make a script that clears the data.json file and then runs each benchmark appending the results to data.json.

Loading, Preprocessing, and Plotting Data: I then load and preprocess the JSON on disk with DuckDB. I do this in a Jupyter Notebook running in R kernel. While I prefer Python, ggplot2 is better than anything Python has.

library(duckdb)
con <- dbConnect(duckdb())
dbExecute(con, "INSTALL json; LOAD json;")

q = "
SELECT
    CASE 
    WHEN json->>'fn' = 'fib-recursive' THEN 'Recursive'
    WHEN json->>'fn' = 'fib-iterative' THEN 'Iterative'
    ELSE json->>'fn'
    END AS fn,
    CAST(json->>'time' AS DOUBLE) * 1000000 AS time
FROM read_ndjson_objects('data.json')
"
df = dbGetQuery(con, q)

Now, the dataframe can be plotted directly and saved as a PDF at the same time:

library(ggplot2)

p <- ggplot(df, aes(x = fn, y = time)) +
    geom_bar(stat = "identity", fill = "steelblue") +
    labs(title = "Execution Time of Fibonacci Functions",
    x = "Function Type",
    y = "Time (microseconds)")
ggsave("plots/fibonacci.pdf", p, device='pdf', width=4.5, height=3)
p

Each SQL/plot pair gets its own cell. And, for convenience, the notebook starts by clearing the plots directory:

library(ggplot2)
library(duckdb)

con <- dbConnect(duckdb())
dbExecute(con, "INSTALL json; LOAD json;")

if (dir.exists("plots")) {
    unlink("plots", recursive = TRUE)
}
dir.create("plots")

This plots directory can then be copied directly into the LaTeX project/Overleaf.

Conclusion: This notebook can now be version-controlled, and the data is in a single, human-readable file that is easy to back up. Additionally, figures can be updated in 30 seconds with a change in data, preprocessing, or plots.

Trying to get a phone screen fixed

Thu, 09 Jun 2022 00:00:00 +0000

I used to use a OnePlus 6T. One day, the screen stopped accepting touch input. The Android ecosystem has been a bit slow lately, and I didn’t want to create e-waste, so I tried to get the screen replaced.

I found a company with a local store, uBreakiFix, that could service my phone. However, the new screen seemed dull and lifeless. Worse, it had backlight bleed. That should be impossible. My phone has an AMOLED panel, and OLED panels don’t have backlights.

Let’s take a look at that screen:

The mystery screen sure does look similar to an LCD, doesn’t it? It’s using RGB stripe, which is common on LCD, and more expensive on OLED.

The larger problem is the use of RGB pixels, whereas almost all OLED phones (OnePlus 6T and LG V30 included), use PenTile RGBG layout. Simply, it has half the number of green sub-pixels.

The screen they used has visible backlight bleed, a pixel layout similar to S-IPS LCD, and a subpixel geometry nowhere near the PenTile display it should be. It’s a counterfeit. I got a refund. And then an iPhone.

A CRDT for contact synchronization

Sun, 30 Jan 2022 00:00:00 +0000

Background

Some things are too important in technology to not standardize. Contacts and calendars, for example. They can be represented as vCard and iCal respectively. These work fine for simple import/export operations, but they provide little aid in supporting users across devices.

CardDAV and CalDAV are the synchronization protocols built on top of vCard and iCal. Thanks to them, you can use whatever apps you want to on your phone or desktop, and it all synchronizes through the cloud.

As long as it goes through the central server.

That central server thing has some problems:

You have to trust someone to host your data
Devices can only communicate through the central server
Your protocols can be less robust since the server can fix issues for you

Email is similar. IMAP synchronization lets everyone use whatever client they want to while the central server keeps your data.

Except with email, and instant messaging in general, there is the desire to replace it with a fully distributed system. Matrix is the main effort to do so. The vision is every application or (potentially static) website-based client acting as a peer. Servers may exist, too, but serve mainly as peers with higher-than-usual availability. It’s a pure distributed/p2p/web3 solution.

It’s not the first to do so. Source code management did this a long time ago. Flat files are your data format. CVS/Subversion was the synchronization solution. Then git/mercurial made decentralization popular.

Note that removing the central server isn’t the only benefit. You get operational benefits in cloud hosting since you can run multiple less-reliable peers. You can benefit from p2p and mesh networks, so nearby devices could sync even when neither can connect to the internet. Users also get the benefit of a more generalized merging algorithm; it’s naturally more robust.

Contacts and calendars may eventually go this way too; even though the need is less pressing.

A distributed vCard list

Unlike source code management, where conflicts between versions are all but guaranteed, Matrix uses Conflict-free replicated data types.

Each person has their own copy of a data structure, and there is a method for merging any two data structures together whereby any order of merges results in the same output. This allows for each peer in a system to have a copy and use gossip to propagate changes. And the gossip that it’s sending is just its current state. It doesn’t need a push mechanism.

Consider two servers hosting a file over HTTP. By periodically reading each other’s values (à la RSS) and merging their data, they can propagate their changes across arbitrary topologies.

A single vCard entry

There are a lot of things you can put in a vCard file. Luckily, for this purpose, only cardinality matters. It has four different classes of labels:

Exactly 1
0 or 1
1 or more
0 or more

A different CRDT can be chosen for each of these based on when you find losing data acceptable. This is the less interesting part of the problem; as long as some logical CRDT is used, it doesn’t matter.

I’m going to use a Last-writer-wins register for exactly 1, and the nullable version of this for the 0 or 1 case. For the remaining two, an observed removed set (with adds taking precedence over removes) will suffice.

A very simple example:

struct ContactEntry {
    name: Lww<String>,
    tel: ORSet<String>,
    // insert the remaining thousand vCard keys here
}

A list of vCards

Synchronizing contacts isn’t as simple as synchronizing a single contact. Contacts can be added and deleted. They can also be merged. Mergers are just an update of one and the deletion of another, but since we want changes that haven’t propagated to the current peer to be reflected, a merger needs to be a first-class operation.

Mergers are hierarchical. They form a tree. You can store a tree as a CRDT. But that’s not necessary here.

Rather, we can store one logical “contact” as a set of contact entries. To differentiate between contact entries, each is assigned a random UUID. Each contact starts with one entry. When it’s merged with another, they form a new set with the union of their entries. When merging two of these sets, any entry in two separate sets will replace both with their union.

This is a Disjoint-set data structure (i.e., a set of disjoint sets). It’s a CRDT, or can be implemented as one. I can’t find anyone else who has shown this, so that might be new.

A list can be represented as such:

struct ContactList {
    entries: Map<Uuid, ContactEntry>,
    contacts: Set<Set<Uuid>>, // uuids point to entries
}

This takes advantage of the mergeable property of CRDTs: from the user perspective, a contact is the merger of each of its entries. It does mergers for the logical representation, not just the physical representation (as we explicitly don’t want to merge different entries). I can’t find this used elsewhere in the ecosystem either.

We can put a tombstone boolean on each of these entry sets to implement deletion. However, if one person deletes a contact while on another device merging it with another contact, it will delete the other once propagated. Rather, we can delete at the entry level:

struct ContactEntry {
    name: Lww<String>,
    tel: ORSet<String>,
    tombstone: TrueWinsBool,
}

A contact is only considered deleted once all of its entries have a tombstone bit set. When a client wants to delete a contact, it sets this bit on each of the entries. The contact will only ever be undeleted if another peer had merged this contact with another non-deleted contact without observing the deletion to protect the new entry from instant deletion.

New things you can now do

Collaborative editor CRDTs are the most developed. They allow for distributed text editing of a single field. One can imagine embedding one of these for each note associated with a contact, or similar use cases.

Also, one useful feature many devices have is showing the most recent or most frequently contacted people first in lists. This could be embedded in their contact to work across platforms. The simple case of the most recently contacted could be implemented with a timestamp. A total interaction count could be done with a counter. To be even more accurate, count-min sketches and HyperLogLog structures can be used to probabilistically keep track of frequencies without embedding too much sensitive data within the contacts themselves.

Many clients show the user when they last synchronized with the cloud. The “no single source of truth” model may seem opposed to this; however, it provides a superset of functionality. You can embed propagation observability of a CRDT into itself; you can pick a node to be the “main” one if you want. Or, you can be more creative and use any arbitrary standard for consensus. For example, you could host cloud peers on three different providers and only consider a version “up to date” when two of the three have observed it.

While the improvements of switching to a distributed architecture are likely marginal, they would be a win for decentralization and user experience. Similar solutions are desirable for any product that has become a near-commodity. Currently, that would be contacts, calendars, and photo sync. In the future, playlists, credential/password stores, browser settings/history/bookmarks, and even user identity could benefit from elegant applications of distributed systems concepts.

Transcendental Numbers for Scoring

Sat, 01 Jan 2022 00:00:00 +0000

I’ve organized a hackathon or two. Figuring out how to score them is difficult. Even excluding social aspects aggregating results is far from an exact science. However, some methods can enforce additional constraints. Especially if they don’t have to be simple or practical.

Reducing the probability of ties

Ties can be problematic in practice at competitions. Should two teams receive the same scoring any fair system must produce a tie. However, the case of two teams receiving scores that add up to the same final score is an unfortunate possibility that can be minimized.

The most common form of a combined score is as a linear sum where \(s\) are scores and \(w\) are weights.

\[\text{Score}=w_1s_1+w_2s_2+ \dots + w_n s_n\]

This is likely to produce ties. Any single variable in this system (assuming its corresponding multiplicand isn’t 0) can be changed to set the score to any arbitrary value.

However, there exists an implicit constraint: the weights and scores are all rational numbers. Formally, \(s_n \in \mathbb{Q}\) and \(w_n \in \mathbb{Q}\). This also implies their product is rational. While values of \(s\) come from humans we have full control over the values of \(w\). Also, \(w_n \neq 0\), since we do not need to include any criteria with no weight.

By introducing another, irrational, set of multiplicands we can ensure that our output is irrational.

Consider the case:

\[\text{Score}=w_1s_1+w_2s_2\sqrt{2}\]

The first component \(w_1s_1\) is rational while the second component \(w_2s_2\sqrt{2}\) is irrational. In every case except \(s_2 = 0\), the Score is irrational.

Adding more terms requires a string of irrational numbers where each number can’t be constructed through a (rational) linear sum of the other irrational numbers. These irrational numbers must not be a rational multiple of any other number used, i.e., you can’t use \(\sqrt{2}\) and \(2\sqrt{2}\), or anything similar as it’s trivial to cancel out the terms. However there are other powers you could use instead which would work, such as using the range \([0, 1)\).

\[\text{Score}=w_1s_12^{0/n}+w_2s_22^{1/n}+ \dots + w_n s_n2^{(n-1)/n}\]

Here, for any finite number of criteria \(n\), and given the constraints on values of \(w\) and \(s\), no two Scores are equal unless all the values of \(s\) are equal. This is the simple solution to the original problem when using linear sums. However, one could use the even stricter set of transcendental numbers instead. \(e^x\) is transcendental (which guarantees irrationality) for any non-transcendental value \(x\).

Consider the case:

\[\text{Score}=w_1s_1e^1+w_2s_2e^2+ \dots + w_n s_ne^n\]

This solves the same problem, but there is a more general form we can target. This approach requires the score to be a linear sum against vector \(s\), but it’s possible to support an entire class of functions instead. Any non-constant algebraic function taking a single transcendental number resolves to a transcendental number. This can be extended to the multi-variable case by using any arbitrary algebraic function in the form \(f(s_1T_1,\space s_2T_2,\space\dots)\) by choosing some special values of vector \(T\). Note the values of \(w\) are no longer necessary as they may be embedded within \(f\).

The constraint on \(T\) isn’t just to find transcendental numbers. The previous case of using \(e\) and \(e^2\) could trivially be “undone” by taking the square root of the second and dividing it from the first to produce a rational result. Rather, we need \(T\) to be a set of transcendental numbers that are all algebraically independent over the rational numbers. A few such sets are known, including one method of producing these sets to any arbitrary size; the Lindemann–Weierstrass theorem. This shifts the problem to finding a set of algebraic numbers which are linearly independent over the rationals. Which, coincidentally, is the exact problem solved by the first solution to the simple case. Using these we can generate a set of transcendental numbers that are algebraically independent over the rationals:

\[T = [e^{2^{0/n}}, e^{2^{1/n}}, e^{2^{2/n}}, \dots, e^{2^{\left[(n-1)/n\right]}}]\]

Any set \(\{s_1T_1,\space s_2T_2,\space\dots\}\) will be algebraically independent over the rationals as well as having each element be transcendental (or zero).

Therefore, for any non-constant algebraic function \(f\), the value \(f(s_1T_1,\space s_2T_2,\space\dots,\space s_nT_n)\) will be transcendental, or zero if all values of \(s\) are zero. Of course values of \(s\) still need to be rational.

Rather than using an arbitrary tie-breaking method, this method inherits all the ordering properties from the scoring function \(f\). Practically this forms an injective (one-to-one) function mapping a vector of rationals \(s\) to the real numbers. Since real numbers are ordered there must be one vector of scores which is the highest within any set.

Laptop battery life data

Mon, 05 Oct 2020 00:00:00 +0000

Back in 2016, I wrote a daemon that grabbed the system battery stats every second and dumped it into a CSV.

I ran it on my laptop for 99 days:

Major takeaways:

Cheap replacement lithium-ion batteries have a really limited number of cycles.
Linux laptop power management still has a ways to go.
Pulling battery stats and writing a file once per second isn’t great for power management.

Replacing malloc with rand

Mon, 19 Aug 2019 00:00:00 +0000

The malloc function is fairly simple. Either give me a pointer to some memory I can use or give me NULL if I’ve asked for too much.

And, on Linux that’s exactly what happens:

int main() {
    int *ptr;

    ptr = malloc(1000); // ptr = 0x563bd6707260
    ptr = malloc(1000000000000); // ptr = 0x0

    printf("%p\n", ptr);
}

However, something interesting happens when you try this on a Mac:

It works…

but why? Surely this 8 GB Mac isn’t going to find a free terabyte lying around.

Clearly it’s mistaken, and as soon as we write to it it’ll segfault:

for(size_t i = 0; 1; i++) {
    ptr[i] = 0;
}

And… it got to 64GB before getting killed:

It didn’t even put a dent in the system resources:

Okay, so it looks like either macOS is discarding writes to memory, or it realized it’s all zeros so it’s compressing them. Let’s try again with some higher entropy data:

for(size_t i = 0; 1; i++) {
    ptr[i] = rand();
}

It still gets to 64GB, but not without swapping to disk:

So it looks like malloc actually did return a terabyte of virtual address space, even if we won’t be able to use all of it.

It’s pretty clear what’s happening here, macOS is just filling in the memory pages when we need them, not when we get assigned them. Or as it’s known formally, demand paging. There are plenty of benefits to this type of memory management, especially for laptops. This is what lets a relatively low-spec MacBook run Docker, Chrome, and a handful of Electron apps all at once while still being usable.

So, if a terabyte works, how large can we go? It’s a 64-bit system, so \(2^{64}\), right?

Well, modern x86_64 CPUs only support 48-bit memory addresses, since 256TB is enough for most people. And sure enough, allocating 100TB works perfectly fine, but trying to allocate a petabyte causes something to break:

But this also has one other benefit, it lets you try out how programs could run with huge amounts of RAM.

rand() as an allocator

If you have enough memory in a system you can just pick some number at random and hope it works, right?

To put this theory to the test I pulled a copy of Redis, an in-memory database, and started replacing its allocator.

Redis uses one of three allocators, set at compile-time, and wraps them in a custom wrapper as zmalloc, so changing one place would change it for the whole project.

To start, let’s get 100TB, and then just pick a spot somewhere in that:

void *zmalloc(size_t size) {
    // printf("zmalloc size=%lu\n", size);

    static void *block = 0;
    if(!block) {
        block = malloc(100000000000000);
    }

    size_t rand64 = ((size_t) rand() << 32) | ((size_t) rand());
    rand64 %= 100000000000000;

    return block + rand64;
}

There’s also calloc, but let’s assume there are zeros there anyway:

void *zcalloc(size_t size) {
    return zmalloc(size);
}

realloc can get a little weird, so let’s try to keep most of the original behavior:

void *zrealloc(void *ptr, size_t size) {
    if(size == 0 && ptr != NULL) {
        zfree(ptr);
        return NULL;
    }
    if (ptr == NULL) return zmalloc(size);
    return ptr;
}

And finally,

void zfree(void *ptr) {
    return;
}

So does it work? Yes!

It even accepts user connections through redis-cli! Sure, once you try to run a remote command you get a segfault, but you can’t win them all.

It takes +13000 zmalloc calls to get a server running, and it works!

Now let’s see if it passes tests:

Hey, passing the first 20 tests, not too bad! There were some data structure tests in those. It didn’t even fail due to a segfault or anything, it just can’t check how large an allocated block was.

Did that really need 100TB of space?

Couldn’t this have worked with just 8GB?

If the goal is to avoid memory collisions, then what is the chance a duplicate pointer gets returned? This exact situation gets covered by the birthday problem. If we have \(k = 50000\) separate allocations and \(n=\text{100 trillion}\) then the chance of a collision can be found with this formula:

\[1-\left(\frac{n-1}{n}\right)^{\frac{(k^2-k)}{2}}\]

Given 100TB of address space, the chance of a collision across 50k allocations is 0.00125%. With 8GB it’s 14.47%. And this only accounts for pointer collisions, much more address space gets used.

And all of this is before considering that rand() isn’t exactly cryptography-grade randomness either.

So, if you are picking your pointers at random, at the very least, taking advantage of demand paging gives you a little more peace of mind.

NCUR19 Trip Report

Sat, 20 Apr 2019 00:00:00 +0000

I’m thrilled that this year I had the opportunity to present my research at the National Conference on Undergraduate Research at Kennesaw State University.

Day 1

NCUR19 kicked off with a plenary session featuring a keynote on whale sharks. Thanks to the Georgia Aquarium, which has the only captive whale sharks in the US, Atlanta is the front-runner on their research. Even though a handful are kept in captivity, there is still very little known about them, like how deep they go on their deep-ocean dives. That last question may soon be answered since a custom tag has been deployed that won’t max out at 2000m. I didn’t know much about whale sharks going into this, but I left with my calendar marked for the day that tracking tag is programmed to come off of one.

Research Highlights

Following the plenary session was the start of the poster presentations. There are at least a hundred posters per session so I can only mention some of the (mostly computer science) highlights that I found memorable:

Autonomous Payload Return Vehicle: When weather balloons drop their payloads with traditional parachutes they have a tendency to land in the worst places. This project uses a parafoil controlled with servos to steer the payload to a target. Being able to pick up your data from an empty field instead of climbing a roof or trekking through water makes atmospheric research more accessible.

Graphene Filters: This research was into the effectiveness of graphene-based filters for organic pollutants. What was surprising to me was how the graphene filters could be cheaper than activated carbon filters in the long term, since they are used up much slower.

Monte Carlo N Particle Semiconductor Detector Simulations: I don’t really have the background needed to understand the chemistry/physics behind this one, but this project is evaluating alternative materials for detecting radiation since the currently used ones are expensive and hard to get. The software used came from an Oak Ridge National Lab and required the project to justify its need to the federal government. It was a really impressive simulation with a clear market need and good results.

Datamining to find Cyberattack Trends: This was a study into a cybersecurity attack database from a federal law enforcement agency. Things such as SQL injection and buffer overflows stayed generally constant with occasional spikes on major vulnerabilities. However, there were large shifts to more focused attacks on edge devices since those provide the highest ROI.

Machine Learning for finding Malicious URLs: Due to the short lifetime of malicious URLs, they are purchased in large quantities. Because of this most are using extremely repetitive and predictable structures. Machine learning can effectively classify these URLs. This can be combined with other methods to further increase accuracy.

Grip Strength Among Sonographers: Sonographers are at a massive risk for repetitive strain injury. Increased grip strength can prevent this, but sonographers already have twice that of the average person. By instead focusing on training related muscles that aren’t regularly stressed further gains can be made to reduce the risk of injury. On a side note, sonographers would make excellent rock climbers.

Pesticides on Spiders: This was a study into how pesticides impact non-target insects, specifically wolf spiders. Many chemical treatments are marketed as having no effects on other species. This research demonstrated them as causing clear damage even at doses far below what is commonly used.

Day 2

This was the day when I presented my research:

It went well! A lot more people showed up than the last time I presented. The nice thing was that no matter a person’s background I was able to find a relatable use-case for my system.

Day 3

Following the final two poster sessions, the conference ended with another plenary session, this time with a keynote on Lockheed Martin Skunk Works. It covered everything from the U-2 and SR-71 all the way to aircraft of the coming decades (Including possible commercial supersonic flight!). The presentation, along with the others, had a focus on the importance of engineering in other fields.

Takeaways

NCUR does a really good job at promoting a diverse set of research from all across the US. And, despite being the only student going from OSU, Ohio was certainly not lacking in representation. No matter where I went there was always someone from Miami, C-State, or Capitol nearby.

But, regardless of where people came from everyone had the same passion for their research and enthusiasm to learn about the work of others.

In addition to a list of projects to follow up on, I left this conference with a better understanding of what goes into research and its greater impact on the world.

Programming Swerve Drive

Mon, 15 Apr 2019 00:00:00 +0000

Swerve drives are fun. While sometimes impractical they check off more boxes than any other drivetrain. Not only can you drive them in any direction, but you can also rotate independently, all while using conventional wheels aimed in the optimal direction for force. Unlike mecanum wheels, which have found use in forklifts, swerve is almost exclusively used by FIRST robotics groups.

Mathematical Model

A swerve drive takes two inputs for control: the desired translation and rotation. This maps to kinematics definitions of a velocity vector and angular rotation, which I’ll call \(\vec{v}\) (m/s) and \(\omega\) (rad/s). The outputs are actually motor values for 2x the number of modules (for pivot and drive motors), but for now, let’s abstract this away and pretend every module takes a vector.

Here is where this definition will diverge from many other implementations. We will solve this in the general case, so \(n\) modules at arbitrary locations. Most implementations have 4 modules in a rectangle around a center, but the general case is both closer to the underlying physics and (at least to me) easier to implement well in modern languages.

Now, since we have angular velocity we need a reference point. If we assume an origin exists at \((0,0)\) we can define the location of each module relative to that. Therefore module \(n\) is located at \(\vec{m}_n\) relative to the origin (in meters).

With this we can define a simple frame like this with just four vectors around a center point:

This allows for what is essentially the fundamental formula of swerve drive:

\[\vec{\text{output}}_n = \vec{v} + \omega\cdot\text{perpendicular}(\vec{m}_n)\]

This doesn’t specify whether you need the clockwise or counter-clockwise perpendicular function, but as long as it agrees with \(\omega\) it doesn’t matter.

By using this general form of swerve drive we get support for much more powerful operations simply by changing a few variables. For example, just by changing the module locations in \(\vec{m}\) you get support for arbitrary shapes:

Also, since the perpendicular function maintains length we get rotational scaling for free:

The final benefit of this model is that the center of rotation is arbitrary. Even if most of the time a center-based rotation is desired, the center can be moved anywhere on the 2d plane if needed.

Necessary Upgrades

Below the high-level kinematics model, a basic implementation can just be a cartesian to polar conversion. However, there are a few parts that stray from the theoretical model that allow for better control using physical motors.

Speed Normalization

To get the best performance out of the drive train you should be running it at a speed where it occasionally maxes out the motors. For example, the module output vector lengths at some point could be [2.30584285 1.80334026 0.55053495 1.538819]. Since a motor should never be set to over full power, there needs to be defined behavior on how to handle this problem.

Option 1: Clamping

The naive method is clamping and is most likely what will happen by default if speed normalization is ignored. Here this results in values of [1.0 1.0 0.55053495 1.0]. This distorts the final direction, so this should never be used.

Option 2: Pre-normalize

This method relies on finding the highest possible speed and scaling down each value accordingly if it is greater than 1. The highest possible speed is always when the translation and rotation components are in the same direction, so we can just add their distances.

\[\text{scalar}=\min\left(\frac{1}{\left|\vec{r}_\text{max}\right| + \left|\vec{v}\right|}, 1.0\right)\]

This relies on knowing \(\vec{r}_\text{max}\), which will always be the \(\vec{r}\) of the furthest module from the center of rotation.

\[\vec{r}_\text{max}=\omega |m_\text{furthest}|\]

This approach is the simplest and guaranteed to never exceed 1, but it may be slightly too conservative. For example, this results in values of [0.99638291 0.77924539 0.23789289 0.66494252], which is very close to the highest. While only \(0.4\%\) is lost in this example, it may be more pronounced in others.

Option 3: Post-normalize

This approach just takes all the speeds and divides them by the highest, if it’s larger than one. In the example, this produces values of [1. 0.78207422 0.23875649 0.6673564]. This method produces the best values but can be a little weird to implement if you separate each module into its own object since they would all need to communicate their values.

Direction Flipping

Turning a module to perfectly match the target vector is often unnecessary since the opposite vector with a reversed speed accomplishes the same thing. Taking this into account, one module should never have to travel more than 90 degrees to reach its target.

This can be implemented with a simple if statement, but there is a better option using vectors that also fixes the stray module problem.

Stray Module Problem

A common problem is one module taking a different path from the rest. This results in the wheels fighting each other and stalling.

While this isn’t too bad for a single target, when the target is constantly changing this can become a large proportion of the total runtime.

Option 1: Mitigation

The simplest option is to slow down the modules when they are pointing in the wrong direction. A quick and easy way to do this is to multiply them by the cosine of the angle difference, \(\theta\), which is easy to do with vectors:

\[\cos\theta=\frac{\vec{\text{target}}\cdot\vec{\text{current}}}{|\vec{\text{target}}|\ |\vec{\text{current}}|}\]

If a more aggressive limit is needed this scalar can be raised to an exponent, which also won’t change the domain. Here is an example of speed scaled by \(\cos(\theta)\) and \(\cos(\theta)^3\):

Another benefit to cosine scaling is that it also will take care of reversing the drive wheel when needed because the resulting cosine will be negative. The only drawback is that you can’t directly use even exponents, but that’s pretty much irrelevant.

Option 2: Explicit Avoidance

Another option is to explicitly avoid having modules take different paths. Essentially, “if one is going to fight the others have it follow the others”. This can only be accomplished with some pretty ugly hacks, but it can be done.

One way of doing this is to shift the module flip windows. When each module is deciding which way to go it looks for the shortest path to being in line with its target. This creates two 180 degree windows, and the one it currently falls on decides which direction it is going to use. If you were to take the average of module rotations (or really their derivatives) and shift this window in the opposite direction proportionally this would effectively make each module follow the rest if it’s close enough. This introduces another constant for how large this shift is. It would need to be tuned to be just larger than the usual error in rotation so it can capture most of the stray modules.

Going Further

Swerve drive gets programmed with a simple physical model assuming perfect inputs. However, swerve algorithms are not a problem with an ideal solution that can be derived or even expressed with conventional mathematical models.

A perfect control system would take into account these three separate factors:

Time series control
Noisy I/O
Full robot kinematics

Each of these makes the final algorithms more complex. The final two are soft-computing problems as well, so there may not necessarily be clear ways to improve on them. So is this as good as it gets? In practice, yes.

But there is another option to take it further: neural networks.

Swerve, at least in 2d, is really just a function that takes three numbers; \(\vec{v}_x\), \(\vec{v}_y\), and \(\omega\); plus \(n\) encoder inputs, and outputs \(2n\) motor outputs, for the drive and pivot motor speeds. And \(n\) is almost always 3 or 4. So seven linear inputs and maybe 8 linear outputs, and almost all the operations are additions and multiplications. This is just about the perfect use case for a small neural network.

However, this doesn’t take into account time series data, since it’s still stateless. To fix this we can give the network some memory, specifically as an LSTM.

Training this certainly would not be easy, and even less so to test, but this is the best option to move forward.

Source code

All of the graphics here were created from this jupyter notebook (HTML).

TCP Terminals with MATLAB

Wed, 20 Mar 2019 00:00:00 +0000

The OSU Freshman Engineering program concludes with a Software Design Project where students compete to build the best MATLAB games they can. Since there was no way I’d win for UI I took a stab at building a multiplayer version of battleship.

Background

While MATLAB certainly isn’t known for its easy game creation this hasn’t stopped people from creating some really impressive projects. TCP/IP support exists, but provides the bare minimum for writing servers. You only get one socket per port, and every function call blocks, so sometimes you have to get creative.

Since this was created for a class the goal was to create the minimal viable product with the least effort, and it definitely shows in the code quality.

Networking

To avoid having to synchronize state across multiple programs I decided to only have one single server and have all clients connect through TCP. This is a common technique in cybersecurity exploits, where you open up a remote root shell, so it is doable. Since we can only open one socket per port, we’ll have to use two:

t1_socket = tcpip('0.0.0.0', 30000, 'NetworkRole', 'server');
t2_socket = tcpip('0.0.0.0', 30002, 'NetworkRole', 'server');

fopen(t1_socket);
fprintf(t1_socket, 'Welcome to Battleship Player 1!\nWaiting for Player 2...\n');
fopen(t2_socket);
fprintf(t2_socket, 'Hello Player 2! Welcome to Battleship!\n');

Great! Now we can send data to the clients that connect with nc <ip> 3000{0,2}! But then we’ll have to find a way to clear the screen so it at least looks presentable. This should be as easy as faking a terminal clear command:

$ clear | xxd
00000000: 1b5b 334a 1b5b 481b 5b32 4a              .[3J.[H.[2J

Now we can clear a client screen by sending those bytes:

function clearSock(socket)
    data = char([hex2dec('1b'), hex2dec('5b'), hex2dec('48'), hex2dec('1b'), hex2dec('5b'), hex2dec('4a')]);
    fprintf(socket, '%s', data);
end

Now we need to get user input. This gets a bit more complex since reading from multiple sockets at once isn’t a supported feature. Luckily, we do have a BytesAvailable property, so we can avoid blocking on a read. Here we have a function that takes an array of sockets and a bitmask to show which ones still need data:

function [p_id,data] = getSomeInput(socks, sockmask)
    p_id = 0;
    data = '';
    while 1
        for pid = 1:length(socks)
            p_id = pid;
            if ~sockmask(p_id)
                continue
            end
            if socks(p_id).BytesAvailable > 0
                data = fread(socks(p_id), socks(p_id).BytesAvailable);
                data = data(1:length(data)-1); % Remove newline
                fprintf('Got data from %d: [%s]\n', p_id, data);
                return
            end
        end
    end
end

Game Logic

Now that all the boilerplate networking functions are out of the way we can get down into the game code. There isn’t too much special about our implementation, so I’ll skip most of this. Despite not being built for the task the language made most of it short and simple if you can represent it as an element-wise operation. For example, here is how I tested for collisions when placing ships:

[err,sBoard] = drawShip(coord, vert, SHIP_SIZES(ship_places(p_id)));

if err
    fprintf(socks(p_id), 'Collides with wall, try again: ');
    continue
end

if sum(sum(board & sBoard))
    fprintf(socks(p_id), 'Collides with another ship, try again: ');
    continue
end

To create a proper user experience they should be able to see an ASCII art version of the board. Something like this:

------------
|      HHH |A
|  H       |B
|  H       |C
|  H  H    |D
|  H  H    |E
|  H  H    |F
|     H    |G
|          |H
|  HHH     |I
|        HH|J
------------
 0123456789

This is where element-wise and matrix operations save the day. Surprisingly, this doesn’t take very many lines at all. All of this, and more, can be drawn with this monstrosity:

function printBoard(socket, board)
    width = size(board,2);
    line = char(zeros(1,width + 2) + '-');
    asciiBoard = char((board == 1) * 'H' + (board == 0) * ' ' + (board == 2) * 'X' + '.' * (board == 3));
    fprintf(socket,'%s\n', line);
    for i=1:width
        fprintf(socket,'|%s|', convertCharsToStrings(asciiBoard(i,:)),'sync');
        fprintf(socket,'%s\n', convertCharsToStrings(char('A' + i - 1)), 'sync');
    end
    fprintf(socket,'%s\n', convertCharsToStrings(line));
    fprintf(socket,' %s\n',convertCharsToStrings(char((1:width) + '0' - 1)));
end

This type of problem is one of the few where MATLAB comes only second to Python in lines of code. ASCII matrices are by no means good solutions to problems, and neither is embedding branching through element-wise logic, but they do have their uses.

Takeaways

This code is bad and wrong, with a UI only a sysadmin could love. But it does work. If I had to do it again I’d use Python, or maybe Go, but it really wasn’t as bad as I was expecting it to be. At the end it was even playable, albeit it’s a pretty slow game to play.

Here is a link to the full code.