OK, sit down, everyone — we don’t want you falling over and hurting yourself when you learn the news that actually yes, your phone has been listening to your conversations all along. Shocking, we know, but that certainly seems to be what an outfit called Cox Media Group (CMG) does with its “Active Listening” software, according to a leaked slide deck that was used to pitch potential investors. The gist is that the software uses a smartphone’s microphone to listen to conversations and pick out keywords that it feeds to its partners, namely Google, Facebook, and Amazon so that they can target you with directed advertisements. Ever have an IRL conversation about something totally random only to start seeing references to that subject pop up where they never did before? We sure have, and while “relationship mining” seemed like a more parsimonious explanation back in 2017, the state of tech makes eavesdropping far more plausible today. Then there’s the whole thing of basically being caught red-handed. The Big Three all huffed and puffed about how they were shocked, SHOCKED to learn that this was going on, with reactions ranging from outright denial of ever partnering with CMG to quietly severing their relationship with the company. So much for years of gaslighting on this.

In other dystopian news, the American Radio Relay League just wrote a $1 million check to end a ransomware attack. According to an ARRL statement, unidentified “threat actors” found their way into computer systems at the group’s Newington, Connecticut headquarters and related cloud-based systems, which allowed them to install encryption packages on laptops, desktops, and servers running a variety of operating systems. The ARRL’s crisis team managed to talk the cyberattackers down from their original demand of several million dollars to just a million, which all things considered was probably the path of least resistance and lowest cost. It’s a shame that things have come to that, but here we are.

The long saga of Starliner’s first crewed test flight is finally over, as the beleaguered spacecraft pushed back from the International Space Station and headed back to a midnight landing in New Mexico on Saturday. The return was sans crew, of course, with NASA being unwilling to risk the lives of astronauts Suni Williams and Butch Wilmore in a spacecraft that hadn’t really performed up to snuff on the way up to the ISS. As if the leaky thrusters weren’t enough, just before the hatches were closed Wilmore reported weird noises coming from a speaker in Starliner. He managed to capture the sounds on his mic for Mission Control, which for all the world sounded like someone repeatedly banging on a pipe in the distance. The weird thing about the sound is the regularity, which sounded a little faster than one per second. We’re keen to see if NASA shares any in-depth engineering information on this and all the other Starliner anomalies now that the craft is back on the ground.

If you’ve ever had to do extensive overhead work, such as sanding or painting ceilings, or working under a car on a lift, you know the burn that starts to set in after just a short while of holding your arms over your head. Up to now, the only way to fix that was either hit the gym and work on upper body strength, or find another way to make a living. But now that we’re living in the future, you can just strap on your own exoskeleton backpack and take a load off the robotic way. Perhaps unsurprisingly, the ExoActive exoskeleton comes from Festool, best known for its wonderfully well-engineered premium tools that often command a premium price. The ExoActive is battery-powered and straps on like a backpack with extensions that support the upper arms. It can be set to different work heights and provides a boost in lifting power, taking some of the weight off your shoulder girdle and transmitting it to your lower back. Unlike other exoskeletons we’ve seen breathless press releases for, this one seems like something you can buy right now. Sure, it’s expensive, but it’s a fraction of the cost of shoulder surgery.

And finally, Animagraffs is back with an incredibly detailed look inside the inner workings of a 16th-century sailing vessel. The video really captures what it took to build vessels that could (just barely) sail around the world for the first time. We loved the explanation of the rigging, especially the differences between the standing rigging and the running rigging. If you don’t know your clewline from your backstay, this Blender tour de force will set you straight.

Browse AI is an easy-to-use tool that allows you to extract and monitor data from any website, without coding. The prebuilt robots can be trained in 2 minutes and can extract specific data from various websites such as LinkedIn, Indeed, ProductHunt, Eventbrite, Google, Upwork, and more. You can also set up monitoring and get notified […]

Source

Last time I tried to convince you that, if you haven’t already, you should try running your 3D printer with Klipper. There are several ways to actually make it work.

The first thing you need is something to run the Klipper host. Most people use a Raspberry Pi and if you already have one that runs OctoPrint, for example, you might well use it. Just tuck your SD card away in case you give up and install a fresh Linux system on a new card.

However, a Pi isn’t your only option. You should be able to make it work on nearly anything that runs Linux. We’ve even seen it running on Windows under WSL. If you have an old laptop that can run Linux, that would work, too. We’ve even heard it works on a Chromebook.

The other option is to get a “pad.” Several vendors make touchscreens with some Linux single-board computer bundled together with Klipper preinstalled. For example, there is the Creality Sonic Pad, along with similar devices from other 3D printing companies.

If you decide to go that route, you might want to make sure it is easy to install your own software easily. Some pads, like the Creality unit, are notorious for having so much customization that they don’t lend themselves to upgrades unless they come from the manufacturer. In some cases, you can wipe out the stock firmware and install a normal operating system, but at that point, you could probably just buy a Pi and a touchscreen, right?

Installation

If you use something like a pad, it probably has a menu option to provide prebuilt firmware for your printer. Typically, you let it save the code to an SD card or a USB stick and then you are expected to flash it to your printer which, of course, depends on what kind of printer you have.

If you are rolling your own, you use a menu configuration program something like building a Linux kernel. If you have a pre-built configuration file, it will probably tell you in its comments what things you should pick. You need to know, for example, the type of CPU your board has, the bootloader offset, and if you are connecting via USB or serial. You can find details on the Klipper project pages.

Installing the Linux side is easy because there is a nice script called KIHUH. The easiest thing to do is clone the Git repository and run it. From there, you can install Klipper, Moonraker, Fluidd, Mainsail, and some other things, too.

The real trick isn’t installing the software. The challenge is creating a proper configuration file for your printer. If you have a totally stock and popular printer, you’ll probably be in luck. But, how many of us can say that?

Start with the GitHub list to see if your printer or board is there. Even if it isn’t an exact match for your hardware, it will give you a start. For example, my custom printer is a Fysetc Spider, but the canned configuration is for a core XY machine, which means I have to make changes.

Even if you get a pad that claims to be “plug and play,” don’t count on it. For example, a Creality Sonic Pad’s instructions for installing with a Creality Ender 3 first asks you to take the printer apart to determine the type of motherboard you have. That’s not really plug and play! Any deviation from the stock machine is likely to require you to change the default profile.

Ch…Ch…Ch…Changes

In addition to just setting things up to match my exact hardware, I also needed to adjust the extruder step count. That has to be simple, right? Most firmware requires you to plug in the number of steps per millimeter of filament.

Klipper, on the other hand, wants to know how many millimeters extrude from a full rotation of the stepper. If you know how many steps (and microsteps) your printer uses, you can easily calculate either number from the other. For example, if you have 200 steps per rotation and 16 microsteps, that’s 3200 steps total. If your current steps per millimeter is 100, then your Klipper “rotation distance” is 3200/100=32.

Configuration Example

I had another major change to make. My printers have a non-standard filament sensor that detects the filament moving. That way, it can detect not only broken filaments but jammed filaments, too.

To install it, I had to add a few lines to my printer.cfg file and restart Klipper. Since I have more than one printer with the same sensor, I put all the lines in a single file and then included it in each printer. So the printer.cfg change was very simple:

[include sfs.cfg]

Then the real work is in sfs.cfg:

[filament_motion_sensor SFS_T0]
detection_length: 10.00 
extruder: extruder
switch_pin: ^PA4 
pause_on_runout: True 
event_delay: 3.0
pause_delay: 0.5
runout_gcode:
  M117 Runout Detected!

[delayed_gcode DISABLEFILAMENTSENSOR] 
initial_duration: 1
gcode:
 SET_FILAMENT_SENSOR SENSOR=SFS_T0 ENABLE=0

[gcode_macro SFS_ENABLE] ; Add this to PRINT_START
description: Enable smart filament sensor
gcode:
  M117 ENABLING the Smart Filament Sensor
  G92 E0
  SET_FILAMENT_SENSOR SENSOR=SFS_T0 ENABLE=1

[gcode_macro SFS_DISABLE] ; Add this to PRINT_END and PRINT_CANCEL
description: Disable smart filament sensor
gcode:
  M117 DISABLING the Smart Filament Sensor
  G92 E0
  SET_FILAMENT_SENSOR SENSOR=SFS_T0 ENABLE=0

This defines a few macros you can use elsewhere. Like Python, the indentation matters. You can organize your files using [include], and that’s especially useful if you have multiple printers that can share files.

Reference

So, how do you know what’s available? The Klipper reference. It will show you all the configuration sections you can use and what can possibly go in them. Don’t forget that some features — like print status notifications — will be in the Moonraker configuration which is a separate document.

Since the system is in Python, you can hack on it to your heart’s content. Just back up first. For example, you can add some custom Python scripts in the klipper/extras directory, like the one that can run arbitrary system commands from G-code.

Tinkering is what most of us like the best, and there’s plenty of opportunity to tinker with here. Klipper is also a good way to put new life in a very old printer since what runs on the printer is very simple, and all the heavy lifting is done elsewhere.

Klipper can easily do adaptive bed leveling, for example. If you can work in Python, it is also easy to experiment with things like exotic sensors.

A team at Google has spent a lot of time recently playing table tennis, purportedly only for science. Their goal was to see whether they could construct a robot which would not only play table tennis, but even keep up with practiced human players. In the paper available on ArXiv, they detail what it took to make it happen. The team also set up a site with a simplified explanation and some videos of the robot in action.

In the end, it took twenty motion-capture cameras, a pair of 125 FPS cameras, a 6 DOF robot on two linear rails, a special table tennis paddle, and a very large annotated dataset to train multiple convolutional network networks (CNN) on to analyze the incoming visual data. This visual data was then combined with details like knowledge of the paddle’s position to churn out a value for use in the look-up table that forms the core of the high-level controller (HLC). This look-up table then decides which low-level controller (LLC) is picked to perform a certain action. In order to prevent the CNNs of the LLCs from ‘forgetting’ the training data, a total of 17 different CNNs were used, one per LLC.

The robot was tested with a range of players from a local table tennis club which made clear that while it could easily defeat beginners, intermediate players pose a serious threat. Advanced players completely demolished the table tennis robot. Clearly we do not have to fear our robotic table tennis playing overlords just yet, but the robot did receive praise for being an interesting practice partner.

Large Language Models (LLMs) can produce extremely human-like communication, but their inner workings are something of a mystery. Not a mystery in the sense that we don’t know how an LLM works, but a mystery in the sense that the exact process of turning a particular input into a particular output is something of a black box.

This “black box” trait is common to neural networks in general, and LLMs are very deep neural networks. It is not really possible to explain precisely why a specific input produces a particular output, and not something else.

Why? Because neural networks are neither databases, nor lookup tables. In a neural network, discrete activation of neurons cannot be meaningfully mapped to specific concepts or words. The connections are complex, numerous, and multidimensional to the point that trying to tease out their relationships in any straightforward way simply does not make sense.

Neural Networks are a Black Box

In a way, this shouldn’t be surprising. After all, the entire umbrella of “AI” is about using software to solve the sorts of problems humans are in general not good at figuring out how to write a program to solve. It’s maybe no wonder that the end product has some level of inscrutability.

This isn’t what most of us expect from software, but as humans we can relate to the black box aspect more than we might realize. Take, for example, the process of elegantly translating a phrase from one language to another.

I’d like to use as an example of this an idea from an article by Lance Fortnow in Quanta magazine about the ubiquity of computation in our world. Lance asks us to imagine a woman named Sophie who grew up speaking French and English and works as a translator. Sophie can easily take any English text and produce a sentence of equivalent meaning in French. Sophie’s brain follows some kind of process to perform this conversion, but Sophie likely doesn’t understand the entire process. She might not even think of it as a process at all. It’s something that just happens. Sophie, like most of us, is intimately familiar with black box functionality.

The difference is that while many of us (perhaps grudgingly) accept this aspect of our own existence, we are understandably dissatisfied with it as a feature of our software. New research has made progress towards changing this.

Identifying Conceptual Features in Language Models

We know perfectly well how LLMs work, but that doesn’t help us pick apart individual transactions. Opening the black box while it’s working yields only a mess of discrete neural activations that cannot be meaningfully mapped to particular concepts, words, or whatever else. Until now, that is.

Recent developments have made the black box much less opaque, thanks to tools that can map and visualize LLM internal states during computation. This creates a conceptual snapshot of what the LLM is — for lack of a better term — thinking in the process of putting together its response to a prompt.

Anthropic have recently shared details on their success in mapping the mind of their Claude 3.0 Sonnet model by finding a way to match patterns of neuron activations to concrete, human-understandable concepts called features.

A feature can be just about anything; a person, a place, an object, or more abstract things like the idea of upper case, or function calls. The existence of a feature being activated does not mean it factors directly into the output, but it does mean it played some role in the road the output took.

With a way to map groups of activations to features — a significant engineering challenge — one can meaningfully interpret the contents of the black box. It is also possible to measure a sort of relational “distance” between features, and therefore get an even better idea of what a given state of neural activation represents in conceptual terms.

Making Sense of it all

One way this can be used is to produce a heat map that highlights how heavily different features were involved in Claude’s responses. Artificially manipulating the weighting of different concepts changes Claude’s responses in predictable ways (video), demonstrating that the features are indeed reasonably accurate representations of the LLM’s internal state. More details on this process are available in the paper Scaling Monosemanticity: Extracting Interpretable Features from Claude 3 Sonnet.

Mapping the mind of a state-of-the-art LLM like Claude may be a nontrivial undertaking, but that doesn’t mean the process is entirely the domain of tech companies with loads of resources. Inspectus by [labml.ai] is a visualization tool that works similarly to provide insight into the behavior of LLMs during processing. There is a tutorial on using it with a GPT-2 model, but don’t let that turn you off. GPT-2 may be older, but it is still relevant.

Research like this offers new ways to understand (and potentially manipulate, or fine-tune) these powerful tools., making LLMs more transparent and more useful, especially in applications where lack of operational clarity is hard to accept.

It’s official: [Engineer Bo] wins the internet with a video titled “Finding NEMA 17,” wherein he builds a dynamometer to find the best stepper motor in the popular NEMA 17 frame size.

Like a lot of subjective questions, the only correct answer to which stepper is best is, “It depends,” and [Bo] certainly has that in mind while gathering the data needed to construct torque-speed curves for five samples of NEMA 17 motors using his homebrew dyno. The dyno itself is pretty cool, with a bicycle disc brake to provide drag, a load cell to measure braking force, and an optical encoder to measure the rotation of the motor under test. The selected motors represent a cross-section of what’s commonly available today, some of which appear in big-name 3D printers and other common applications.

[Bo] tested each motor with two different drivers: the TMC2209 silent driver to start with, and because he released the Magic Smoke from those, the higher current TB6600 module. The difference between the two drivers was striking, with lower torque and top speeds for the same settings on each motor using the TB6600, as well as more variability in the data. Motors did better across the board with the TBC6600 at 24 volts, showing improved torque at higher speeds, and slightly higher top speeds. He also tested the effect of microstepping on torque using the TBC6600 and found that using full steps resulted in higher torque across a greater speed range.

At the end of the day, it seems as if these tests say more about the driver than they do about any of the motors tested. Perhaps the lesson here is to match the motor to the driver in light of what the application will be. Regardless, it’s a nice piece of work, and we really appreciate the dyno design to boot — reminds us of a scaled-down version of the one [Jeremey Fielding] demonstrated a few years back.