A self-balancing robot is a great way to get introduced to control theory and robotics in general. The ability for a robot to sense its position and its current set of circumstances and then to make a proportional response to accomplish its goal is key to all robotics. While hobby robots might use cheap servos or brushed motors, for any more advanced balancing robot you might want to reach for a brushless DC motor and a new fully open-source controller.
The main problem with brushless DC motors is that they don’t perform very well at low velocities. To combat this downside, there are a large number of specialized controllers on the market that can help mitigate their behavior. Until now, all of these controllers have been locked down and proprietary. SmoothControl is looking to create a fully open source design for these motors, and they look like they have a pretty good start. The controller is designed to run on the ubiquitous ATmega32U4 with an open source 3-phase driver board. They are currently using these boards with two specific motors but plan to also support more motors as the project grows.
We’ve seen projects before that detail why brushless motors are difficult to deal with, so an open source driver for brushless DC motors that does the work for us seems appealing. There are lots of applications for brushless DC motors outside of robots where a controller like this could be useful as well, such as driving an airplane’s propeller.
I am a crappy software coder when it comes down to it. I didn’t pay attention when everything went object oriented and my roots were always assembly language and Real Time Operating Systems (RTOS) anyways.
So it only natural that I would reach for a true In-Circuit-Emulator (ICE) to finish of my little OBDII bus to speed pulse generator widget. ICE is a hardware device used to debug embedded systems. It communicates with the microcontroller on your board, allowing you to view what is going on by pausing execution and inspecting or changing values in the hardware registers. If you want to be great at embedded development you need to be great at using in-circuit emulation.
Not only do I get to watch my mistakes in near real time, I get to make a video about it.
Getting Data Out of a Vehicle
I’ve been working on a small board which will plug into my car and give direct access to speed reported on the Controller Area Network (CAN bus).
To back up a bit, my last video post was about my inane desire to make a small assembly that could plug into the OBDII port on my truck and create a series of pulses representing the speed of the vehicle for my GPS to function much more accurately. While there was a wire buried deep in the multiple bundles of wires connected to the vehicle’s Engine Control Module, I have decided for numerous reasons to create my own signal source.
At the heart of my project is the need to convert the OBDII port and the underlying CAN protocol to a simple variable representing the speed, and to then covert that value to a pulse stream where the frequency varied based on speed. The OBDII/CAN Protocol is handled by the STN1110 chip and converted to ASCII, and I am using an ATmega328 like found on a multitude of Arduino’ish boards for the ASCII to pulse conversion. I’m using hardware interrupts to control the signal output for rock-solid, jitter-free timing.
Walk through the process of using an In-Circuit Emulator in the video below, and join me after the break for a few more details on the process.
Here’s a slick-looking VGA demo written in assembly by [Yianni Kostaris]; it’s VGA output from an otherwise stock ATmega2560 at 16MHz with no external chips involved. If you’re getting some Super Mario Kart vibes from how it looks, there’s a good reason for that. The demo implements a form of the Super Nintendo’s Mode 7 graphics, which allowed for a background to be efficiently texture-mapped, rotated, and scaled for a 3D effect. It was used in racing games (such as Super Mario Kart) but also in many others. A video of the demo is embedded below.
[Yianni] posted the original demo a year earlier, but just recently added detailed technical information on how it was all accomplished. The AVR outputs VGA signals directly, resulting in 100×120 resolution with 256 colors, zipping along at 60 fps. The AVR itself is not modified or overclocked in any way — it runs at an entirely normal 16MHz and spends 93% of its time handling interrupts. Despite sharing details for how this is done, [Yianni] hasn’t released any code, but told us this demo is an offshoot from another project that is still in progress. It’s worth staying tuned because it’s clear [Yianni] knows his stuff.
Continue reading “Does This Demo Remind You of Mario Kart? It Should!”
Lisp is a supremely elegant programming language, but you won’t find it around much today. That’s a shame; in the 80s and 90s, all the cool kids were using Lisp machines, computers dedicated to the creation and interpretation of Lisp. While the AI renaissance of the 80s is dead, replaced with the machine learning fad of today, Lisp machines have gotten much smaller. Now, they’ll fit in your pocket, and they have parenthesis matching, to boot.
If this build looks familiar, you’re not wrong. A while back, we saw a similar pocket Lisp computer based around the ATMega328 microcontroller with 32k of Flash and 2k of RAM. That’s not a lot by any measure, and a much more suitable processor for an AVR-based pocket Lisp machine would be the big boys of the ATMega family.
The new and improved version of the Tiny Lisp Computer is built around the ATMega1284. If it’s capable enough to run a 3D printer, it should run Lisp very well. With more program space and more RAM come more features including matching parens when entering code, a serial monitor interface, and a program editor – basically a text editor on the chip.
Apart from the larger chip, the circuit remains relatively unchanged. The display is still an OLED that can be had for a few dollars from the usual online retailers, and the other bits of circuitry are still just a handful of resistors, caps, and wire. An off-the-shelf FTDI module (or whatever serial chip you desire) can be added to connect to a serial terminal, and support for a PS/2 keyboard rounds out the board.
Here’s a life protip for you: get really, really good at one video game. Not all of them; you only want to be good – top 10% at least – at one video game. For me, that’s Galaga. It’s a great arcade game, and now it’s IoT. [justin] has been working on publishing high scores from a Galaga board to the Internet. The electronics are actually pretty simple – just a latch on a memory address, and an ESP8266 for comms.
On with the mergers and acquisitions! Lattice has been sold to Canyon Bridge, a Chinese private equity firm, for $1.3 Billion. Readers of Hackaday should know Lattice as the creators of the iCE40 FPGA platform, famously the target of the only Open Source FPGA toolchain.
The Internet of Chocolate Chip Cookies. Yes, it’s a Kickstarter for a cookie machine, because buying a tube of pre-made cookie dough is too hard. There is one quote I would like to point out in this Kickstarter: “Carbon Fiber Convection Heating Element (1300W) is more energy-efficient than traditional electric elements and heats up instantly.” Can someone please explain how a heating element can be more efficient? What does that mean? Aren’t all resistive heating elements 100% efficient by default? Or are they 0% efficient? The Internet of Cookies broke my brain.
The USB Rubber Ducky is a thumb-drive sized device that, when plugged into a computer, presents itself as a USB HID keyboard, opens up a CLI, inputs a few commands, and could potentially do evil stuff. The USB Rubber Ducky costs $45, a Raspberry Pi Zero and a USB connector costs $6. [tim] built his own USB Rubber Ducky, and the results are great.
We’ve seen tiny microcontroller-based computers before, but nothing like this. Where the usual AVR + display + serial connection features BASIC, Forth, or another forgotten language from the annals of computer history, this project turns an AVR into a Lisp machine.
The μλ project is the product of several decades of playing with Lisp on the university mainframe, finding a Lisp interpreter for the 6800 in Byte, and writing a few lisp applications using the Macintosh Toolbox. While this experience gave the author a handle on Lisp running on memory-constrained systems, MicroLisp is running on an ATMega328 with 32k of Flash and 2k of RAM. In that tiny space, this tiny computer can blink a few boards, write to an OLED display, and read a PS/2 keyboard.
The circuit is simple enough to fit on a breadboard, but the real trick here is the firmware. A large subset of Lisp is supported, as is analog and digitalRead, analog and digitalWrite, I2C, SPI, and a serial interface. It’s an amazing piece of work that’s just begging to be slapped together on a piece of perfboard, if only to have a pocket-sized Lisp machine.
Thanks [gir] for the tip.
The idea of winding inductive guitar pickups by hand is almost unthinkable. It uses extremely thin wire and is a repetitive, laborious process that nevertheless requires a certain amount of precision. It’s a prime candidate for automation, and while [Davide Gironi] did exactly that, he wasn’t entirely satisfied with his earlier version. He now has a new CNC version that is more full-featured and uses an ATMega8 microcontroller.
[Davide Gironi]’s previous version took care of winding and counting the number of turns, but it was still an assisted manual system that relied on a human operator. The new upgrade includes a number of features necessary to more fully automate the process, such as a wire tensioner, a wire guide and traverse mechanism (made from parts salvaged from a broken scanner), and an automatic stop for when the correct number of turns has been reached.
All kinds of small but significant details are covered in the build, such as using plastic and felt for anything that handles the wire — the extremely fine wire is insulated with a very thin coating and care must be taken to not scratch it off. Also, there is the need to compute how far the traverse mechanism must move the wire guide in order to place the new wire next to the previously-laid turn (taking into account the winding speed, which may be changing), and doing this smoothly so that the system does not need to speed up and slow down for every layer of winding.
This system is still programmed by hand using buttons and an LCD, but [Davide Gironi] says that the next version will use the UART in order to allow communication with (and configuration by) computer – opening the door to easy handling of multiple winding patterns. You can see video of the current version in action, below.
Continue reading “CNC Upgrade to Guitar Pickup Winding Machine”