XBOX Adaptive Controller (XAC) with Custom Arduino Joystick — Working Code

At long last I’ve revisited my problem with getting the Arduino Leonardo / Pro Micro to work with the XBOX Adaptive Controller (XAC). This code now works with the XAC! Huzzah!

More to come. I’m working on a Nintendo JoyCon Joystick version for a user with limited mobility.

//=================================================================================

include “Joystick.h”

//=================================================================================

Joystick_ Joystick(JOYSTICK_DEFAULT_REPORT_ID,
JOYSTICK_TYPE_JOYSTICK, 1, 0,
true, true, false, false, false, false,
false, false, false, false, false);

//=================================================================================

const boolean debug = true;

//=================================================================================

//Joystick variables – Button (with debounce)
int SEL, prevSEL = HIGH;
long lastDebounceTime = 0;
long debounceDelay = 50; //millis

//=================================================================================

//Joystick pins

define VERT_PIN A9 // AKA the “Y” — dependent on how thumbstick is oriented

define HORZ_PIN A8 // AKA the “X” — dependent on how thumbstick is oriented

define BUTTON_PIN 7 // Pushbutton of the thumbstick

//Mapping to XBOX Adaptive Controller
//X and Y will auto map to Axis 0/1 or 2/3 depending on which side you plug
//the joystick into (left=0/1 or right=2/3). The pushbutton on the stick needs
//to be set & programmed depending on placement. TODO: Some sort of config on stick?
//10=Left Stick Press, 11=Right Stick Press

define XBOX_AC_STICK_BUTTON 10

//=================================================================================

int rawHorz, rawVert;
int mapHorz, mapVert;

//invert if needed
bool invHorz = false;
bool invVert = true;

//=================================================================================

void setup() {

//Startup the joystick object.
Joystick.begin(false); // false indicates that sendState method call required (so we do all changes at once).

//I’m using Map below, but setting range Just In Case.
//Also setting Axis to zero at startup.
Joystick.setXAxisRange(-127, 127); Joystick.setXAxis(0);
Joystick.setYAxisRange(-127, 127); Joystick.setYAxis(0);
Joystick.sendState();

//Set HORZ and VERT pins (from joystick) to input
pinMode(VERT_PIN, INPUT);
pinMode(HORZ_PIN, INPUT);
pinMode(BUTTON_PIN, INPUT_PULLUP);

if (debug) {
Serial.begin(9600);
Serial.println(“HandheldUSBJoystick_ForXBOXAC_V1”);
}

}//setup

//=================================================================================

void loop() {

// —————————————————-

// Check for button push – and debounce
int reading = digitalRead(BUTTON_PIN);
if (reading != prevSEL) {
lastDebounceTime = millis();// reset timer
}
if (millis() – lastDebounceTime > debounceDelay) {
if (reading != SEL) {
SEL = reading;
if (SEL == LOW) {Joystick.pressButton(XBOX_AC_STICK_BUTTON);}
else {Joystick.releaseButton(XBOX_AC_STICK_BUTTON);}
}
}
prevSEL = reading;

// —————————————————-

//Read analog values from input pins.
rawHorz = analogRead(HORZ_PIN);
rawVert = analogRead(VERT_PIN);

//Map values to a range the XAC likes
mapHorz = map(rawHorz, 0, 1023, -127, 127);
mapVert = map(rawVert, 0, 1023, -127, 127);

if (debug) {
Serial.print(“RAW H/V: “);
Serial.print(rawHorz);
Serial.print(” “);
Serial.print(rawVert);
Serial.print(” “);
Serial.print(“MAP H/V: “);
Serial.print(mapHorz);
Serial.print(” “);
Serial.print(mapVert);
Serial.println();
}

if (invHorz) {mapHorz = -mapHorz;}
if (invVert) {mapVert = -mapVert;}

Joystick.setXAxis(mapHorz);
Joystick.setYAxis(mapVert);

// —————————————————-

// Send updated joystick state to HID upstream
Joystick.sendState();

}//loop

//=================================================================================

frotz on the Pocket CHIP

Got frotz working on the Pocket CHIP. Now I can run Interactive Fiction games (ex. Infocom) on the move, while using a discontinued hardware device. 🙂 At least I finally put it to use.

Photo taken in 2016, when I originally got it, and it sat without a use.
Now, in 2019, I dust it off and install frotz.
Got Hitchhiker’s running!

Enabling SSH Server on Pocket CHIP

Before you do anything, check out the mirrored documentation found at chip.jfpossibilities.com The site has mirrored the sources, so you can actually run updates again. Thank you, JF!

# Pocket C.H.I.P. (Pocket CHIP)
# Installing SSH Server on Pocket CHIP
# Note: When using sudo (do as sysadmin) the password is “chip”

* Open Terminal

* Move to apt directory
> cd /etc/apt/

* Update sources.list
> sudo nano sources.list

* In sources.list, replace opensource.nextthing.co with chip.jfpossibilities.com
* CTRL-O to write out (save). CTRL-X to exit.

* Updates preferences
> sudo nano preferences

* In preferences, replace opensource.nextthing.co with chip.jfpossibilities.com
* CTRL-O to write out (save). CTRL-X to exit.

* Update with jfpossibilities as the repository (instead of the defunct nextthing)
> sudo apt-get update

* Install SSH Server
> sudo apt-get install openssh-server

* Start the SSH Server
> sudo service ssh start

* Get the IP address. You can look on your router, or:
> ip a
* Look for the wlan0 inet entry (looks for your subnet, etc 192.168.x.)

* On your PC, use WinSCP or similar to SSH into that IP.
* The user will be “chip” and the password is also “chip” (if you didn’t change default).
* You should now be able to easily transfer files between your PC and the Pocket CHIP.

# Why I Did This
# Not a whole lot of the use for the device, but it’s portable, has a screen and keyboard…so…
# How about Interactive Fiction / Text Adventures? The old Infocom games. Running the Z Machine.

# How to install FROTZ — the Z Machine

* Do all of the above to get SSH Server running (makes it easier to copy games from PC).

* Instal frotz
> sudo apt install frotz

* In /home/chip/ you can create a folder called games
> cd /home/chip
> mkdir games

* I then used WinSCP to copy to Z5 game files to that directory (/home/chip/games/)

* Now to run them. Navigate to the /games/ directory.
> cd games

* Run frotz
> frotz [gamename].z5

* For example: > frotz leather_goddesses_of_phobos.z5

# Do some web searches to find z5 files. I found this site helpful: https://if.illuminion.de/

AutoScope 2.0 : Coding The Scans

I got the X and Y limit switches working. Not perfect, but good enough to move forward. Spent yesterday coding “go home” “go center” and a preliminary “scan slide”.

Limit switches. Y is on bottom, X is on top. Bracket also holds Z (other side, not visible, not currently connected).

Slide Center is currently hard-coded based on “eye balling” one of my sample slides. I’ll have to come up with something more scientific. 🙂

The level of magnification determines the steps per photo — inverse ratio (lower the mag, higher the # of steps). It follows the mag values, but I’ve tweaked to give some additional overlap. The steppers and gearing are good enough for over 1000x (the optics, not so much).

I’ve also directly connected the camera to the microscope (not going through an eyepiece). These images are roughly 300x. 3D printed a little 32mm adapter tube.

As I play with it, I’m coming up with a list of stuff to do: add a Cancel/Abort/Panic button (hooked to an interrupt). Allow user to set scan ranges. Allow user to set center. Save default values?

Also thinking through a proper case for it.

I’ve used this sized enclosure for other projects. A good amount of room to work in.
Display, board, buttons, drivers — need to be stuffed into a box.

Of course, also working through how I’m going to trigger cameras.

AutoScope 2.0 : In Search Of Home

It’s so simple a problem that it’s a giant pain in the neck! To further automate the microscope, I need a way for the program to find a “home” position — a starting point. Something that won’t strip gears, crack slides, or otherwise cause mayhem.

Most X/Y/Z devices (3D printers, laser cutters, CNC routers, etc) use limit switches. The trouble is the way the microscope stage moves.

X – Moves just the slide left/right
Y – Moves the stage forward/back
Z – Moves the entire stage up/down

So, you either start attaching switches in weird places (on the stage, on the body) or come up with something else. Added fun? The top limit of Z should change depending on the objective lens. And, by the way, not the entire stage moves for Y — just the very top of it. But, Z does move everything. You start to see my problem.

How to cleanly find home, inexpensively, with as little modification to the microscope as possible?

I’ve looks at more sensors than I wish to admit:

Time of Flight (Laser) — Good for finding a single direction of movement, but I’d need three at $15 each. I tried some ideas of using just one for X and Y, but that didn’t pan out.

RGB Sensor Through Eyepiece — Find the “dark” / black and you determine the edges of the sample. Works fine, in a controlled (dark) environment, but reflected light (from the room light, bouncing off the top of the slide) messes with the readings.

Hall Effect Sensors — Like switches, but triggered by magnets. Most promising, but when Z is moved, their point of triggering changes. I pretty much need a constant/known distance between magnet and sensor.

Accelerometer / Magnetometer — AKA Gyroscope and Compass — Good for finding Yaw/Pitch/Roll, but since the microscope doesn’t Yaw/Pitch/Roll, not helpful for me. The stage movements are too small to accurately tell if its moving in a particular direction. Perhaps this is a solution, but I’ve not figured out how to tease out good data.

I was also thinking of a proximity sensor, like the one found on our Prusa 3D printer. Kinda like a Hall Effect without the magnets. But, the sensors aren’t cheap ($15-$30 each), pretty big, and I’d need three. And the whole range of motion problems and where to mount them.

This is the Y switch. You can see how part of the stage (toward top) moves, bottom part doesn’t.

So, for now, I’ve admitted defeat and gone back to micro switches. I’m hoping to get them working “good enough” so that I can write code. For now, the focus (ha-ha) is on X and Y. I’ll add Z later. (Z is less important, as the focus really needs a human eye, or smart AI.)

The X switch. Using a “finger” on the stage I printed. The program will find Y first, to move the stage closest to the user/switches. Then will look for X. Final program will lower to find Z, then Y, then X.