Skip to content

Instantly share code, notes, and snippets.

Avatar
:shipit:
Working on Side Projects

Allan MacGregor amacgregor

:shipit:
Working on Side Projects
View GitHub Profile
View 3_commands_on_demand.md

3. Commands on Demand

Welcome back! Unless you never left, in which case, maybe it's time for a snack?? Previously we were discussing the notion of taking two sources of hardware output and somehow rectifying them into a single software input. I used the example of two IMUs, but I'm going to retract that one for now, because I haven't actually duplicated sensors on the vehicle yet. Rather, let's talk about using multiple sources of vehicle commands, since I've at least got that much working. But 2021 is the year of redundant sensors! (or should I call them oxiliary?)


Pesky front seat drivers...1

Two is one

I've never tested an autonomous system that lacked the option for a human operator to assume manual control. I know there are aircraft out there where the pilot is l

View 2_code_for_any_mode.md

2. Code for any Mode

From the start, this autopilot was designed to use multiple nodes operating on a local network. And with that premise in mind, I introduce you to Segal's law (not to be confused with Steven Seagal's Above the Law).


"A person with a watch knows what time is it. A person with two watches is never sure."

And here lies perhaps the biggest issue when it comes to multiple devices working together:

If two devices disagree, how do you know which one is right?

I'm sure there's a lot of really clever answers to this, but the nature of Elixir allows for an answer that is simple. And I like simple.

If a device is alive, assume it's right.

View 1_hardware_vs_software.md

1. Hardware vs. Software

Software is great, but at some point it has to interact with hardware or it's useless. One of the pressing questions early on was how many of the hardware interfaces could be written in Elixir. For example, the first peripheral I wanted to test out was an IMU (inertial measurement unit). If I were working with Arduino, I would have a library already available, ready to plug and play.

Should I connect the IMU to an Arduino board, and then interface with the Arduino board using a serial protocol of my choice? Or does the extra hardware outweigh the benefits of ready-to-use software?

Since I was still very new to Elixir, I thought it would be interesting to replicate one of my previous projects that had utilized Arduino, in this case a 2-axis camera gimbal. Do I have pictures of the original? No. Did I take pictures of the Elixir version before I took it apart? Also no. So we'll have to use our imaginations. (Don't worry, I hear your boos and I agree)
All I can offer i

@greghgradwell
greghgradwell / 0_in_the_middle.md
Last active Nov 17, 2020
0. In the beginning, there was the middle
View 0_in_the_middle.md

0. In the beginning, there was the middle...

You're jumping into a novel at about Chapter 6. And no, that's not because you missed the earlier chapters. I am only writing it now because it has finally become something worth recording (and hopefully reading). First, let me assure you that this is neither a theoretical exercise, nor a vague description of a "stealth" project. In short order you will be introduced to the current prototype that has already demonstrated many of the original project goals. And there will be plenty of pictures (please ignore the fact that this post has approximately 0 pictures 😬).

This project started out as somewhat of an experiment, or rather, it was a means to scratch an itch that had been bothering me for a few years:

What does it take to make an autopilot sufficiently reliable, affordable, and integratable enough to be extremely useful?

Or written as more of a challenge:

Can I create an autopilot that I could trust, afford, and would actually want t

View think_in_math.md

Think in Math. Write in Code.

Programmers love to discuss programming languages. Besides debating their own merits, we integrate them into our identities and even infer things about others who use them. Some even defend a form of [Linguistic Determinism][6] that thinking is limited to what is typable.

Since we spend so much time using languages, an interest in making them better is justified. However, the character of these debates suggests that we think of them as something more. Perhaps we have forgotten their primary role. Programming languages are implementation tools, not thinking tools.

@Vinai
Vinai / magento-composer-issues.md
Last active Apr 15, 2020
My beef with composer and Magento
View magento-composer-issues.md
@ramantehlan
ramantehlan / README-Fancy.md
Last active Jul 22, 2021
README template I use for most of my projects.
View README-Fancy.md

Introduction

  • Add your project logo.
  • Write a short introduction to the project.
  • If you are using badges, add them here.

📒 Index

@leonardofed
leonardofed / type12.md
Last active Jun 3, 2021
I built this thing to make coding interviews suck less
View type12.md

We built this thing to make coding interviews suck less

The traditional technical interview process is designed to ferret out a candidate's weaknesses whereas the process should be designed to find a candidate's strengths.

No one can possibly master all of the arcana of today's technology landscape, let alone bring that mastery to bear on a problem under pressure and with no tools other than a whiteboard.

Under those circumstances, everyone can make anyone look like an idiot.

The fundamental problem with the traditional technical interview process is that it is based on a chain of inference that seems reasonable but is in fact deeply flawed. That chain goes something like this: