debator//debater

A machine to help us communicate…

The last time I had free nights and weekends, 2011, our country was growing predictably chipper over the coming election, so I spent some of that free time considering debaterdebator.

The idea was simple: build a machine to help us communicate. I wondered whether personal relationships could be leveraged to draw friends into better discussions on political things, whether that discussion might benefit from ready access to conversation aides, and if the participants could be encouraged beyond the cable news/talk radio and red/blue strawmen. Fundamentally, I thought (and think), that people desire increased good for their selves, family, friends, and broader culture, that they would find it disconcerting to disagree with people they already trust and interact with, and that these relationships would have the best chance of drawing people together, into some greater understanding of and respect for our mutual interests and individual concerns.

Now, this idea struck some friends as obviously bad; that once you start down the partisan debate path, forever will it taint the relationship. I think that’s both wrong and unfortunate.  It’s unfortunate because it is the willful maintenance of a veneer, a retreat from true, honest conversation and, actually, a diminution of the friendship.  That’s Facebook, that’s the echo chamber we have today.  Instead, the (benevolent!) platform could strategically choose topics for conversation and then support the users in the formulation and conduct of a discussion.

So, in the case that uncle Jimbo had posted/tweeted articles and messages critical of the latest IPCC report on climate change, and nephew Jimmy the converse, our platform would begin with their relationship and detect that the article content and audience graph between these two relatives only minimally overlapped.  From there it would have prompted each person to review the other’s endorsements and encourage them to pose questions to each other.  Since neither participant is an expert in climate change, the platform would use the same article graph to find and suggest bridge articles that appeared to span the difference in perspective and might serve as a basis for shared knowledge and increased accord.  By encouraging each person to question the other (filtering, at least crudely, against attacks) within the context of a shared set of information, I hoped that they would come to a better understanding of each other’s perspective, their own, their culture, and their world.  And this would be valuable to them, to our society, and to the many interested parties.

I believed this interaction was enabled by reasoning over social platforms and the simple encouraging of people to seek explanations for their positions and, in citing them, attempt to defend their sources and arguments against those mustered charitably by their friend.  So, the platform should be a quest to discover truth, at first between two friends and likely reaching a trivial depth, but it had the potential to stoke something other than partisan, tribal cynicism, which we have far too much of.

I believed a this system was technologically possible 5 years ago (2011); it is even more the case today, and this is slowly being realized in a predictably breathless manner:

Those all referred to Facebook, and indeed their seat high atop Mt. Data enables them to rain benefits and harms on those below according to, essentially, their Ferengi whim.

While there are rational fears about the power of big-data (with the right analysis Facebook can create knowledge, and hence powers, that no other entity save the NSA can approach), it need not be exercised so insidiously.  I very much believe technological advances are tools that we can choose to apply for our benefit; so the contrast between what Facebook is doing and what I wanted to do is the user’s choice.  Facebook wants to drive greater engagement to expose their users to more ads, to encourage consumerism.  The problem is that Facebook is not helping people; it seeks to capitalize on their preferences, fears, and weaknesses, rather than aid their discovery, growth, and participation in the world.  It and many other platforms today provide a useful service, but they could do so much more.

LED Christmas Lights

For any given product, it is always interesting to see which aspects are improved and which languish.  Engadget’s recommendation of the best LED and incandescent Christmas lights highlighted this; the difference between the LED and incandescent strands is almost entirely restricted to the bulb (and associated electronic driver).

LED Christmas light (top) versus incandescent (bottom)

Looking carefully at the above picture, the incandescent bulb can be removed from the socket while the continuous mold line (lying exactly between the socket’s two flat sides) suggests that the LED bulb cannot be removed.  Assuming this, I’d wager that the LED bulb is first connected to the wires and then the socket molded around this connection.  The socket length and design, then, serve no functional purpose beyond fulfilling the consumer’s expectation.

A simple machine to make LED Christmas lights. From left; a spool of multistrand, multiconductor wire passes between two vertical-alignment rollers, through a wire-puller (drive), and into the LED inserter. LEDs fall from the vertical hopper into a bit and are driven by the pneumatic cylinder into the wire, such that their leads pierce the wire and making electrical contact. Exiting the wire, the leads are bent against the wire in the same manner as a stapler curls the staple on the back of the paper. This prototype does not encase the LEDs, so after the press the light strand is wound around a spool for packaging.
LEDs can be inserted directly into the wire, then encapsulated in plastic/rubber for electrical isolation.

LED Christmas lights were just coming to the market during my senior year in high school.  My senior project focused on the attachment of the bulb to the wire, where I realized that the increase in bulb quality (incandescent to LED) and associated decrease in bulb failure lessened the need for consumer-replaceable bulbs.  So, I designed a light strand where the LEDs were directly inserted into the wire and also a machine to construct these strands.

Removing the socket results in a more compact light strand which should be cheaper to produce (less material and elimination of a dedicated electrical assembly) and less visually-intrusive because the ‘socket’ has been substantially reduced (Christmas light strands are green to blend in with the tree).  Electrical contact is maintained without soldering by the compliance of the wire, much as a nail driven into wood is retained by forces from the compressed fibers.

I’ve learned much in the ten years since this project, but this idea remains relevant and would be fun to revisit.  I built this project in the context of the Szmanda science scholarship, so my paper and presentation highlight the energy efficiency of LED lights against traditional incandescents:

Bike Helmet Head Light

I enjoy biking into Engineering every day and though not much of a problem today, the summer solstice, I like to see and be seen throughout the darker times.  I quite like my Planet Bike Blaze, a compact 2W bike light and its warble flash mode, but it’s somewhat difficult to interface to my helmet.  So, this past weekend I finally replaced the fishing line version with a 3D printed pan/tilt mount.

Helmet pan/tilt light mount
Helmet pan/tilt light mount

Continue reading “Bike Helmet Head Light”

Control Diagrams in LaTeX

[latexpage]

Over Christmas break I’ve become dangerous with $\LaTeX$ document typesetting (wikipedia).  There’s something incredibly attractive about having the entire source of a document embedded in a single, text file.  Indeed the learning curve has been a bit steep (it may yet get stepper…), but I’m now able to reasonably produce dynamics and controls documents with integrated figures.  Here’s the state block diagram for the quintessential spring-mass-damper problem, composted in $\LaTeX$:

\begin{tikzpicture}[node distance=5mm and 15mm, >=stealth, skip loopDL/.style={to path={– ++(0,-.5) |- (\tikztotarget)}},skip loopLU/.style={to path={ -| (\tikztotarget)}}]
[+preamble]
\usepackage{tikz}
\usepackage{graphicx}
\usetikzlibrary{ arrows,  shapes.misc,  shapes.arrows,  chains,  matrix,  positioning,  scopes,  decorations.pathmorphing,  shadows, calc}
\tikzset{
nonterminal/.style={rectangle, minimum size=6mm, very thick, draw=red!50!black!20, top color=white, bottom color=red!50!black!50, font=\itshape },
terminal/.style={rounded rectangle,  minimum size=6mm, very thick,draw=black!50, top color=white, bottom color=black!20, font=\ttfamily},
junction/.style={circle, draw }}
\pgfsetlinewidth{.4mm}
[/preamble]

\node (xddot) {};
\node (plus1) [junction,right=of xddot] {[N]};
\node(invM) [nonterminal,right=of plus1] {$\frac{1}{M_p}$};
\node(intT1) [nonterminal,right=of invM] {$\int$dt};
\node(intT2) [nonterminal,right=of intT1] {$\int$dt};
\node(x)    [right=of intT2] {};
\node(Cp) [nonterminal,below=of invM] {$C_p$};
\node(Kp) [nonterminal,below=of Cp] {$K_p$};

\path[->,every node]
(xddot)                 edge node[pos=-.1]    {$\ddot{x}$}                 (plus1)
(plus1)                edge node[above]        {\emph{ $M_p\frac{d\nu}{dt}$ }}     (invM)
(invM)                    edge node[above]         {\emph{ $\frac{d\nu}{dt}$ }}         (intT1)
(intT1)                edge node[above]        {\emph{ $\nu=\frac{d\nu}{dt}$ }}    (intT2)
(intT2)                edge node[pos=1.1]    {\emph{x}}                    (x)
($ (intT1.east)+(2mm,0)$)    edge[skip loopDL]                                (Cp.east)
(Cp.west)                 edge[skip loopLU]                                (plus1.south)
($ (intT2.east)+(2mm,0)$)     edge[skip loopDL]                                (Kp.east)
(Kp.west)                 edge[skip loopLU]                                 (plus1.south west);
%add minus signs to plus1 — can’t this be added to the skip loops above?
\node at ($(plus1.west)+(-.2,.2)$) {+};
\node at ($(plus1.south west)+(-.2,-.2)$) {$-$};
\node at ($(plus1.south)+(.2,-.2)$) {$-$};

\end{tikzpicture}

 

Some parts are still a little rough, but the capability is there.  In case you’re wondering, I’m using QuickLatex, which renders TikZ graphics.  I’m planning to write some more advanced posts in Dynamics and Controls using these tools, but for now here’s the code for the above diagram:

!\begin{tikzpicture}[node distance=5mm and 15mm, >=stealth, skip loopDL/.style={to path={-- ++(0,-.5) |- (\tikztotarget)}},skip loopLU/.style={to path={ -| (\tikztotarget)}}]
[+preamble]
\usepackage{tikz}
\usepackage{graphicx}
\usetikzlibrary{ arrows,  shapes.misc,  shapes.arrows,  chains,  matrix,  positioning,  scopes,  decorations.pathmorphing,  shadows, calc}
\tikzset{
nonterminal/.style={rectangle, minimum size=6mm, very thick, draw=red!50!black!20, top color=white, bottom color=red!50!black!50, font=\itshape },
terminal/.style={rounded rectangle,  minimum size=6mm, very thick,draw=black!50, top color=white, bottom color=black!20, font=\ttfamily},
junction/.style={circle, draw }}
\pgfsetlinewidth{.4mm}
[/preamble]

\node (xddot) {};
\node (plus1) [junction,right=of xddot] {[N]};
\node(invM) [nonterminal,right=of plus1] {$\frac{1}{M_p}$};
\node(intT1) [nonterminal,right=of invM] {$\int$dt};
\node(intT2) [nonterminal,right=of intT1] {$\int$dt};
\node(x)    [right=of intT2] {};
\node(Cp) [nonterminal,below=of invM] {$C_p$};
\node(Kp) [nonterminal,below=of Cp] {$K_p$};

\path[->,every node]
(xddot) edge node[pos=-.1] {$\ddot{x}$}                        (plus1)
(plus1) edge node[above]   {\emph{ $M_p\frac{d\nu}{dt}$ }}     (invM)
(invM)  edge node[above]   {\emph{ $\frac{d\nu}{dt}$ }}        (intT1)
(intT1) edge node[above]   {\emph{ $\nu=\frac{d\nu}{dt}$ }}    (intT2)
(intT2) edge node[pos=1.1] {\emph{x}}                          (x)
($ (intT1.east)+(2mm,0)$) edge[skip loopDL]                    (Cp.east)
(Cp.west) edge[skip loopLU]                                    (plus1.south)
($ (intT2.east)+(2mm,0)$) edge[skip loopDL]                    (Kp.east)
(Kp.west) edge[skip loopLU]                                    (plus1.south west);
%add minus signs to plus1 -- can't this be added to the skip loops above?
\node at ($(plus1.south west)+(-.2,-.2)$) {$-$};
\node at ($(plus1.south)+(.2,-.2)$) {$-$};

\end{tikzpicture}

LEVITATE

—Acronym says it all: The Lunar Exploration Vehicle for Intraplanetary Transport and Terrestrial Expansion. An enormous project, but a good time.

The EMA senior design spans two semesters; the first develops an idea into a consumer product, while the second tasks us to design an airplane, submarine, or spaceship. Last semester I developed BoomAlert, a device to warn sailboat crews of a dangerous boom movements. This semester Tim, Adam, Kevin, Tyler, and I are developing LEVITATE, the Lunar Exploration Vehicle for Intraplanetary Transport And Terrestrial Expansion. Props to Kevin for the NASA-worthy acronym.

We documented (somewhat) LEVITATE’s development over the semester, see Team LEVITATE. We’re also on Twitter, give us a follow.

From left: Tim, Kevin, Adam Tyler, and Ben
From left: Tim, Kevin, Adam Tyler, and Ben

Project Summary

LEVITATE is a lunar exploration vehicle capable of providing intra-lunar transportation of two astronauts to any scientifically interesting or resource-rich location by means of orbital and sub-orbital transfers. It has the capability to sustain two astronauts for up to fourteen Earth days at the remote site. LEVITATE is motivated by a dichotomy in the way our nation has previously planned to explore the Moon, as presented in the Review of U.S. Human Spaceflight Plans Committee’s analyses of possible lunar missions. LEVITATE enables global lunar access in addition to lunar base development.

Project Documents

RASC-AL Report [.pdf, 4.7MB]

RASC-AL Presentation [.pdf, 4.5MB]

RASC-AL Poster [.pdf, 1.6MB]

Ben’s Recap

Let’s keep it short: over the course of 66 days, 5 undergraduate Engineering Mechanics students designed a spaceship. The semester began with some pie-in-the-sky ideas on aerospace vehicles capable of carrying two people or 500 lbs…

…proceeded to some rocket science…

…included some enthusiasm…

…and ended with a 7″ stack of engineering drawings.

Assuming a standard daily consumption of 2 20oz bottles of Mt. Dew, each member drank approximately 20gal (78L) of the lime-green stimulant. Of course, this increase in consumption is inversely-mirrored by the daily decrease in sleep, as the May deadline approached. Thankfully, the feared correlation between frustration with Solidworks and optical mouse failure was not observed. All-told, team LEVITATE put a ton of work into the project, learned countless lessons about engineering design and documentation, team coordination, and individual motivation along the way, and left with an invaluable encapsulization of their undergraduate education.

RASC-AL Competition Summary

As briefly mentioned on the blog, we entered LEVITATE into the 2010 Revolutionary Aerospace Systems Concepts Academic Linkage forum, held in Cocoa Beach, FL. This program solicits undergraduate and graduate teams to solve general problems faced by NASA’s exploration efforts. Solutions to these problems are grounded in academic research, leverage existing technologies and systems, and optimize some essential parameter, usually mass or fuel consumed.

The key advantage of an intra-lunar vehicle like LEVITATE is that it allow mass (money) to be spent building a permanently-inhabited base at a single lunar location while providing access to the entire lunar surface. Thus, it combines the ‘Lunar Outpost’ concept — future missions reuse equipment and facilities launched on previous missions — with the ‘Lunar Global’ concept, where short missions are conducted at various locations, returning samples to Earth for analysis and never returning to the same location. Once on the lunar surface LEVITATE requires no Earth-launched resources. Assuming lunar resource gathering and processing is a significant activity, LEVITATE’s fuel can be collected with no additional effort during this processing. And since more than four lunar equipment landings are required to enable continual human habitation, there will be a surplus of spare landers on the lunar surface from which to salvage replacement parts for the majority of LEVITATE’s systems.

As you may appreciate above, LEVITATE was designed to every nut and bolt and, I would argue, that we gave the best presentation/paper/poster session of our vehicle in the undergraduate competition. The only outstanding elements of our design were those systems that we knew depended heavily on the other systems in the lunar architecture (outpost module, spacesuits, robotic assets, etc.) and/or those that were already of a sufficient technology readiness level (>TRL 6) to give us confidence in their availability. (This is why we fully designed the life support, vehicle structure, suitport airlocks, and habitat wall structure.) Unfortunately, from the perspective of the RASC-AL competition, this reliance on the lunar exploration architecture and the time pressure of our academic schedule prevented us from adequately documenting our vehicle design decisions. While I can attest to the background research performed on each system choice and our valuation of each option, these decisions were not conducted nor documented in the most rigorous way (namely trade studies). Our compressed development and decision-making process, combined with RASC-AL’s virtual requirement of trade studies, prevented us from placing in the competition. Despite that, I greatly enjoyed developing LEVITATE and my time in Florida.

A Sample Size D Drawing:

This assembly drawing is one of the panels that form LEVITATE’s pressure vessel.  The annotations refer to additional drawings that describe components of the wall panel.  This drawing describes how those parts should be arranged and fixed together.

BoomAlert

—A device to warn sailboat crews of dangerous boom movements; developed in EMA 469 with David Aguilar, Lisa McGill, Scott Sardina, and Jordan Wachs.

The EMA senior design spans two semesters; the first develops an idea into a consumer product, while the second tasks us to design an airplane, submarine, or spaceship. Over the first semester David Aguilar, Lisa McGill, Scott Sardina, Jordan Wachs, and I developed BoomAlert, a device to warn sailboat crews of dangerous boom movements. See also my spring design, LEVITATE.

If you want to watch our final presentation instead of reading, seek to 1:50 here.

BoomAlert alerts sailboat crew to dangerous motions of the sailboat boom known as autojibes. These occur when sailing with the wind and are due to poor captainship or random, unanticipable, changes in the wind. Immediately before the autojibe the sail is typically full-out, nearly perpendicular with the centerline of the boat. As the wind changes direction the boom quickly accelerates and swings across the cockpit to the other side of the boat, reaching rotational velocities of >2 rad/sec. These angular velocities are not very dangerous near the pivot point (gooseneck), but can reach 5-10 mph where the crew sits. If a crewmember is unaware, they can be struck by the boom, as seen here: (I would embed, but the video owner doesn’t want anyone to see his video. Begrudgingly, a link.)

To overcome this problem, BoomAlert senses boom accelerations and alerts the crew by aural and visual means. Here are the major parts:

Accelerometer Housing

We began our design with a sail on Lake Mendota to characterize sailboat boom movements. With a waterproof camera attached to the mast, looking upward at the underside of the boom, Dave simulated autojibes while I recorded videos of the boom sweeping from side to side. Returning to land, we analyzed these videos and determined angular positions, velocities, and accelerations, as seen on right. Based on these results, we decided to measure boom acceleration and trigger the alerts when acceleration crosses a user-set threshold. This threshold is determined by boom length and crew position along the boom, so that BoomAlert can be used on any size of boat.

The accelerometer box holds a 3-axis accelerometer which communicates with a microcontroller by the I2C two-wire serial communication protocol.

Control Box

The control box contains the system electronics, power supplies, and alert devices.  An Atmel ATMega 368 microcontroller compares the accelerometer readings against the acceleration threshold, and depending on the boom’s position, alerts the sailors to the motion.

Documents

View our slides [2.2MB]

SplitKey

—An ergonomic laptop keyboard that does not constrain portable computer form or design.

Laptop computers combine power with mobility and have recently usurped global desktop shipments. Users are computing for longer periods in a variety of locations yet laptop manufacturers often fail to consider the user’s comfort and health in the computer’s design. Specifically, one cannot enjoy an ergonomic computing experience on their laptop without sacrificing the computer’s portability.

Ergonomic keyboards are commonly available (if seldom used) but are often twice or three times the size of the laptop computer. Having taken apart laptops and keyboards, I realized that a simple improvement could be made to a laptop’s keyboard to significantly enhance user comfort without decreasing computer performance or mobility. I developed a removable laptop keyboard that can be further separated between those keys normally operated by the right and left hands. The laptop remains fully functional when the keyboard is attached and communication is accomplished by either wired or wireless means. Such an improvement allows for an increase in user comfort and potential aversion of the onset of musculoskeletal diseases.

I developed Split Key over fall 2007 and entered in the 2009 Innovation Days, winning the Sorenson design notebook competition and taking 3rd in the Tong prototype prize. I enjoyed considering, if briefly, the full scope of the idea — ergonomic research, laptop and keyboard patents, market considerations, and design optimizations. Please see my presentation or disclosure for more information:

Split Key from Ben Conrad on Vimeo.
Presentation [.pptx or .odp, 5.0MB] — As given on 2/12/09.

Disclosure [.pdf] — Idea description, ergonomic research, and market potential. I would appreciate any comments and hope to detail the prototype creation on Instructables…as time permits.

The Build Process: