Broadcast Engineer at BellMedia, Computer history buff, compulsive deprecated, disparate hardware hoarder, R/C, robots, arduino, RF, and everything in between.
3927 stories
·
4 followers

A big chunk of Leonardo da Vinci's notebooks have been digitized and can be viewed online

1 Share

The British Library has digitized 570 loose pages of notes written and drawn by Leonard da Vinci to compile a notebook which is called, The Codex Arundel.

You can view the document online for free, although it's written in Italian and uses his "characteristic left-handed mirror-writing (reading from right to left)." The Guardian suggests enjoying the work of the self-taught Renaissance man as it is, without translation:

The digitised British Library manuscript is a fascinating artefact in itself, just to browse. You don't need a translation to appreciate the beauty and wonder of Leonardo's mind. This is a great work of art, in a precociously conceptual genre that has been emulated by modern artists such as Joseph Beuys and Cy Twombly.

The Codex includes "diagrams, drawings and brief texts" which cover "a broad range of topics in science and art, as well as personal notes." The British Library describes some of Da Vinci's insights:

His notebooks combine detailed observation with notes of experiments. Even if he did not actually undertake the experiments, he described what could be tried. Many of his insights foreshadowed scientific research by many centuries. For example:

Leonardo repudiated perpetual motion, understood the principle of relative motion, and foreshadowed Newton's Third Law by two centuries: "For every action there is an opposite and equal reaction."

He rejected the notion that the Biblical flood was responsible for depositing fossils many miles from their origin and deduced the existence of very long spans of geological time.

By dissecting humans and animals, Leonardo made many anatomical and some physiological discoveries.

He investigated optics and perception with subtle experiments, explaining why the sky is blue, arguing that light has a finite velocity and travels in straight lines, and deducing the existence of a surface within the eye that receives light from a wide field of view.

Leonardo formulated the law of the flow of currents: "All motion of water of uniform breadth and surface is stronger at one place than at another according as the water is shallower there than at the other."

(Open Culture)

Previously: Students build working version of Leonardo da Vinci's self-supporting bridge

Read the whole story
tekvax
16 hours ago
reply
Burlington, Ontario
Share this story
Delete

This Isn’t The R2-D2 Controller You’re Looking For

1 Share

Who loves a good R2-D2 robot? Everyone, but especially young Star Wars fans who — frustratingly — have no problem spotting a controller and spoiling the illusion of an R2 unit brought to life. [Bithead942]’s concealed his R2-D2’s remote and re-establishes the illusion of an autonomous droid — no Jedi mind-tricks necessary.

[Bithead942] prefers to accompany his droid in traditional a Rebel Alliance pilot’s suit, so that gives him a bit of extra space under the jumpsuit to help conceal the controller. Dismantling a Frsky Taranis X9D controller, [Bithead942] meditated on how to use it while so concealed. In a stroke of insight, he thought of his unused Wiimote nunchucks, and launched into the build.

Since he only wanted to use the joystick and buttons, he had to perform a bit of circuit sidestepping and run some extra wires to get all the functionality he wanted from the nunchuck. That achieved, an appropriately sized project box needed to be cut to size with a lightsab– a band-saw and glued together, punching some holes for the various buttons, wires, cords, barrel plug for recharging, and the antenna in the process. Like a Jedi — or Sith! — using the force to guide them in building their lightsaber, [Bithead942]’s remote worked almost perfectly on the first try.

With the project box riveted to a padded shoulder harness, it is barely noticeable under [Bithead942]’s costume, and wrist straps manage the cables along the length of his arms while also letting him drop the nunchucks to hang if needed. Shortly after finishing he took his R2-unit for a test-run using this new setup at a convention — with great success! He did run into a few issues: notably, the harness moved around a bit too much for comfort and the rocker switch that controlled the head rotation fell apart a few times,  so they’re getting swapped out. The concealability of the nunchucks are a vast improvement over the bluntly conspicuous controller, but aren’t perfect. Still, there were no heat issues and other attendees were generally amazed at the seemingly independent droid. When it comes to figuring out how the BB-8 droid from the recent movies works, we have you covered too.


Filed under: nintendo wii hacks, robots hacks





Read the whole story
tekvax
2 days ago
reply
Burlington, Ontario
Share this story
Delete

SCiO “Pocket Molecular Scanner” Teardown

1 Share

Some of you may remember the SCiO, originally a Kickstarter darling back in 2014 that promised people a pocket-sized micro spectrometer. It was claimed to be able to scan and determine the composition of everything from fruits and produce to your own body. The road from successful crowdsourcing to production was uncertain and never free from skepticism regarding the promised capabilities, but the folks at [Sparkfun] obtained a unit and promptly decided to tear it down to see what was inside, and share what they found.

The main feature inside the SCiO is the optical sensor, which consists of a custom-made NIR spectrometer. By analyzing the different wavelengths that reflect off an object, the unit can make judgments about what the object is made of. The SCiO was clearly never built to be disassembled, but [Sparkfun] pulls everything apart and provides some interesting photos of a custom-made optical unit with an array of different sensors, various filters, apertures, and a microlens array.

It’s pretty interesting to see inside the SCiO’s hardware, which unfortunately required destructive disassembly of the unit in question. The basic concept of portable spectroscopy is solid, as shown by projects such as the Farmcorder which is intended to measure plant health, and the DIY USB spectrometer which uses a webcam as the sensor.


Filed under: chemistry hacks, teardown



Read the whole story
tekvax
2 days ago
reply
Burlington, Ontario
Share this story
Delete

Old Intercom Gets Googled with Raspberry Pi and AIY Hat

1 Share

Old Radio Shack intercom; brand new Google Voice interface for a Raspberry Pi. One of these things is not like the other, but they ended up together in this retro-look Google Voice interface, and the results are pretty slick.

The recipient of the Google hive-mind transplant was one of three wireless FM intercoms [MisterM] scored for a measly £4. Looking much as they did when they were the must-have office tool or home accessory for your modern mid-80s lifestyle, the intercom case was the perfect host for the Pi and the Google AIY hat. Only the case was used — not even the original speaker made it into the finished product. The case got a good scrubbing, a fresh coat of paint to perk up the gone-green plastic, and an accent strip of Google’s logo colors over the now-deprecated station selector switch. [MisterM] provided a white LED behind the speaker grille for subtle feedback. A tap of the original talk bar gets Google’s attention for answers to quick questions, and integration into the family’s existing home automation platform turns the lights on and off. See it in action after the break.

[MisterM] was lucky enough to score an AIY hat for free, and as far as we know they’re still hard to come by. If you’re itching to try out the board, fear not — turns out you can roll your own.


Filed under: classic hacks, google hacks



Read the whole story
tekvax
2 days ago
reply
Burlington, Ontario
Share this story
Delete

Linux Fu: Better Bash Scripting

1 Share

It is easy to dismiss bash — the typical Linux shell program — as just a command prompt that allows scripting. Bash, however, is a full-blown programming language. I wouldn’t presume to tell you that it is as fast as a compiled C program, but that’s not why it exists. While a lot of people use shell scripts as an analog to a batch file in MSDOS, it can do so much more than that. Contrary to what you might think after a casual glance, it is entirely possible to write scripts that are reliable and robust enough to use in many embedded systems on a Raspberry Pi or similar computer.

I say that because sometimes bash gets a bad reputation. For one thing, it emphasizes ease-of-use. So while it has features that can promote making a robust script, you have to know to turn those features on. Another issue is that a lot of the functionality you’ll use in writing a bash script doesn’t come from bash, it comes from Linux commands (or whatever environment you are using; I’m going to assume some Linux distribution). If those programs do bad things, that isn’t a problem specific to bash.

One other limiting issue to bash is that many people (and I’m one of them) tend to write scripts using constructs that are compatible with older shells. Often times bash can do things better or neater, but we still use the older ways. For example:

if [ $X -gt 0 ] 
then ....
fi

This works in bash and a lot of other similar shells. However, bash can do better:

if [[ $X > 0 ]]
then ...
fi

Features

Don’t think bash is a programming language? It has arrays, loops, sockets, regular expression matching, file I/O, and lots more. However, there are a few things you should know when writing scripts that you expect to work well. You might add your own items to this list, but this one is what comes to my mind:

  • Use “set -o errexit” to cause the script to exit if any line fails
  • Use “set -o nounset” to cause an error if you use an empty environment variable
  • If you don’t expect a variable to change, declare it readonly
  • Expect variables could have spaces and quote accordingly
  • Use traps to clean up your mess

Exit on Error

If you use “set -o errexit” then any line that returns a non-zero error code will stop script execution. You might object that you want to test for that condition like this:

some_command
if [[ $? != 0 ]]
then 
   recover
fi

If you use the errexit flag, that test will never occur because once some_command throws the error, you are done. Simply rewrite like this:

some_command || recover

The effect is if some_command returns true (that is, zero), then bash knows the OR operator is satisfied so it doesn’t run any more commands. If it fails, then bash can’t tell if the OR is satisfied or not, so it runs recover. The exit code of the entire thing is either 0 from some_command or the exit code of recover, whatever that is.

Sometimes you have a command that could return an error and you don’t care. That’s easy to fix:

some_other_command || true

By the way, usually, the last item in a pipeline determines the result. For example:

a | b | c

The exit code of that line is whatever c returns. However, you can “set -o pipefail” to cause any error code in the pipe to halt the script. Even better is the $PIPESTATUS variable which is an array with all the exit codes from the last pipeline. So whatever program b returned will be in ${PIPESTATUS[1]}, in the above example.

Unset Variables

Using “set -o nonunset” forces you to initialize all variables. For example, here’s a really bad script (don’t run it):

TOPDIR=tmp
#rm -rf /${TOPDIRR}

You can argue this isn’t great code, but regardless, because TOPDIR has a typo in the last line, you’ll erase your root directory if this runs without the protective comment in front of the rm. This works for command line parameters, too, so it will protect you if you had:

bad_cmd /$1

Readonly

Many times you set a variable and you really need a constant. It shouldn’t change as the script executes and if it does that indicates a bug. You can declare those readonly:

readonly BASEDIR="~/testdir"
readonly TIMEOUT_S=10

Expect Spaces

File systems allow spaces and people love to use them. This can lead to unfortunate things like:

rm $2

When $2 is something like “readme.txt” that’s fine. However, if $2 is “The quick red fox” you wind up trying to erase four files named “The,” “quick,” “red,” and “fox.” If you are lucky, none of those files exist and you get errors. If you are unlucky, you just erased the wrong file.

The simple answer is to quote everything.

rm "$2"

If you ever use $@ to get all arguments, you should quote it to prevent problems. Consider this script:

#!/bin/bash
function p1
{
  echo $1
}

p1 $@
p1 "$@"

Try running the script with a quoted argument like “the quick red fox”. The first function call will get four arguments and the second call will get only one, which is almost surely what you intended.

Traps

It isn’t uncommon for scripts to create temporary lock files and other things that need cleaning up if the script stops. That’s what the trap command is for. Suppose you are working on building a file called /tmp/output.data and you want to remove it if you don’t get a chance to complete. Easy:

trap "rm -f /tmp/output; exit" INT TERM EXIT

You can look up the trap command for more details, but this is a great way to make things happen when a script ends for any reason. The exit command in quotes, by the way, is necessary or else the script will attempt to keep running. Of course, in an embedded system, you might want that behavior, too.

You probably want to remove the trap before you are done unless you really want output.data deleted, so:

trap - INT TERM EXIT

Wrap Up

You should consider turning off features you don’t need, especially if taking input from outside your script. For example, using “set -o noglob” will prevent bash from expanding wildcards. Of course, if you need wildcards, you can’t do this — at least not for the part of the script that uses them. You can also use “shopt -s failglob” which will cause wildcards to throw an error, if you want to secure your script.

Speaking of security, be very careful running user input as commands. Security is an entirely different topic, but even something that seems innocent can be maniuplated to do bad things if you are not careful. For example, suppose you secure sudo to allow a few commands and you offer the script:

sudo -u protuser "$@"

If sudo is set up right, what’s the harm? Well… the harm is that I can pass the argument “-u root reboot” (for example) and sudo will decide I’m root instead of protuser. Be careful!

There are a lot of tricks to writing bash scripts that are portable. I don’t care about those in this context because if I’m deploying an embedded system on a Raspberry Pi, I will control the configuration so that I know where /tmp is and where bash is located and what version of different programs are available. However, if you are distributing scripts to machines you don’t control, you might consider searching the internet about bash script portability.

If you want to catch a lot of potential errors in scripts (including some portability issues) you can try ShellCheck. You might also appreciate Google’s shell style guide. If you aren’t sure bash is really a programming language, this should convince you.


Filed under: Hackaday Columns, linux hacks, Skills, Software Development



Read the whole story
tekvax
2 days ago
reply
Burlington, Ontario
Share this story
Delete

This car was lifted into the air by a tornado in Hamburg, NY. The owner's home security camera caught it.

1 Share

In Hamburg, NY, Kevin Karas' home surveillance camera captured a tornado touching down and lifting his car and pretty much everything else around it right up into the air.

(more…)

Read the whole story
tekvax
2 days ago
reply
Burlington, Ontario
Share this story
Delete
Next Page of Stories