Posts Tagged ‘Arduino’
These are a few of the bits that I cut from the main video because it was too long, including running it at full speed and a comparison with a super-simple system! There’s a strobe light in this video, too.
You might want to watch part 1 if you haven’t already, so that this makes more sense.
I threw this together from an old toy’s motor, old printer’s iR sensor, pizza box and some other things, to try out the PID controller algorithm after discovering it on Wikipedia and seeing that there was pseudocode, meaning that I didn’t have to get a PhD in mathematics to be able to read the crazy-looking formulas that Wikipedia seems to be so fond of. There’s a strobe light in this video.
I had planned to screen-capture my program while recording but completely forgot to at the time, so please try to survive my camcorder pointing at my laptop screen…
Here, the PID controller is trying to keep the motor at a precise speed (and get it there as quickly as possible). It doesn’t work well half the time because the L298 (H-bridge), responsible for switching power to the motor, doesn’t seem to like making the motor brake. That means it speeds up much more quickly than it slows down, which the algorithm doesn’t like (it’s designed for linear systems) – it basically ends up trying too hard to slow down, resulting in a big undershoot. I might be able to somewhat compensate for that in code.
I might try this with a Sabertooth motor speed controller (as used in my old singing motors project) in place of the L298, which can certainly force a motor to stop spinning, but the Sabertooth gives such a boost to the motor to get it up to speed that 90% of the PID’s job becomes redundant… Oh well, at least it’d be able to hit any given note without me having to calibrate it first like I did with the singing motors. By the way, that’s why this system measures speed in Hz – I originally intended for it to play music like a new kind of “singing motor”.
Originally, I planned to use a 3-pin computer fan instead of this motor, using the tachometer pin to measure the speed, but that required me to have a common ground for the motor and the tachometer, and I didn’t have the right components available (I only had N-channel MOSFETs, but I needed a P-channel MOSFET). So I ended up throwing my own motor assembly together and using an N-channel MOSFET only (could only turn power on/off, not brake), which the PID system didn’t like. I thought the L298 would fix that problem, since it’d allow the PID system to reverse power to the motor and brake it, but it turns out it’s too weak to have much of an effect after all… =/
Part 2/2 will show it running at full speed (with a more powerful PSU), show a much more naïve speed controller algorithm for the lulz, and just clear up a couple of details.
I’ve given her another 2 ultraound sensors on either side, so that she can see how well lined-up she is to walls on either side of her. This is to try to keep her heading directly towards a wall, so that the head ultrasound sensor will get the best reflections possible (assuming that her environment uses lots of right-angles).
The Arduino fires all 3 ultrasound sensors and listens for their echoes at the same time in order to “see” at the highest frame rate possible (typically 20-50 FPS), but this causes issues with echoes from one sensor bouncing around and returning to a different sensor. Although the code avoids any clearly-bad echoes like this (e.g. 2 echoes on the same sensor), it’s far from perfect, and she often thinks that she’s crashed into something (an object is very close to the head) when she hasn’t. I think there’s also a strange bug in the function that times the echo delays, or something strange is going on with hardware interrupts, because the function sometimes returns 0 for a sensor which clearly has an object in range, and at the same time, the sound of the tone playing on the speaker (using the built-in tone() function) becomes distorted so that it doesn’t even sound like a square wave anymore. I’ve never experienced that before, and I have no idea what’s wrong there. Oh well, she looks cool aligning herself half of the time.
Fun game to play: See how many inconsistencies there are in this video. It’s a combination of videos recorded 7 months apart.
It actually works! Well, its first ever print-out could certainly do with some improvements, but to be honest, I’m happy it’s even intelligible at all! Part 7 in my super-basic, Arduino-controlled printer project.
It should be better when I at least have a stable and level tray for the paper (or whatever) to sit on. I have an idea for an alternative to a heavy sheet of steel, which you should be able to see in the next video. Perhaps the PSU fan will have arrived by then, too… <_<
Also, enjoy the in-sync 50 FPS if you can! That pen flicks back and forth at stupid speeds, so a high frame rate is actually useful here.
Time for some real progress this time! The sixth part in this series where I make a super-basic printer with an Arduino.
It’s pretty much ready to print – just a little hot glue and a sheet of paper and it’s all set! But unfortunately, this video is already ~8 minutes long, so that’ll have to wait.
After trying out solenoids and ruling out floppy drive motors because of speed, I looked at servos as a way of moving the pen up and down. I settled on Hitec’s second-fastest micro servo, which is digital (means it’s not limited to 50 Hz update intervals) and has metal gears (means it won’t destroy itself quickly). It’s designed for use in R/C helicopters, so I’m hoping this will handle the fast motions over a small range of travel, with a light load, well. I’m certainly impressed by it so far.
The most boring video in this series of me making a super-basic, Arduino-controlled printer. I made it at 50 FPS to try to make it more interesting to people who can play that, but that ended up making it out-of-sync at times. *Sigh*
This is what happens when I don’t plan everything through before I start making something (i.e. all the time). Sorry. Stuff will actually happen in the next one, I promise!
Part four in this series of “making of” videos where I make a super-basic printer controlled by an Arduino.
There’s still no pen, so I stuck an LED where the pen will go and made it turn on when the pen should be drawing, as a test. Then, I took a long-exposure photo while it “printed” with the LED, pointing the camera upwards slightly after it finished each row. What I ended up with was a photo of the image that it tried to print, with inverted colours and stretched a bit because I didn’t move the camera at the right speed.
It can also now print bidirectionally, and it’s much faster to receive the data for the next row of pixels, because they’re no longer sent one at a time.
Part three in this series of “making of” videos where I make a super-basic printer controlled by an Arduino.
Although it still doesn’t look like a printer, I’ve been working on the software. Here, you can see the first stages of having the printer be controlled by the computer. The image data is actually being sent, but very slowly (think of it as a “compatibility mode”) – I wanted to make sure I had two-way communication working perfectly before making things faster. As such, there are still debugging messages being displayed on the Arduino’s LCD, too, left over from me trying to get things to work.
The next stage will be to prove that the Arduino is really receiving the image data correctly, even though there’s no mechanism to move a pen yet!
P.S. This video editor is bloody awful.
Part two in this series of “making of” videos where I make a super-basic printer controlled by an Arduino.
Sorry for being really lazy about uploading this. Also, the upload itself finished a little quicker than I thought it would, so yay, the date at the end is in the future.
The printer is a new, colour Epson LQ-300+II this time. Sorry in advance – I was tired after spending the whole night coding. Here’s the program I made to send Epson’s ESC/P 2 commands to a compatible printer and do fancy stuff such as change effects, colour, size, and even send non-ASCII characters as graphics in the middle of ASCII text. It’s still a long way from a usable text editor, though.
The program can also monitor plain-text log files and print new lines of text as they are saved. Here, it prints off live chat logs from 4 IRC channels. I optimised it a little for IRC logs, so that it can print different parts in different colours. I considered making it monitor my web server’s log file, but visiting certain pages on my site can add dozens of lines at once to the log file, which would waste a whole sheet of paper in seconds.
My program uses a USB interface, which I made with an Arduino, to communicate with the printer. The Arduino passes printer status info to the laptop, such as “error” or “paper out”, and forwards data from the laptop to the printer’s parallel port if the printer is ready.
I’m using a different, brand-new printer this time because it turns out that the other, second-hand printer had a bad head with 2 or 3 dead pins, causing blank lines in the print-out. I actually recorded several videos on the progress of cleaning the printer and its head, and was able to fix one of the pins, but 1 or 2 never came back to life, so it’d make a bit of an anticlimactic video that I might not upload. By the way, I recorded the pins firing in slow-motion, and one was very slow while the other didn’t move at all. I uploaded the video here.
PREVIOUS PART: Hardware