Your quad-copter is hovering nicely 100 feet north of you, its camera pointed exactly on target. The hover is doing so well all the RC transmitter controls are in the neutral position. The wind picks up a bit and now the ‘copter is 110 feet north. You adjust its position with your control stick but as you do the wind dies and you overshoot the correction. Another gust pushed it away from target in more than one direction as frustration passes your lips: ARGGGHH!! You promise yourself to get a new flight computer with position hold capability.
How do multicopters with smart controllers hold their position? They use a technique called Proportional – Integral – Derivative (PID) control. It’s a concept found in control systems of just about everything imaginable. To use PID your copter needs sensors that measure the current position and movement.
The typical sensors used for position control are a GPS receiver and an Inertial Management Measurement Unit (IMU) made up of an accelerometer, a gyroscope, and possibly a magnetometer (compass). Altitude control would require a barometer or some other means of measuring height above ground. Using sensor fusion techniques to combine the raw data, a computer can determine the position, movement, and altitude of the multicopter. But calculating corrections that will be just right, without over or undershooting the goal, is where PID comes into play. Continue reading “Flying with Proportional – Integral – Derivative Control”→
Programmatic CAD, in particular the OpenSCAD language and IDE, has accompanied the maker movement for a while now. After its introduction in 2009, it quickly found its way into the 3D printing toolbox of many makers and eventually became what could be called an Industry Standard among open hardware labs, makerspaces and tinkerers. The Prusa i3, one of the most popular DIY 3D printers, was designed in OpenSCAD, and even Makerbot, the company that sold 100.000 3D printers, uses the language for its “Customizer” – an online tool that allows users to customize 3D printable models with minimal effort.
OpenSCAD is indeed a wonderful tool, and we have been using it a lot. We have become used to its quirks and accepted working with polygon mesh approximations of the models we are trying to design. We have made our peace with excessive rendering times, scripting workarounds and the pain of creating fillets, and we have learned to keep our aesthetic expectations low. We are happy with the fact that there is a way to programmatically create and share virtually any object, but sometimes we wish there was a better way in the open source world. Hint: there is.
Our Hackaday Chief [Mike] sent me an e-mail the other day with a link to the Belgrade Hackaday Badge simulator. He clearly wanted me to enter something into the demo scene competition. The good news is that because of the simulator, you didn’t have to leave your desk to participate. The bad news is that I had very little time left at the end of the month, so I wanted to do something appealing but it had to be fairly easy to roll out. I wound up doing a very quick project but it had a few fine points that I thought I’d share. The end goal was to have an interesting display of Conway’s game of life on the badge.
By the way, there was a completely different project with the same goal by [Jeremias] on Hackaday.io. As far as I know, this was just the result of two people setting out to do the same thing. You’ll see the user interface is a good bit different, so you might see which you prefer.
If you haven’t seen it, the real badge is below. The emulator, of course, just runs as a window on your PC. For those that will be at the conference, or just want to program closer to the actual hardware, there is now a preconfigured MPLABX framework for the PIC18LF25K50 and the bootloader/kernel running on this badge.
Let’s face it: 3-dimensional odometry can be a computationally expensive problem often requiring expensive 3D cameras and optimized algorithms that can be difficult to wrap our head around. Nevertheless, researchers continue to push the bounds of visual odometry forward each year. This past year was no exception, as [Christian], [Matia], and [Davide] have tipped the scale in terms of speed with an algorithm that can track itself in 3D in real time.
In the video (after the break), the landmarks are sparse, the motion to track is relentlessly jagged, but SVO, or Semi-Fast Visual Odometry [PDF warning], keeps tracking its precision with remarkable consistency, making use of “high frequency texture” as a reference. Several other implementations require two cameras or a depth camera variant, but not SVO. It uses a single camera with a high frame rate between 55 and 300 frames per second. Best of all, the trio at the University of Zürich have made their codebase open source and available as a package for ROS.
Sometimes there’s just no place like your desktop. You’ve already got your favorite development tools and references setup or installed and it’s a pain when you’re trying to work on an unfamiliar, or simply uncustomized, system. On your desktop everything is at your fingertips. If you want to search the web, the browser is just an alt-tab away. If you need a calculator, it’s right there to run. Your editor highlights syntax in your favorite colors already.
When developing on a Raspberry Pi, you leave all these creature comforts behind unless you spend the time to configure the Pi to your liking. Then it all gets wiped when you install a new distribution, like the recent change from Wheezy to Jessie. Even then it’s frustrating to switch back and forth between the desktop and the Pi because there is always something on the other system that you need. My usual comment is, “dirty word”, literally.
Cross-developing on your desktop is a very workable solution. We’re going to walk through setting up your desktop and a Pi to do this. This means loading a Pi ARM toolchain on your desktop and a debugging server on the Pi. This’ll let you develop and debug from in the comfort of your desktop. An added advantage is when you put that Pi in a robot you can debug over a wireless link.
Regular expressions might seem arcane, but if you do any kind of software, they are a powerful hacker tool. Obviously, if you are writing software or using tools like grep, awk, sed, Perl, or just about any programming language, regular expressions can simplify many tasks. Even if you don’t need them directly, regular expression searches can help you analyze source code, search through net lists, or even analyze data captured from sensors.
If you’ve been using regular expressions for a long time, they aren’t very hard. But learning them for the first time can be tedious. Unless you try your hand at regular expression crosswords. The clues are regular expressions and the rows and columns all have to match the corresponding regular expressions.
After hour and hours spent in front of a terminal or IDE, a user begins to build a list of infuriating little things. That one pop-up box that happens every time you press that button by mistake. The noise the software makes when the compile fails. Or the horrible reality that your code just crashed because there wasn’t enough difference between uppercase ‘O’ and a zero. In comes the programming font.
The typical way to find a programming font is to troll forums for a user with a similar problem and see if they have a workable solution. [Koen Lageveen] went out and found nearly all of the free programming fonts out there and compiled a list. He then took one more step and wrote a web app that lets you test them out. Hopefully this will help those in the very real struggle for the perfect programming font. You can try out the tool for yourself, and if you really like it [Koen] has all the code up for it on his GitHub.