Archive Page 2

Pneumatic Controller: Part 3

That’s right, Part 3! Take that, Hand Typing project!

You will not believe how simple the solution to my interrupt woes turned out to be. I tried the code again with the Timer1 Arduino library and was able to use timer interrupts and the LCD, but still couldn’t change the LCD from inside the interrupt. While looking online, I found someone saying how interrupts were disabled inside other interrupts, but you could re-enable them.

Now until this point, I had thought that interrupts were disabled just as a function of how they work, but it seems that they are only disabled with the assumption that if you wanted to stop whatever you’re doing to do the interrupt, you probably don’t want to be interrupted while in it. But in my case, I did so that I could print to the LCD.

interrupts();

That’s it. That is literally all I added to the timer interrupt function to make it work perfectly. It is frustratingly simple. Anyway, it worked.

Luckily (?), it still had some problems. The timer interrupt had some confusion with the scrolling and would sometimes, but somehow not always, print random characters all over and stop the flow of the program. Naturally this was not something I wanted.

I thought of two solutions. The first was to change from an automatic scroll to one that scrolled when a button was pressed, using an external interrupt. This was significantly worse for some reason.

The second way was to get rid of the interrupts entirely.

“But Ari,” you exclaim. “You spent so much time getting them to work. They were so special to you!”

That’s true, imaginary commenter. But an important lesson i learned about writing papers is to kill your darlings. As much as I liked having timer interrupts in the code, ultimately they made it more complicated and worse than it needed to be.

So what would I use instead of interrupts? Well, the normal way would have been to just check for scrolling every loop through this part of the code, but I hadn’t originally because parts of the code stopped and waited for input, which would leave a break with no scrolling. What I realized is that only one function actually used the scroll function anyway so all I needed to do was reorganize it to use a loop instead of waiting (for those who have used the Arduino LCD, it was a switch from waitForKey() to getKey()).

This worked and the program now scrolls lovelily (it’s a word, look it up). It even makes the program a bit faster because there’s no extra memory taken up by interrupts and libraries. Hooray!

Besides a couple of smaller changes, the main thing I did last week was to make a temporary assembly for the keypad/LCD. Until now I had been leaning the keypad as best I could but this got a little annoying. I couldn’t put the full assembly together because I haven’t decided how things will be stacked (probably: Arduino – Generic shield to make disconnecting the Arduino a one step process – All wires besides the LCD – LCD), so I taped them together as best I could.DSCN2071

DSCN2072DSCN2073

The nice thing is that the keypad was built with a window for the LCD, so everything looks all neat and shiny. The text displayed is from the beginning of the setup and is asking how many pistons to use.

Things continue to go well with no obvious problems foreseeable. I hope to finish the debugging of the setup program this week and then start assembling/testing the actual pistons.

Until next time!

Ari

Pneumatic Controller: Part 2

First things first: I added the picture of the sensor setup to the first part post. Done.

Next, solenoids. Monday I was able to start working with the actual transistors and found that, lo and behold, they had the same problem! That was somewhat disconcerting, especially after I tried them with multiple combinations and checked and rechecked all the connections. Finally I tried it with one the lights from the original system (they took the same power as the solenoids) and had no problem.

At this point I began to think that although normal solenoids, which just open or close a single valve, don’t care about the direction of current (I think), maybe these ones did. These solenoids controlled two valves each and would normally have one open and one closed, and when power was applied, would switch them. This is really helpful in terms of programming the controller because it means that each piston only needs one command to change direction (either open or closed, instead of open-closed and closed-open), but I figured it might effect the current. Naturally, the easy, 5 second switch of wires fixed everything and the solenoids worked perfectly and, most importantly, I felt dumb. But I learned.

The diagrams I’ve been working from for the transistors is below.

Briefly leaving the Ari Made Himself Feel Dumb portion of the blog (don’t worry, we’ll be back shortly), I later figured out how to make Arduino functions with a variable number of parameters, not just a set number (it could be f(1) or f(1, 2)…). This was important because Arduino’s printf function did not in fact work like MATLAB’s sprintf function as I had thought, so I had to build my own.

To non-programmers, if I wanted to print a bunch of statements in the form of “It is cycle number X” and replace X with the cycle number, the easiest way is with this type of function. With it, I can put in placeholders and just tell the function what to replace it with each time. However, Arduino’s printf function didn’t work this way.

Naturally, once I was done I discovered that Arduino in fact did have something along those lines, namely the sprintf function. Although it works somewhat differently, it was good enough that I could use it. But since this mishap did lead me to learn something new about making functions, I’m considering it as a win.


Now we have a more interesting problem! The LCD I’m using has 2 lines that each can hold 16 characters. This meant that all the instructions and information I wrote for it had to fit in those spaces or else it would be cut off. However, there were some I couldn’t fit without making them too confusing, so I wrote a scrolling function that would shift them over every second or so (Arduino has such a function but it only works for both lines at once). The problem was with making it scroll even when the program was waiting on a step, such as the user inputting a number.

I had thought I solved this with the use of interrupts. Interrupts are basically magic functions that are separate from the rest of the program. While the rest of the program follows a specific order, whenever an interrupt is activated, it will stop the rest of the program and do its thing, only then going back to the main program. Usually, the program has to be specifically looking for a reason to do something, like checking for timing or an input, but interrupts are always checking (except when in a different interrupt). Most interrupts are external, meaning the Arduino gets a signal from outside itself, but in my case I wanted a timing based one, so it would scroll every half second or so.

However, when I tried it I found that nothing happened. I could make the interrupts work, and I could make the LCD work, but with both running everything would freeze. I had seen others use interrupts with LCDs so I couldn’t find the problem. At first I thought that only the timing based interrupts had this problem, so I considered using a timing based interrupt to turn on a pin that was connected to the input of an external interrupt. That way, a timer would activate an external interrupt which would then print to the LCD. Incidentally, that does work although the LCD still didn’t. Still, neat.

I also tried disabling interrupts while inside the interrupt (which you can do, apparently), then re-enabling them afterwards, but this didn’t work either.

Eventually it became clear that the problem was that the LCD shield I was using, used interrupts itself. This meant that the LCD couldn’t print anything because an interrupt was already running. I haven’t found a solution yet but I’m currently looking at a couple of options:

  • I found other people had this same problem and this person seems to have solved it. By connecting two pins on the shield and adding some code, they were able to use interrupts with the shield. This hasn’t not worked for me, though it’s unclear why.
  • It seems that only the buttons on the shield use interrupts and not the actual LCD. Since I don’t need the buttons anyway, I might be able to disable all the interrupts in the code and use my program normally.
  • Since the shield’s code is checking for interrupts anyway, I might be able to steal that interrupt pin and use it for my own purposes, then change the code to update the LCD instead of doing various button-related things. This might involve connecting a wire to the chip on the shield, but since it will be covered anyway it shouldn’t be an issue of loose wires.

All in all, I’m feeling good about the project and look forward to working on it this week.

Until next time!

Pneumatic Controller: Part 1

I’m back! I’ve actually been working on stuff, I promise. While some progress has been made on the finger typing project, I’m going to save that for another post and do this one about the pneumatic controller.

For those unfamiliar, the pneumatic controller project is something that I’ve been working on for a while. Briefly: I programmed a pneumatic cycle tester while working at UL, but due to the age of the system, decided that redesigning the electronics around a microcontroller would be a good idea. Until recently, I’ve only been able to work on the theoretical: designing the electronic layout, writing the code, making a BOM (bill of materials), and, more recently, making a user interface in Python to make using the system easier.

Well I’m now very happy to say that we are officially moving forward with the project.

This is by far the largest electronic/coding project I’ve worked on by myself. It involves several aspects I’ve never worked with before, such as LCDs, keypads, solenoids, and much longer code. While I think (and hope) that the project will be a success to the extent that I planned, I think that it will at least be better than it is now.

Here’s what’s happened so far:

Day 1 I bought the Arduino so I would be able to start right away and ordered the bulk of the components online. Other than the general program, which would be best to test in sections once the system is built, there were several things I wanted to test individually because they were new for me.

First up was the LCD. Turns out the LCD and keypad from the original Festo system could be detached from the extra electronics and used with the Arduino. This news was somewhat dampened by my breaking the LCD almost immediately. While the LCD was similar to what I would have purchased, the wiring was positioned differently and through an unclear combination of me getting confused by different schematics and the LCD being designed differently than most, it stopped working. It’s possible it never worked. Who knows?

But, up from the ashes grow the roses of success. In this case, success came through me finding out that Adafruit makes a deliciously simple LCD shield for Arduino and the keypad working after a very anticlimactic 10 minutes work. I’ve never used a shield before, but it looked fairly idiot-proof. I put the shield together on Wednesday with only a brief panic at how hot the IC got when I soldered it in, and it worked perfectly. A little more expensive than planned, but about the same as if I had bought both the plain LCD and keypad to begin with. Incidentally, shields fitting perfectly flush to the board and then working correctly is just the best feeling.

So beautiful

So beautiful

Next up were the sensors. I had been hoping I would be able to wire them directly to the Arduino, similar to how you would wire a button, but it turns out the sensors have 3 leads: power, ground, and signal. I tried a couple of methods before speaking to someone at Sparkfun (who have an amazing chat service, by the way) for advice. Eventually, I settled on using a transistor with a separate 24V power source for the sensors, as shown below. This worked great. I had never seen someone use transistors for a high power input before, so it was a neat thing to learn.

Finally, the solenoids. This should have been pretty straightforward (ha!) as it’s just a simple transistor circuit with an added diode, but naturally it was not. After determining that the solenoids needed at least 20V to run (although they could be held with 10V) I tried the circuit and found that while I could activate the solenoid, it would stay put even after the transistor wasn’t powered. I tried various combinations but found that nothing changed and the solenoid would only switch back when the main power was cut. I think this is probably because I was using a different transistor but I won’t know until I can try the real one on Monday. Still, progress.

That’s it for now. I’ve also been making changes and fixes to the code and diagrams. Next time I’ll be able to show you some of the other diagrams and, hopefully, actual pictures! I’m also hoping to update this fairly regularly, since I’ll be working on it at least somewhat every day. Here’s a picture of the new, more exciting, circuit diagram.

So exciting

So exciting

No promises for the finger typing, except that it will one day be done and published.

Goodbye for now!

Hand-Finger Typing: Part 2

Part 0/1

Part 2: Building Hardware

Today I finished the hardware part. Hooray! It ended up being a bit more complicated than expected (shocker) but it wasn’t anything an hour wandering in an art supply store couldn’t fix.

What I now have are two cotton gloves with conductive wire sewn into the finger tips, then threaded through the glove to the base, where they’re tied off. Conductive paint covers both ends to keep things neat and conductive. This worked a lot better than my initial ideas using tape, foam, and/or rubber.

P1020423 P1020424

P1020425

The wires are taped down so I don’t accidentally pull them while using the gloves.

The wiring is pretty basic, as all the system really is is 6 buttons. Below is a diagram anyway, made using Fritzing, which incidentally is wonderful.

Hand-Finger Typing - v1_bb

In reality, the red wire would go to the thumbs and the colored wire would go to the fingers. The buttons are used here as placeholders.

For those of you unfamiliar with using microcontrollers for input, the reason the pins I’m using also go to ground is to avoid “floating” pins. When a pin is not connected to anything (like when it’s connected to an open switch), it is considered floating and will randomly fluctuate between on and off. Having it connected to ground through a resistor prevents this.

I wrote a basic program that would just tell me if fingers made contact and everything seems to be working fine. Hopefully this trend continues.

My thoughts thus far are that the gloves are nice for now, but I definitely would want something better for the future, especially since they don’t breathe and summer is coming. They also have little grip to begin with and the paint only makes that worse.

Future plans are:

  1. Replace the gloves with either better gloves or some kind of finger strap
  2. Replace the tips with conductive rubber with better grip
  3. Add a Bluetooth module so I won’t be tethered to the computer (which may be pretty easy thanks to Adafruit’s Bluefruit products
  4. Add a flat joystick to one hand and button to the other to act as a mouse
  5. Allow the Arduino to type anywhere and not just in the Arduino program (this is more of a programming task)
  6. Perhaps a small vibrating motor that will buzz when a letter has been finished. Otherwise I could lose track and start typing gibberish (e.g. instead of 1-2, 6-3, 2-2 I could have 2-6, 3-2, 2-something, which are a completely different set of letters)

Things are going well and I hope to have Part 3 done soon.

Geronimo!

Hand-Finger Typing: Part 0/1

Part 0: Introduction

Apologies for the name; I haven’t come up with anything better. This is the next project I will be working on and, as a special change of pace, I will actually (hopefully) be updating on my progress.

The project is based on a concept I’ve had for several years now. The idea is that there are conductive pads on the tips of the user’s fingertips. Touching these to the thumbs in different combinations would make different letters. For instance, touching the dominant hand’s middle finger to the thumb, then the non-dominant hand’s middle finger (the easiest combination) would give an “e” (the most common letter).

This system would allow typing without the need for a keyboard and would allow the use of hands more, since the hands wouldn’t need to be together in order to type and could switch between typing and not typing quickly. While this wouldn’t be in the prototype, using conductive rubber (which, incidentally, is a thing) would allow gloves with this capability to still have a good grip.

The main benefit, however, is that human brains instinctively know where all the parts of the body are without looking (proprioception), which means that this method of typing would be more instinctual than using a keyboard, which is not part of your body. Incidentally, proprioception is pretty cool in general and I recommend reading about it. It’s why you can touch your nose with your eyes closed.

Obviously learning this new method of typing is a task in itself which is why I don’t really intend for this to be marketed or to replace anything. While it might, might be more efficient than normal typing, normal typing is already in mass use. This project is mainly for fun.

The project will have 4 parts:

Part 1: Deciding which finger combination will correspond to which letters. Finding the most common letters is easy thanks to Wikipedia, but I will still need to decide what the easiest finger combinations are. This is obviously subjective but it shouldn’t vary too much between people. I’ve actually already finished this, as seen below.

Part 2: Building the hardware. Since this is a prototype, this is actually pretty simple. All it really consists of is something conductive on fingertips. I’m planning on using thin gloves, aluminum foil, and wire. The brains will be an Arduino.

Part 3: Software: Surprisingly, this also shouldn’t be too difficult. The pseudocode that I’ve worked out so far is fairly basic and shouldn’t take too long. The coding experience I got through the pneumatic controller project should be very helpful.

Part 4: Learning to type anew. This is the part I’m really worried about. I haven’t had to learn to type on a new “keyboard” since I first learned how years ago. I’m expecting lots of finger cramps and swearing. Thankfully I have fun programming and building to do before I have to deal with that.


Part 1: Picking letters

This part was finished today. I took the most common letters from Wikipedia and put it into Excel. Then I thought of a few guidelines to follow (like how the easiest fingers are middle, index, then ring). I found that pinkies (which are super awkward to use) could be ignored entirely because with just middle, index, and ring you get 36 options*. Then I basically sat down and stared into space flicking my fingers about like a crazy person. What I came up with is Letter combinations (mini). It is what I believe to be the most efficient method.

More importantly, it’s color-coded, which looks very pretty. If you’ve never used conditional formatting in Excel, you should.

These files reference dominant and non-dominant hand (unless I forget) because the product will allow the user to switch between righty and lefty. I’m a righty, so I will be using dominant-right and non-dominant-left.

*This is confusing only if you over think it. After any first finger, you then have 6 choices of where to go (middle, index, and ring on two different hands). You have 6 options to begin with, so 6 x 6 = 36.


That’s all for now. I will hopefully have something interesting to tell you soon. I’m making this post/project more public in the hopes that it will pressure me to keep more of a schedule.

Allons-y!

Pneumatic Controller Project

Arduino Circuit Diagram - Mega_bb

While working for UL, I was tasked with programming a Festo pneumatic controller used for cycle testing. This system had all the physical components set up and wired, but had not been programmed. Using online resources, I learned the basics of PLC programming and from there learned the Festo software. I was able to finish the program so that the system could cycle a piston for a chosen number of times, with options for how to use the sensors.festo piston

However, the system was not able to be up to its full potential. Because of how old the components were, the software for the controller and the LCD screen and buttons wasn’t made anymore. The current version of the controller software was compatible with the older controller, so the basics could still be performed, but the LCD was completely unusable. This meant that to use the system, you had to go through a computer and changing parameters was much more complicated. I decided to design an improved system that would open up the full capabilities of the device. As of now, the designs have not been implemented as it is not clear whether the added benefit is worth the additional cost/time.

The first decision I made was to switch from a Festo based system to an Arduino one. Festo is not used by as many people and so there is not nearly as much documentation and support, both official and by users, as Arduino. It’s also a much more difficult and cumbersome system to use, partially because I am more used to line-by-line coding such as Arduino. It would be easier to program and easier to modify or repair in the future if needed. Even with replacing all the electronics of the system with Arduino parts (which would mean taking out the controller, LCD, and buttons and putting in a microcontroller, new LCD, keypad, and various electronics to allow the microcontroller to work with the high current solenoids), the cost would still be less than a third of the cost of getting a new Festo LCD, which may still not work with the older controller.

After, I started designing the new system, trying to get as much detail as possible to minimize the risk if I switched systems. As much as I wanted and Arduino based system, I didn’t want to be left with nothing. Below is the circuit diagram I came up with.

Arduino Circuit Diagram - Mega_bbCreated using Fritzing

I also wrote code for the new system, which allowed the user to perform all tasks, from setting up pistons to following their progress, from the LCD and keypad, with no need for the computer. It also enabled the use of all 6 pistons and sensors, something that would have been much more convoluted in a PLC program. The best part was that due to the program’s nature, and the ability to comment, it could be expanded later on to encompass more pistons/sensors with minimal effort.

The pseudocode and actual code (in doc form) are below.

Pseudocode (Mega)

Code for Arduino version of pneumatic controller

As of now, I have not had a chance to try the new program so all I can say is that it compiles, which is a start. If I get the opportunity to move forward with this project, I will update the site with the progress.

More renderings (June 8)

The Jump Start Charger has been added to the Renderings page. 

This one lets you charge up just enough to jump-start a car.