An example of LLaVa, downloaded and run from Donald Papp's recent article.

[NB: This is not a comment on Justine Tunney's work, which is both excellent and valuable. I'm only pointing out that current AI systems leave a lot to be desired.]

The entire process took almost 24 minutes, and the description is *almost* accurate.

#
# LLaVa Command
#
/tmp/Pics: time /Data/llama/llava-v1.5-7b-q4-main.llamafile     --image DSCF2753.jpg --temp 0 -ngl 35     -e -p '### User: What do you see?\n### Assistant:'     --silent-prompt 2>/dev/null

The image features a large metal table with a silver top, sitting on
a white floor. On the table, there is an industrial-sized fan or
blower, which appears to be made of metal and has a circular shape.
This fan is placed in the center of the table, drawing attention due
to its size and design. The overall scene gives off a sense of a
workshop or a place where such equipment might be used for various
purposes.

real    23m40.456s
user    93m53.092s
sys    0m8.459s

The long execution time suggested that perhaps a smaller image would be faster, so I resized the image for a 2nd run.

The second run is completely inaccurate, with notably several hallucinated items.

/tmp/Pics/SmallImages: time /Data/llama/llava-v1.5-7b-q4-main.llamafile     --image DSCF2753Small.jpg --temp 0 -ngl 35     -e -p '### User: What do you see?\n### Assistant:'     --silent-prompt 2>/dev/null

The image features a room with a large metal table in the center.
On top of this table, there is an industrial-sized food processor
or blender, which appears to be made from metal and has a silver
color. The table occupies most of the space in the room, extending
almost all the way across the scene.

In addition to the main focus on the table and its contents, there
are several chairs placed around the room, with some located near
the edges of the image. A bench can also be seen in the background,
further emphasizing the room's purpose as a workspace or dining
area.

real    24m11.196s
user    96m11.241s
sys    0m6.162s

Food processor? Chairs?

This AI is not quite ready for prime time.

The original image was 4608x3456, the resized version (2nd run) was 533x44.

The image (large/small) given to LLaVa:

I'm using an older, but still beefy, NVidia graphics card with CUDA installed. I have a 4 core 4GHz system with 48GB of memory installed.

A recent Hackaday post describes the construction of a quarter-wave impedance matching circuit. The author was asking why his system shows a resonance at around 600 MHz.

Typing his circuit into SimSmith shows the following results.

The first image (above) shows the SimSmith simulation of his original circuit. The green line on the Smith chart shows that a 90 degree length of his 41.56 ohm cable will indeed match the 25 ohm load to - approximately - the 50 ohm generator. The line actually lands on 69.1 ohms, which reflects the fact that he's using a constructed 41.5 ohm line and not 35 ohm line (which would make an ideal match).

This next image shows SWR plotted as a function of frequency. His calculations indicate that the minimum SWR should be around 200 MHz, but was confused when his NanoVNA showed a minimum at 600 MHz.

The image above shows what is actually going on. I believe he's seeing the 2nd harmonic of his calculated frequency, and SimSmith indicates that there should be a 3rd harmonic as well.

SWR is not 1, which reflects the fact that his impedance match is not perfect - 69 ohms instead of 50 ohms - because his constructed transmission line is not the optimal value.

I needed to debounce a RasPi button in python, and found that the software in this link has problems: sometimes the button press is ignored.

Here's an improved version fixing the problem. It uses the GPIO hardware to initially detect the button press (rising or falling, or both) then uses a timer to detect changes in state for a user-selected debounce time.

A full library file implementation "Button.zip" can be found in the project files section, along with a simple test program.

DEBOUNCE_MS = 50                        # Debounce time, in ms
UPDATE_MS   = 5                         # Update/check time, in ms

class ButtonHandler(threading.Thread):
    def __init__(self, pin, func, edge='both', bouncetime=200):
        super().__init__(daemon=True)

        self.edge = edge
        self.func = func
        self.pin = pin
        self.bouncetime = bouncetime
        self.bounceleft = bouncetime
        self.bouncing   = 0
        self.prevpinval = GPIO.input(self.pin)

    def __call__(self, *args):
        if self.bouncing:
            return

        self.bouncing   = 1
        self.bounceleft = self.bouncetime
        self.prevpinval = GPIO.input(self.pin)
        self.timer = threading.Timer(UPDATE_MS/1000.0, self.Tick, args=args)
        self.timer.start()

    def Tick(self, *args):
        pinval = GPIO.input(self.pin)

        if self.edge == GPIO.RISING  and pinval == 0:
            self.bouncing = 0
            return

        if self.edge == GPIO.FALLING and pinval == 1:
            self.bouncing = 0
            return

        if pinval != self.prevpinval:
            self.bounceleft = self.bouncetime

        self.bounceleft -= UPDATE_MS

        if self.bounceleft <= 0:
            self.bouncing   = 0
            self.func(*args)
            self.prevpinval = pinval
            return

        self.prevpinval = pinval
        self.timer = threading.Timer(UPDATE_MS/1000.0, self.Tick, args=args)
        self.timer.start()

Reference to a discussion online.

Here's a picture of the PCB holder I designed. It has magnets in the base, to stick to any metallic surface.

The magnets have a surprisingly strong and stable holding force - enough that the system can hold a PCB on the metal bed of a CNC mill without bolts.

This one has washers at the far ends. This PCB slides in from the front and stops at the washers. Reverse one side (one washer in front, one at the rear) and the PCB is locked in place.

The side slots allow me to hold a PCB vertically or at a 45 degree angle. The elongated holes are for mounting on a mill table, and the threaded holes are for some attachments I made.

TL;DR

1. New version of the <alt><tab> selector is available
2. Environment variables can define the task order
3. Project files and wiki are on github

A new version of Alt-Tab

After nosing around the completely undocumented Cinnamon code for several more hours, I could find no place where the taskbar stores it's task list.

I *did* find a function that let me safely poke around in the source files and see what information is available:

Main.warningNotify(String1,String2);

Later, I found a function that appears to get an environment variable:

GLib.getenv(ORDERENV);

Main.getWorkspaceName(global.screen.get_active_workspace().index());

You can find the new file and documentation on the GitHub project, including installation instructions and more documentation.

Overview of the new version

Check the GitHub project, for more/better documentation.

The new Alt-Tab order is determined by the CLASS and TITLE of the application window.

The CLASS identifies the application, and will be something like "Firefox" or "Nemo".

The TITLE identifies what the application is showing, such as a specific web page (Firefox) or directory (Nemo). The TITLE is the string shown in the taskbar, and will be something like "Google - Mozilla Firefox" (for Firefox) or "Home" (for Nemo), depending on what your application is showing.

To show all window classes and titles:

#
# List all window titles
#
wmctrl -l -x | awk '{print substr($0,index($0,$5))}'

#
# List all window classes
#
wmctrl -l -x | awk '{ print substr($3,1+index($3,".")) }'

Setting the sort order

Environment variables in the user's .profile file can define the sort order.

1. In workspace n, the sort order is determined by "ALT_TAB_WORKSPACEn" if this variable exists.
2. Otherwise, the sort order is determined by "ALT_TAB_ORDER" if this variable exists.
3. Otherwise, the windows are sorted by title.

The ALT_TAB_xxxx variables contain multiple CLASS:TITLE specifiers separated by semicolon.

Workspaces are numbered from 1, not zero. The first (leftmost) workspace is "WORKSPACE1".

The variables are part of the user's original login, so changes must be made to the user's .profile file (and not, for example, the .bashrc file). After editing, log out and log back in for changes to take effect.

Examples

Example1:

export ALT_TAB_WORKSPACE1="Firefox;Nemo;Gnome-terminal"
export ALT_TAB_WORKSPACE2="Gnome-terminal:Edit;Gnome-terminal:Work;VirtualBox;Firefox;Nemo"

In WORKSPACE1 the alt-tab listing will have firefox leftmost (in first position), Nemo in 2nd position, the terminal in third position. Other windows will be to the right of the terminal.

In WORKSPACE2 the alt-tab listing will have both terminals leftmost, but the one titled "Edit" will come before (to the left) of the one titled "Work", in 2nd position. VirtualBox, Firefox, and Nemo will follow, then any unspecified windows.

Other workspaces will be sorted by title (the default).

Example2:

export ALT_TAB_ORDER="Firefox;Nemo;Gnome-terminal"
export ALT_TAB_WORKSPACE2="Gnome-terminal:Edit;Gnome-terminal:Work;VirtualBox;Firefox;Nemo"

WORKSPACE2 Alt-Tab will be as described above.

All other workspaces will show Firefox->Nemo->Gnome.

Example3:

#
# No preference in window order
#
#export ALT_TAB_ORDER="Firefox;Nemo;Gnome-terminal"

Alt-tab will sort by title, the default.

Named Workspaces

If you have named your workspace, use "ALT_TAB_" with the new workspace name.

Example4:

#
# Workspace named "PERSONAL"
#
export ALT_TAB_PERSONAL="Thunderbird;Firefox;Nemo"

The renamed workspace "PERSONAL" will show in the order Thunderbird -> Firefox -> Nemo

All other workspaces will sort by title, the default.

I'm on a campaign to remove minor annoyances in my life, and the alt-tab behavior in Cinnamon finally annoyed me enough that I had to change it.

The new version presents the task list in a fixed and predictable order every time alt-tab is activated, which allows me to use muscle memory to quickly switch between windows.

Update1: A diff listing below shows the changes more clearly.

Update2: Firefox and Chrome titles include the web page title; in other words, their window_title(), hence their position in the list, will change depending on which webpage is accessed.

The solution might be to sort on "Mozilla" or "Chrome" if the task name contains "Mozilla" or "Chrome". Perhaps if the title contains a dash, sort on the substring after the dash character. I'll look into that later if it becomes a problem or if enough people request it.

The Problem Statement

On linux/Cinnamon (and windows), pressing <alt><tab> pops up a list of active applications, allowing the user to navigate and select a window to switch to. When a different window is selected, the current window is pushed down, and the new window comes forward.

The problem is that alt-tab sorts the windows in least-recently-used order; meaning, the window you are in is the 1st position, the one you were in last is in 2nd position, and so on.

This works for switching between two - and only two - windows, but if you need three or more it quickly becomes a permutation engine. Selecting the 4th window puts the 1st window in 2nd place, the 2nd window in 3rd place, and so on.

For example, if you simultaneously use an editor for source, a command window to build, and a third window for test (seeing the results), you cannot quickly switch between windows because the ordering is always different. You have to stop, look at the list, recognize the icons, and then tell your fingers how many times to tap the <tab> key.

Add one or two more apps (a file explorer say, or a system monitor) and it rapidly becomes an exercise in fumbling and redoing while paying attention: your fingers *want* to learn a fixed action to switch to the editor, but half the time they go somewhere else and you have to stop, look, and recover.

It's annoying as hell.

Initial Attempts

My go-to solution for these sorts of problems is to go out on the net and see if someone else has solved it, then download their solution. Usually with an "apt-get install their-solution" command.

Apparently no one has done this for Alt-Tab. So far as I can tell, there's no add-on or applet that will change the behavior.

However, in looking around the net I accidentally found a reference to this file:

/usr/share/cinnamon/js/ui/appSwitcher/appSwitcher.js

Could editing this file change the alt-tab behavior?

Step 1: Is this the right file?

Linux comes with a long list of default annoyances, and the first step in fixing any of them is to find the right file to change. This can take anywhere from 4 hours to several days, depending on on the specific annoyance you want to change.

So when I found the file reference above, I knew that there was a fair chance I could address the issue without spending a lot of time finding the right file.

Maybe.

Editing Cinnamon files is roughly akin to walking a tightrope over a canyon with no net: it's trivial to completely bork your system in such a way that a complete system reinstall is the easiest fix.

Knowing this, I felt it was *likely* that messing up alt-tab *probably* wouldn't completely bork my system, since I could reboot and put things back without activating the alt-tab function.

I've been wrong about this before. To give you an idea of how easy this is, I typo'ed the filename of the screen saver executable, and Cinnamon went into an infinite error-popup-reload cycle that was almost impossible to get out of. You would *think* that missing a screen saver would not be a critical/must reboot error, but it was.

Looking through the directory, I noticed the file "classicSwitcher.js" has the following few lines [at about line 408]:

let title = window.get_title();
if (window.minimized) {
    this.label = new St.Label({ text: "[" + title + "]"});
    let contrast_effect = new Clutter.BrightnessContrastEffect();
    contrast_effect.set_brightness(-0.5, -0.5, -0.5);
    this._iconBin.add_effect(contrast_effect);
    }

It appears that minimized windows have their title enclosed in square brackets.

Let's make a *small* change to this file and see if that affects anything. I added "zz" to the beginning of the bracket text:

    this.label = new St.Label({ text: "zz[" + title + "]"});

Silently intoning, "Our Os who art in CPU, LINUX be thy name...", I carefully invoked the incantation of window manager reload: <ctrl><alt><esc>.

Like the strike of lightning during a storm, the window flashed briefly, the speakers crackled, and the system *seemed* to be working.

...I've been fooled by that before.

With trepidation, I carefully entered <alt><tab> and viewed the results.

Step 2: Can I change the ordering?

Going back to appSwitcher.js file, I noticed the following code snippet [about line 78]:

    // Sort by user time
    windows.sort(sortWindowsByUserTime);
    return windows;
    }

That looks promising. Let's comment that out and see what happens.

One flash of lightning and clap of thunder later (why do the speakers crackle when the desktop reloads?), and pressing alt-tab results in:

It's not obvious from the image, but the windows are now in Z-order. A little experimentation shows that they are *always* in Z-order, regardless of when they were last accessed.

Another success! Woot!

Don't get cocky! Baby steps...

Step 3: Can I fix the ordering?

The sortWindowsByUserTme function is a typical sorting callback. It compares two objects (in this case application windows) and returns -1, 0, or 1 depending on the ordering of the objects [about line 15]:

function sortWindowsByUserTime(win1, win2) {
    let t1 = win1.get_user_time();
    let t2 = win2.get_user_time();
    let m1 = win1.minimized;
    let m2 = win2.minimized;
    if (m1 == m2) {
        return (t2 > t1) ? 1 : -1;   
    }
    else {
        return m1 ? 1 : -1;
    }    
}

I want the window order fixed, so that alt-tab shows the same ordering every time it's invoked.

What I'd *like* to have is the windows shown in the same order as the taskbar at the bottom of my screen. That's apparently impossible (according to the internet), so I'll have to settle for something else.

Cinnamon source code is completely undocumented, so there's no way to tell what resources are available, or what functions can be called from the context of the app switcher. The best you can get is a list of functions available to the class being executed, and even that's hard because we don't know what that class we're in, or what the base classes are.

(I did actually find some documentation on Cinnamon, but it's apparently a different linux desktop package named "Cinnamon" that doesn't have "ClassicSwitcher" or "appSwitcher" in their reference docs. I also found a computer-generated listing of the classes, but containing no descriptive text or explanations.)

However, going back to the "zz" section, we know that window.get_title() is available to that class. The sort function is being passed two windows, so perhaps we can sort on the window title?

The new, improved code snippet reads [about line 15]:

function sortWindowsByUserTime(win1, win2) {
    let t1 = win1.get_title();
    let t2 = win2.get_title();
    return t1.localeCompare(t2);
//    let t1 = win1.get_user_time();
//    let t2 = win2.get_user_time();
//    let m1 = win1.minimized;
//    let m2 = win2.minimized;
//    if (m1 == m2) {
//        return (t2 > t1) ? 1 : -1;   
//    }
//    else {
//        return m1 ? 1 : -1;
//    }    
}

I re-enabled the call to the sorting function [originally line 78, now 84] and invoked the magical incantation of desktop reload, and...

Voila! The tasks are now sorted by title name, and the ordering is fixed. It never changes, except after adding or deleting a window.

Step 4: Fixing the default selection

The tasks are ordered by name and fixed order, but the task *after* the current task is highlighted. This means that you still can't use muscle memory to select a task, because the number of keypresses varies with your starting point.

Apparently the current task is active when the app list is invoked, and the act of pressing alt-tab moves the selection one position to the right.

This means that you can cycle through the list of applications with a single alt-tab press. Some people might prefer this, but I don't happen to like it. I want the highlighted selection to always be in the same position.

A quick perusal of the code shows that this is determined by the _currentIndex class variable, which is set when the application list is generated.

So I added a line to select the last window in the sorted list on startup, and the action of pressing alt-tab moves the selection to the first position.

Adding 1 line [at about 106]:

this._currentIndex = this._windows.indexOf(global.display.focus_window);
if (this._currentIndex < 0) {
    this._currentIndex = 0;
}
this._currentIndex = this._windows.length-1; // ADD THIS LINE

One press gets me to the command prompt always, two gets me to Chrome, three goes to the editor, and so on.

And this, which should be a checkbox in the preferences panel, only took a couple of hours to implement.

Not bad by linux standards!

Further research

Ideally, the user should be able to specify the application order somehow. It seems reasonable to use the taskbar ordering, and that would give the user a ready-made way to change the task list order, and the ordering would always be visible.

I'd love to be able to do that, but I don't know how to extract that information from within the Cinnamon app switcher, and as I mentioned there's no documentation anywhere.

If anyone knows how to accomplish this, please let me know in the comments.

Diff of two files

Here's a diff of appSwitcher.js with the original:

#/usr/share/cinnamon/js/ui/appSwitcher: 
diff appSwitcher.js appSwitcher.js.bak 
16,30c16,25
<     let t1 = win1.get_title();
<     let t2 = win2.get_title();
< 
<     return t1.localeCompare(t2);
< 
< //    let t1 = win1.get_user_time();
< //    let t2 = win2.get_user_time();
< //    let m1 = win1.minimized;
< //    let m2 = win2.minimized;
< //    if (m1 == m2) {
< //        return (t2 > t1) ? 1 : -1;   
< //    }
< //    else {
< //        return m1 ? 1 : -1;
< //    }    
---
>     let t1 = win1.get_user_time();
>     let t2 = win2.get_user_time();
>     let m1 = win1.minimized;
>     let m2 = win2.minimized;
>     if (m1 == m2) {
>         return (t2 > t1) ? 1 : -1;   
>     }
>     else {
>         return m1 ? 1 : -1;
>     }    
106,107d100
<         this._currentIndex = this._windows.length-1;

Some images for a response on the blog.

You can make an improvised switch by pressing two thumb tacks into the jaws of a clothespin, and soldering wires to the nails that stick through.

Then put something between the jaws to break the contact.

For example, grab the plastic tab that holds a loaf of bread shut and tie some fishing line to that. Place the plastic tab between the jaws, run the line across a doorway or path, and anchor the end to the wall somehow.

When a person enters the room/crosses the path, their leg snags the fishing line and pulls the tab out from the jaws of the clothespin, completing the circuit.

(Note: The particular buzzer used is really, *really* loud!)

(From the article, you can put an aspirin between the jaws to detect moisture.)

The version below includes a battery and a transistor socket. Stick the wires of a flashbulb into the socket and use the plastic tab as described above to make a flash-bulb warning of intruders.

Also of note: It's hard to see from the photo, there are 2 thumb tacks sticking out from the base of the battery. Take the whole unit and press it into the side of a tree or wooden molding and run the trip wire across the room to another thumbtack.

Takes about a minute to install 1 intruder sensor.

I probably shouldn't mention this, but mount a 35mm film canister on the clothespin, put the flashbulb *inside* the canister, and fill the canister with gunpowder.

This makes a very satisfying flash *and* bang for unwanted intruders!

It's also reasonably safe, assuming you use a plastic film canister and not a metal one.

I couldn't immediately find one of those or I would have posted an image.

[A Hackaday article submitted for the "we're hiring" article.]

[Third attempt. I can't seem to find a good enough article to write about for Hackaday, so maybe I'll just compose one of my own. A "good enough" article needs a video, is interesting, and not already have a HAD article covering it.]

[Oh, wait! Here's one...]

December 4, 2016 by Peter Walsh

One of the best things about the Hackaday prize is that it presents all manner of great projects to the world to build, modify, and learn from. One of these is the Thor 3-d printed robotic arm.

Thor is not your typical hobbyist or robotics club build, it's pretty much a scaled-down industrial robotic arm in a desktop configuration. The yaw­-roll­-roll­-yaw­-roll­-yaw configuration is the same as found in many industrial robots on the market.

The arm has six degrees of freedom using seven stepper motors, some of which are gear-reduced for greater torque. The design hides the internal mechanism: all the pulleys, belts and wiring are enclosed, making the whole project kid safe.

Steppers are controlled by an Arduino Mega using a specially-designed 7-motor driver shield and pololu motor drivers. The system could probably also be driven by a couple of RAMPS boards, and the project logs talk about using a smoothie board to control 5 of the seven motors.

Thor is 3-d printed plus hardware, and the entire kit looks like it would be perfect for learning about industrial robotics, solving a Rubik's cube, or perhaps stirring your tea.

We've seen robotic arm projects on Hackaday before, including one made from cardboard.

Check out the video of Thor in action after the break.

Posted in Arduino Hacks, robots hacks

Tagged robot arm, servo motor