[Big Fish Motorsports] has a vehicle with an adjustable rear spoiler system that broke in the lead up to a big race. The original builder had since gone AWOL so the considerable talents of [Quinn Dunki] were brought to bear in getting it working again.
Cracking open the black control box of mystery revealed an Arduino, a ProtoShield and the first major road block: the Arduino remained stubbornly incommunicado despite several different methods of trying to read the source code. Turns out the Arduino’s ATMega324 was configured to be unreadable or simply fried, but an ATMega128 [Quinn] had proved to be a capable replacement. However, without knowing how the ten relays for this spoiler system were configured — and the race day deadline looming ever larger — [Quinn] opted to scrap the original and hack together something of her own design with what she had on hand.
Continue reading “Spoiler Alert! Repairing A Race Car Can Get Complicated, Fast.”
[Blecky]’s entry to the Hackaday Prize is MappyDot, a tiny board less than a square inch in size that holds a VL53L0X time-of-flight distance sensor and can measure distances of up to 2 meters.
MappyDot is more than just a breakout board; the ATMega328PB microcontroller on each PCB provides filtering, an easy to use I2C interface, and automatically handles up to 112 boards connected in a bus. The idea is that one or a few MappyDots can be used by themselves, but managing a large number is just as easy. By dotting a device with multiple MappyDots pointing in different directions, a device could combine the readings to gain a LiDAR-like understanding of its physical environment. Its big numbers of MappyDots [Blecky] is going for, too: he just received a few panels of bare PCBs that he’ll soon be laboriously populating. The good news is, there aren’t that many components on each board.
It’s great to see open sourced projects and tools in which it is clear some thought has gone into making them flexible and easy to use. This means they are easier to incorporate into other work and helps make them a great contestant for the Hackaday Prize.
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.