Advertisements

Nixie clocks

Some clocks I’ve made:

Lethal Nixie Clock

Lethal Nixie Clock

Clock 1 schematic

Clock 1 schematic

Clock 1: Single tube Lethal Nixie clock — you know having all the high voltage lines exposed and un-insulated. Inspiration for this design was from this clock. Unfortunately I built mine right after having surgery. I think the painkillers had something to do with the aesthetics… Anyhow I wasn’t electrocuted while building it under the meds…That’s always a plus!

Pinout and some key components

Clock 1 Pinout and key components

ATMEGA 328 arduino with a DS1307 RTC for timekeeping. Basically the arduino pulls time from the RTC then updates IO. During this it’s got a time based ISR that: interrupts the code, measures the high voltage, then makes necessary tweaks to the boost converter duty cycle via a proportional controller. Alright let’s get to me gabbing on about it in the video. I forgot to show how to set the time in the video, here’s a quick video on that. Arduino Code here.

Main circuit schematic of the 4 tube nixie

Clock 2 main schematic

Clock 2: Four tube nixie clock. Very similar to the previous clock but uses i2c GPIO port expanders for all the tube outputs, and a GPS instead of a DS1307. This clock just needs some final tube aligning and some buttons to change the time zone! Everything’s implemented on the board/code side. Code for it is here. Just a heads up this is a ‘guide’ to making one, not instructions.

Each individual nixie tube schematic

Clock 2 individual nixie tube schematic

The individual nixie tubes have the same repetitive circuit for each cathode, here’s what one cathode

4nixieTubeProtoLayout

Clock 2 protoboard header layout

looks like (you’ll need to make 10 replications for a tube that needs to display 0-9, for like the tens minutes you’ll only need 0-5 cathodes to work. The gpio expander boards all connect to the same I2c bus. There’s jumpers on the MCP that select the i2c address, these jumpers are different on each tube to allow the microcontroller to control each one individually.Anyway VIDEO PART2, PART3 here. I did a lot of explanation in the video’s, so I’ll keep this post brief.

pinout mapping of nixie tube

Clock 2 Pinout mapping of nixie tube

Finally Clock 3 (Not a nixie!):

This is when I look back and think “I really make too many clocks…”, I’ll keep this one brief. This is a clock based on a ~3 inch TFT with touchscreen with Teensy3.1. It generates fractals thanks to a julia2 fractal algorithm I found online. My code randomly tweaks some of the constants that determine shapes/colors in the julia2 algorithm to keep things fresh.

As you can see it graphs temperature, humidity, barometric pressure over a 2 day period. The vertical markers represent 6 hours. The graph auto

20151001_172931

Fractal Clock

zooms/offsets each sensor’s data to keep it looking nice with the mins/max displayed at top and bottom per graph. The 3d printed case insulates the insides, so the temperature is a bit high — i need to print one with more vents.  Time is set by the touch screen (video doesn’t show that). As you can see I actually made this clock quite some time ago. Source code here.

I did a game of life with this library too. I meant to make a clock where the game of life would randomly get organisms added that would eat away at the time. This code also demonstrates the graph algorithm that auto scales/auto offsets.

Clock 4:

Hey remember that original clock? I also made a kit I had up on ebay for a while. PCB was designed with CircuitMaker, PCB manufactured by OSHpark

20160520_185557

Ebay kit of the ‘lethal nixie tube clock’

Advertisements

Xbee hive

xbee

xbee galore!

Well summer is over! I ended up doing my internship at Caterpillar and had a delightful time! I especially loved the cafe there! The D11, D7E, and 735 articulated truck were cool too.

I really hope to post some more how-to guides probably related to RF modules… I’ve been working with some ultra low cost RF modules from sparkfun and just starting to do some work with XBees after an awesome donation! I have around 60 pro/standard series 1/prototype (mostly standard) xbee modules!

wireless wii nunchuck mouse

I just haven’t had the time to write about many of my other projects. Here’s a wireless wii nunchuck mouse, and it uses a 5v limited joule theif for the power supply. This is great since it runs down to 1v. The receiver acts as a HID device with basic error detection and those low end modules are only a one way link, so it would just throw out the reading if any error was calculated.

As far as my next guide topics i’m certainly open to suggestions. Possibly a part 2 mosfet guide that goes into more detail about calculating current, power dissipation, resistive feedback, and triode regions. Maybe a BJT intro guide or something else…

Self balancing robot

Ugly! Accelerometer in wii nunchuck, Gyro in Wii motion plus (right side)

In the near future I really want to build a quadrocopter, and would possibly need to do this for two of the interns I’ve been pursuing (NASA JPL or OSF). I was trying to figure out a good place to start and actually get some tests in. After doing some thinking I assume that a quad’s control system is similar to a self balancing robot only in two axis. On a quad I would read the pulses coming from a tx/rx system to adjust the target balancing angle. So far I’ve only put in two days into this robot, yes I am aware that I may not be approaching this the best way! please leave advice! So far it’s been 1 day to get the wii motion plus working with the wii nunchuck (they have the same I2C address…), and 1 day writing the software and building the robot. Everything is very rough so far, so I’m going to wait to post the source code! If you want a copy please leave a comment and I’ll send you the three versions! Once I get more familiar, I’ll surely write a very detailed guide!

Control system:

My current control system. Edit: I calculate angle from the accelerometer right after the offset and scaling.

I’m using a complementary filter, which is used to combine a gyro (accurate but drifts over time) and an accelerometer (not so accurate but doesn’t drift). Anyway look at the control picture to see exactly how I’m doing the calculations. Everything underlined in blue I want to get rid of/move. Possibly I will want to keep the MA so that I can do a standard deviation. The standard deviation could help the platform tune the complementary filter. A high standard deviation for the accelerometer would tune the complimentary filter constants to .999(gyro)/.001(accel) where as a low standard deviation may set it to .95(gyro)/.05(accel) and make it a continuous tuning function.  I’ve also been brainstorming on methods that would allow robot calculate the balancing angle for the platform. As far as phase shift: I’m not too worried about the accelerometer’s phase shift due to the filters, but the gyro needs the phase shift to be an absolute minimum!

Talking to two I2C devices with the same address. Had to include my new tool - saleae logic analyzer

How I would improve results:

The wii motion plus is a ~20$ three axis 2000deg/sec gyro with a plastic case, sockets, PCB, and a I2C pass through chip. This really isn’t the right type of gyro for this type of robot, and I seriously question the quality of the gyros on board. I can say the same for the accelerometer on the wii nunchuck too. I’ve also thought of a few ways to calibrate the system and get the gyro/accel units to match up with each other. Regardless the results are pretty good and I may just need to tune everything. Those servos are also slow as beans! My plans are to replace the gyros with less than 500deg/sec gyros, clean up the algorithm and work on perfecting it! I also need to put the IMU on the pivoting point of the platform.

Code:

segway05 – I probably won’t get around to taking another wack at this till summer, so here’s the most recent code. Not many comments other than the blatant mistakes pointed out.

Great resources:

Complementary filter by MIT

Tilt with accelerometer

Calculating angles with accelerometer

Using wii nunchuck and Accelerometer together – Just an FYI if you disable the Wii motion plus to talk to the nunchuck via passthrough port, the wii motion plus takes about 100ms to turn back on which is SLOW. I don’t  have a wiimote/wii, so I can’t listen in on them talking with my logic analyzer. This method is good since both devices have the same I2C address…

Videos:

Sorry about the terribad quality videos!


Standard Deviation and Moving Average

Recently my neighbor paid me to build a key less entry system for his dorm room. I decided to go the economical route and use a button/potentiometer that sits outside the door and an Arduino on the inside that controls a servo connected to the lock. For my room, I thought it would be interesting to use a Ping))) ultrasonic distance sensor instead of the potentiometer and lose the button.

The Ping))) sensor kept taking readings while my hand was moving. In order to fix this I decided use a Moving Average filter, then calculate the Standard Deviation of the values currently included in the M.A. filter. When my hand is still, the Standard Deviation will become very small.

Example code:

M.A._and_S.D.(pdf)- “storeValue(variable);” is how to enter data into the array, then call M.A. and S.D.

Not much of a circuit required! Arduino's regulator also powers Ping))). Servo has it's own 5v regulator... needs capacitors

pingDoorLocker(pdf) – As you can see, this program blew up a little…

Download .pde source code from RapidShare

I tried to make the M.A. and S.D. code very easy to follow. Some things could have been combined in the S.D. and Variance method, but to the beginner what I wrote above is probably easier to understand since it follows the equations. As for the pingDoorLocker – I threw that code together very quickly.

Follow up notes: That was probably the worst way to do this project… I thought of a few ways how to write the program that would chop the code WAY down, but this is an example about using M.A. and S.D.! Pretty bad use of a M.A. filter if you ask me!

His door unlocker.

Since I did put a few hours into building my neighbor’s door opener, here’s an image of it! He didn’t want numbers on the potentiometer dial, so I made the LED flash the number that is currently being entered.

Code for his door opener (pdf) – leave a comment if you want schematics/code on rapid share since pdf loses tabs.

Wicked Laser

My initial response.

Green laser with shades to block green light.

Just received my, “Flashlight Sample” from Hong Kong. I guess it’s better than calling it a high power laser and losing it at customs. I’m certainly satisfied with seeing a clearly visible beam in just about any light condition! No smoke required! Using it to cut electrical tape like butter, and popping balloons never gets dull! Shining this thing on the ceiling literally lights up the whole room! The only downside is that there are warnings NOT to look at the dot without eye protection… how can I resist!?

Green laser DPSS.

The legality of high power handheld laser pointers is somewhat murky and will likely change in the near future. It may be a federal crime to shine a powerful laser at the sky (who could resist doing this) since it may hit an aircraft.

How they work:

This is a Diode Pumped Solid State laser (DPSS). The actual diode inside is an infrared laser, and the light gets changed to a green color by a rather interesting, yet inefficient process. Anyway I don’t want this post to be too long, so head here if you want to learn more! I’ve read that cheap DPSS lasers don’t have the IR filter in order to have a higher power output. This must dramatically increase danger since shades probably don’t block IR too!

similar laser

Picture of a similar laser.

Future use:

I plan on putting this bad boy on a robot that will drive around popping balloons, and target tank cut outs made out of black flash paper. Another possible use is to buy a simple line camera and make a laser distance sensor.

Where to buy:

Sellers include Laser Glow, Dragon Lasers, and Wicked Lasers. I would be curious to see how well some of the laser modules from deal extreme work. Maybe I’ll get this guy!

Update:

After a year and some change the laser diode failed. Disappointing since I never went through a set of batteries! That’s a pretty good indication that the laser diode was being driven far beyond its ratings. Be warned when buying from Wicked Lasers!

ASEE 2011 Competition

Original CAD.

The goal of this project is to have a robot start on the east wall, navigate the track, collect all red doll rods, and finish touching the original east wall. The key robot rules are: robot must be fully autonomous, total budget is under 450$, the robot must fit inside an 8 x 12 x 10 inch box, and it must complete the task within two minutes. We designed the robot to be similar to an assembly line, so the robot never stops moving. Our robot ended up using a PI controller based on the Arduino PID library.

Front view, doors closed.

The batteries were only changed twice which shows how the project focused on building small modules, and shows how smoothly the final design came together. We ended up not competing due to funding issues with the school, which is why nothing was fully completed or perfected.

Member roles:

  • Moser EE- electronics, programming, control theory
  • Imig EE – electronics, control theory
  • Doxsie ME- CAD design, organization, mechatronics
  • Dulce BioE- general management, organization, paperwork

Design Stages:

The total time for this project was about seven months!

Front view, doors open.

  • Rather than rushing into any decisions, we decided to brainstorm for about two months. This brainstorming allowed team members who weren’t interested to drop out and allowed everyone else ample time to research, think of designs, test sensors, and test algorithms.
  • Next stage was to build a robot that could follow a wall, we had two robots at this time — Arduino and a Propeller based robot. Many complications arose with the propeller robot, so we ended up going with Arduino since it’s simple to use. This stage took about two months.
  • Once the team’s robot could follow a wall, it was time to navigate the course perfectly every time. This stage took about a month. A video oh another!

    Rear, doors closed.

  • The final stage was giving the robot it’s second chassis, and test one door. We then added the color detection modules. This stage took about a month, giving us plenty of time for perfection.

Programming style:

I ended up doing the majority of the programming and I’ll give a bird’s eye view on the concepts of the program.

  • Break the overall program into three stages.
  • Keep everything very modular and break up core robot functions into methods which are reused in all applicable stages.
  • Write the program in a style which contains no time based delays. If a large time based delay is needed, then store the current up time and don’t take action until the stored up time and the current up time differ by whatever the delay needs. There are some exceptions to this, but they’re under ten milliseconds.

The Arduino may do a few hundred loops a second where the actual processor just runs calculations and makes adjustments to registers, it’s not generating signals for the servos. There are large delays when the robot is turning at the corners, or at a time where it doesn’t need to be accurately following a wall and color detecting. We were originally using a compass, but a simple estimated turn is better and saves 30$.

Final ASEE robot source code (pdf) – Since we didn’t go to Canada, the code isn’t pretty.

All connections and currents.

Electronics used:

Picture of wiring. What a mess!

We did use a standard Arduino with an Atmega328. This proved to have enough pins for everything. Our Arduino was the DC BoArduino from Adafruit!

The wheels used continuous rotation servos. Doors were cheap analog servos, color sensors are the same ones that I wrote about earlier…etc. A full list of the final parts is in the pdf below.

Final robot parts (pdf)

Mechatronics:

The doll rods are much easier to work with if they’re knocked over since they can roll. I’ll admit that we used some design ideas from the other team. They didn’t knock over the doll rods and had major difficulties with actually getting the rods into their storage compartment. Their robot was based on dead reckoning, which meant there was no feedback when it came to navigating the track. Although dead reckoning is an easy path to take, it’s not ideal when tolerance is less than an inch. The video below is an older one back before we completed the color sensors. The servo in the next video is a digital all metal gear servo and it’s MUCH nicer than our final servos.

front view from robot showing pid response:

inside the cargo bay (collecting both colors):

Original robot with compass and Sharp IR distance sensor

Why are we not competing?: The tech department is funding the project, and our team is composed of engineering majors. Since we’re not from their department, they weren’t able to drop a few thousand to send us to Canada. It was frustrating since this was not explained until a few weeks before the competition!

Why didn’t we use all the doll rods?: Yes… as you can see we weren’t using all 12 doll rods. This was because the other team that dropped out still had most of the doll rods, and we didn’t have enough extras to fill up the course. We didn’t get around to making more.

One more video!