software

79 Articles

PyGame Celebrates 20 Years By Releasing PyGame 2.0

October 28, 2020 by 7 Comments

Python is an absolutely fantastic language for tossing bits of data around and gluing different software components together. But eventually you may find yourself looking to make a program with an output a bit more advanced than the print() statement. Once you’ve crossed into the land of graphical Python programming, you’ll quickly find that the PyGame library is often recommended as a great way to start pushing pixels even if you’re not strictly making a game.

Today, the project is celebrating an incredible milestone: 20 years of helping Python developers turn their ideas into reality. Started by [Pete Shinners] in 2000 as a way to interface with Simple DirectMedia Layer (SDL), the project was quickly picked up by the community and morphed into a portable 2D/3D graphics library that lets developers deploy their code on everything from Android phones to desktop computers.

Things haven’t always gone smoothly for the open source library, and for awhile development had stalled out. But the current team has been making great progress, and decided today’s anniversary was the perfect time to officially roll out PyGame 2.0. With more than 3,300 changes committed since the team started working on their 2.0 branch in July of 2018, it’s a bit tough to summarize what’s new. Suffice to say, the library is more capable than ever and is ready to tackle everything from simple 2D art up to 4K GPU-accelerated applications.

Rip and tear in PyGame 2.0

If you haven’t given PyGame a try in awhile, don’t worry. The team has put special effort into making the library as backwards compatible as possible, so if you’ve got an old project kicking around that you haven’t touched in a decade, it should still run against the latest and greatest version. If you’ve never used it before, the team says they’ll soon be releasing new tutorials that show you how to get the most out of this new release.

Whether you’re putting together your own implementation of Conway’s “Game of Life” or creating the graphical front-end for your own Linux distribution, PyGame is a powerful tool to have in your collection. Our sincere congratulations to all PyGame developers, past and present, for making it to this auspicious occasion. We can’t wait to see what the next decade will bring.

[Thanks to deshipu for the tip.]

Hardware Vs Software: Fight!

October 10, 2020 by 41 Comments

It’s one of the great cliches in the hacker world: the hardware type and the software type. You can tell which of these two you are quite easily. When a project is actually 20% done, but you think it’s 90% done, and you say to yourself “And the rest is a simple matter of software”, you’re a hardware type. Ask anyone who has read my code, and they’ll tell you, I’m a hardware type.

Along with my blindness to the difficulties of getting the code right, I’ve also admittedly got an underappreciation of what powers lie in the dark typing arts. But I am not too proud to tip my hat when I see an awesome application of the soft stuff. Case in point: this Go board sequencer that we ran last week. An overhead webcam parses players’ moves as they put black and white stones down while playing the game of Go, and turns this into music.

The pure software type will be saying “but there’s a webcam and a Go board”. And indeed, that’s true. There are physical elements to this project that anchor it in the shared reality of the two people playing. But a hardware project this isn’t; it’s OpenCV and Max/MSP that make it work.

For comparison, look at the complexity of this similar physical sequencer. It’s got a 16 x 16 array of LEDs and switches and a CNC milled, primed, and painted surface that’s the size of a twin bed. Sawdust and hand-soldering: that’s a hardware project.

What I love about the Go sequencer is that it uses software just right. The piece is still physical. It could have just as easily been a VR world, where the two people would interact with each other only inside their goggles. But somehow that’s not quite as human as putting stones on a wooden board, sitting across from, and maybe even looking at, your opponent. The players aren’t forced to think about the software. They don’t feel like they’re playing a video game.

But at the same time, the software side of things makes all of the horrible hardware problems go away. Nobody is soldering a rat’s nest of 169 switches. There’s a webcam plugged into the USB port of a laptop. There’s a deep simplicity there.

Should you always trade out arcade buttons for OpenCV? Absolutely not! But is it worth considering the soft side when doing it in hardware is just too, well, hard? I’m open.

This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter. Want this type of article to hit your inbox every Friday morning? You should sign up!

Autodesk Announces Major Changes To Fusion 360 Personal Use License Terms

September 16, 2020 by 313 Comments

Change is inevitable, and a part of life. But we’re told that nobody likes change. So logically, it seems we’ve proved nobody likes life. QED.

That may be a reach, but judging by the reaction of the Fusion 360 community to the announced changes to the personal use license, they’re pretty much hating life right now. The clear message from Autodesk is that Fusion 360 — the widely used suite of CAD and CAM software — will still offer a free-to-use non-commercial license for design and manufacturing work, with the inclusion of a few very big “buts” that may be deal-breakers for some people. The changes include:

  • Project storage is limited to 10 active and editable documents
  • Exports are now limited to a small number of file types. Thankfully this still includes STL files but alas, DXF, DWG, PDF exports are all gone
  • Perhaps most importantly to the makerverse, STEP, SAT, and IGES file types can no longer be exported, the most common files for those who want to edit a design using different software.
  • 2D drawings can now only be single sheet, and can only be printed or plotted
  • Rendering can now only be done locally, so leveraging cloud-based rendering is no longer possible
  • CAM support has been drastically cut back: no more multi-axis milling, probing, automatic tool changes, or rapid feeds, but support for 2, 2.5, and 3 axis remains
  • All support for simulation, generative design, and custom extensions has been removed

Most of these changes go into effect October 1, with the exception of the limit on active project files which goes into effect in January of 2021. We’d say that users of Fusion 360’s free personal use license would best be advised to export everything they might ever think they need design files for immediately — if you discover you need to export them in the future, you’ll need one of the other licenses to do so.

To be fair, it was pretty clear that changes to the personal use license were coming a while ago with the consolidation of paid-tier licenses almost a year ago, and the cloud-credit system that monetized rendering/simulation/generative design services happening on the Autodesk servers. Features removed from the free license in this week’s announcement remain in place for paid subscriptions as well as the educational and start-up license options.

The problem with these personal use licenses is that it’s easy to get used to them and think of them as de facto open-source licenses; changing the terms then ends up leaving a bad taste in everyone’s mouth. To their credit, Autodesk is offering a steep discount on the commercial license right now, which might take some of the sting out of the changes.

Update 09-25-2020: Autodesk has announced that STEP file export will remain in the free version of Fusion 360

Improving More Leaf Design Flaws

September 16, 2020 by 19 Comments

[Daniel] was recently featured here for his work in improving the default charging mode for the Nissan Leaf electric vehicle when using the emergency/trickle charger included with the car. His work made it possible to reduce the amount of incoming power from the car, if the charging plug looked like it might not be able to handle the full 1.2 kW -3 kW that these cars draw when charging. Thanks to that work, he was able to create another upgrade for these entry-level EVs, this time addressing a major Leaf design flaw that is known as Rapidgate.

The problem that these cars have is that they still have passive thermal management for their batteries, unlike most of their competitors now. This was fine in the early ’10s when this car was one of the first all-electric cars to market, but now its design age is catching up with it. On long trips at highway speed with many rapid charges in a row the batteries can overheat easily. When this happens, the car’s charging controller will not allow the car to rapid charge any more and severely limits the charge rate even at the rapid charging stations. [Daniel] was able to tweak the charging software in order to limit the rapid charging by default, reducing it from 45 kW to 35 kW and saving a significant amount of heat during charging than is otherwise possible.

While we’d like to see Nissan actually address the design issues with their car designs while making these straighforward software changes (or at least giving Leaf owners the options that improve charging experiences) we are at least happy that there are now other electric vehicles in the market that have at least addressed the battery thermal management issues that are common with all EVs. If you do own a Leaf though, be sure to check out [Daniel]’s original project related to charging these cars.

Continue reading “Improving More Leaf Design Flaws” →

Optimizing GIF Playback For Microcontrollers

August 3, 2020 by 12 Comments

Despite being cooked up by Compuserve back in the late 1980s, GIFs have seen a resurgence on the modern internet, mostly because they’re fun. However, all our small embedded systems are getting color screens these days, and they’d love to join in the party. [Larry Bank] has whipped up a solution for just that reason, letting embedded systems play back short animated GIFs with limited resources.

[Larry] does a great job of explaining how the GIF format works, using LZW compression and variable-length codes. He talks about how the design of the format presents challenges, particularly when working with microcontrollers. Despite this, the final code works well, and is able to work with most animated GIFs of the right dimensions and construction. 24K of RAM is required, and image width is limited to 320 pixels. Images can be loaded from flash, memory, or SD cards, and he notes that best performance is gained with a microcontroller with fast SPI for writing to screens quickly.

It’s a great piece of software that promises to add a lot of charm, or silliness, to microcontroller projects. It also simplifies the use of animations, which can now be designed on computers rather than by using onboard graphics libraries. GIF really is the format that never seems to die; we’ve featured cameras dedicated to the form before. Video after the break.

Continue reading “Optimizing GIF Playback For Microcontrollers” →

Ask Hackaday: Why Did GitHub Ship All Our Software Off To The Arctic?

July 29, 2020 by 95 Comments

If you’ve logged onto GitHub recently and you’re an active user, you might have noticed a new badge on your profile: “Arctic Code Vault Contributor”. Sounds pretty awesome right? But whose code got archived in this vault, how is it being stored, and what’s the point?

Continue reading “Ask Hackaday: Why Did GitHub Ship All Our Software Off To The Arctic?” →

Tackling Trunked Radio With Software

June 16, 2020 by 12 Comments

For those starting to wade into radio as a hobby, one of the first real technical challenges is understanding trunked radio systems. On the surface, it seems straightforward: A control channel allows users to share a section of bandwidth rather than take up one complete channel, allowing for greater usage of the frequency range. In practice though it can be difficult to follow along, but now it’s slightly easier thanks to software defined radio.

This guide comes to us from [AndrewNohawk], who is located in San Francisco and is using his system to monitor police, fire, and EMS activity. These groups typically used trunked radio systems due to the large number of users. For listening in, nothing more than an RTL-SDR setup is needed, and the guide walks us through using this setup to find the control channels, the center frequency, and then identifying the “talk groups” for whichever organization you want to listen in on.

The guide goes into great detail, including lists of software needed to get a system like this started up, and since [AndrewNohawk] is a self-identified “radio noob” the guide is perfectly accessible to people who are new to radio and specifically new to trunked systems like these. Once you get the hang of it, it’s not too hard to scale up, either.