There are so many important design decisions behind a robot: battery, means of locomotion, and position sensing, to name a few. But at a library in Helsinki, one of the most surprising design features for a librarian’s assistant robot was googly eyes. A company called Futurice built a robot for the Oodi library and found that googly eyes were a very important component.
The eyes are not to help the robot see, because of course they aren’t functional — at least not in that way. However without the eyes, robot designers found that people had trouble relating to the service robot. In addition, the robot needed emotions that it could show using the eyes and various sounds along with motion. This was inspired, apparently, by Disney’s rules for animation. In particular, the eyes would fit the rule of “exaggeration.” The robot could look bored when it had no task, excited when it was helping people, and unhappy when people were not being cooperative.
There’s something enchanting about the soft glow of a properly diffused LED, and this is only improved by greater numbers of LEDs. [Manoj Nathwani] was well aware of this, setting out to build a large display using ping-pong balls for their desirable optical qualities.Unfortunately, not everything went to plan, but sometimes that’s not all bad.
The matrix, built back in 2016 for EMF Camp, was sized at 32×18 elements, for a total of 576 pixels. This was achieved with the use of 12 WS2811 LED strips, with the lights set out on a 50mm grid. Cheap knock-off pingpong balls were used for their low cost, and they proved to be excellent diffusers for the LEDs.
With everything wired up to a NodeMCU, basic testing showed the system to be functioning well. However, once the full matrix was assembled in the field, things started to fall over. Basic commands would work for the first 200 LEDs or so, and then the entire matrix would begin to glitch out and display random colors. Unable to fix the problem in the field, [Manoj] elected to simply run the display as-is. Despite the problems, passers-by found the random animations to be rather beautiful anyway, particularly at night.
After the event, [Manoj] determined the issue was due to the excessive length of the data line, which in the final build was 48 meters long. While the problem may be rectified when [Manoj] revisits the project, the audience seemed to appreciate the first revision anyway.
The ballistics of humble potato is a time-honoured research topic for everyone who likes things that go bang. The focus of such work is usually on the launcher itself, with the projectiles being little more than an afterthought. [drenehtsral] decided that the wares of the local organic ammunition supplier were not good enough for him and his minions, so he designed and then 3D printed some rifled potato cannon slugs.
The design was done using OpenSCAD, has a number of adjustable parameters like infill and rifling. We doubt that the rifling introduces any spin, since it is being fired from a smooth bore barrel, but as always 3D printing brings the capability to quickly test different ideas. A quick search on Thingiverse shows a number of 3D printed spuds, so [drenehtsral] is not the first give it a go. However, this did bring to our attention that the field of spud gun projectiles is begging to be explored.
There is enough space inside a projectile to fit an IMU and logging electronics, which would give some very nice empirical data (providing you can recover it of course) on spin, acceleration, and trajectory that can be used to further improve designs. Spring loaded stabilising fins would be cool, and maybe someone can even manage to implement some form of guidance? The possibilities are endless! If you’re up for the challenge, please document your work it and let us know.
Like many hackers, [Tom Szolyga] has soft spot for the venerable Z80. The number of instructions and registers made it relatively easy to program in ASM, and he still has fond memories of the refreshingly straightforward CP/M operating system he used to run on them back in the day. In fact, he loves Z80 computers so much he decided to build one that he could carry around in his pocket.
The result is the Minty Z80, so-called because it lives inside a tin formerly inhabited by every hacker’s favorite curiously strong mint. But the goal of this build wasn’t just to make it small, but also make it convenient to work with. [Tom] is using a ATmega32A to help interface the Z84C0008 microprocessor with the modern world, which allows for niceties such as support for a micro SD card. There’s no onboard USB-to-serial capability, but with an external adapter connected to the Minty’s header, it’s easy to use log into this microcosm of classic computing with a terminal emulator running on a computer or mobile device.
[Tom] has provided the schematics and Bill of Materials for the Minty Z80 on the project’s Hackaday.io page, but as of the latest update, he’s holding off on releasing the board files until he’s sure that all the bugs have been worked out. There’s no word yet if he found any show stoppers in the first iteration of the board design, but he’s posted a picture of the fully assembled miniature retrocomputer in all its glory which seems like a good sign.
The design of the Minty Z80 is similar to that of the Z80-MBC2 by [Just4Fun], but on an even smaller scale. It’s encouraging to see several projects leveraging modern design and components to prevent classic computing from becoming little more than a distant memory.
At first glance, it might not seem to make sense to write shell scripts in C/C++. After all, the whole point to a shell script is to knock out something quick and dirty. However, there are cases where you might want to write a quick C program to do something that would be hard to do in a traditional scripting language, perhaps you have a library that makes the job easier, or maybe you just know C and can knock it out faster.
While it is true that C generates executables, so there’s no need for a script, usually, the setup to build an executable is not what you want to spend your time on when you are just trying to get something done. In addition, scripts are largely portable. But sending an executable to someone else is fairly risky — but your in luck because C shell scripts can be shared as… well, as scripts. One option is to use a C interpreter like Cling. This is especially common when you are using something like Jupyter notebook. However, it is another piece of software you need on the user’s system. It would be nice to not depend on anything other than the system C compiler which is most likely gcc.
Luckily, there are a few ways to do this and none of them are especially hard. Even if you don’t want to actually script in C, understanding how to get there can be illustrative.
As far as controlling robots goes, makers today are spoilt for choice. WiFi and Bluetooth enabled microcontrollers are a dime a dozen, and integration with smartphone apps is a cinch. Despite this, the old methods still hold sway, as [Igor Fonseca] demonstrates with a simple Arduino bot.
It’s a classic build, using a tracked chassis with a pair of motors providing propulsion and skid steering. The motors are controlled by an L298N H-bridge board, with power courtesy of a trio of 18650 batteries. An Arduino Uno acts as the brains of the operation. Control is via a Playstation 2 controller, in this case a 2.4 GHz third party version. This allows the robot to be controlled wirelessly, with the decoding handled by [Bill Porter]’s useful Arduino library.
It’s a cheap approach to building a remote-controlled bot, and one that would be a great way to teach interested children about how to work with embedded systems. We’ve featured a similar build before, too. Video after the break.
India’s Chandrayaan-2 mission to the Moon was, in a word, ambitious. Lifting off from the Satish Dhawan Space Centre on July 22nd, the mission hoped to simultaneously deliver an orbiter, lander, and rover to our nearest celestial neighbor. The launch and flight to the Moon went off without a hitch, and while there were certainly some tense moments, the spacecraft ultimately put itself into a stable lunar orbit and released the free-flying lander so it could set off on its independent mission.
Unfortunately, just seconds before the Vikram lander touched down, an anomaly occurred. At this point the Indian Space Research Organisation (ISRO) still doesn’t know exactly what happened, but based on the live telemetry stream from the lander, some have theorized the craft started tumbling or otherwise became unstable between three and four kilometers above the surface.
Telemetry indicates a suboptimal landing orientation
In fact, for a brief moment the telemetry display actually showed the Vikram lander completely inverted, with engines seemingly accelerating the spacecraft towards the surface of the Moon. It’s unclear whether this was an accurate depiction of the lander’s orientation in the final moments before impact or a glitch in the real-time display, but it’s certainly not what you want to see when your craft is just seconds away from touchdown.
But for Chandrayaan-2, the story doesn’t end here. The bulk of the mission’s scientific goals were always to be accomplished by the orbiter itself. There were of course a number of scientific payloads aboard the Vikram lander, and even the Pragyan rover that it was carrying down to the surface, but they were always secondary objectives at best. The ISRO was well aware of the difficulties involved in making a soft landing on the Moon, and planned their mission objectives accordingly.
Rather than feel sorrow over the presumed destruction of Vikram and Pragyan, let’s take a look at the scientific hardware aboard the Chandrayaan-2 orbiter, and the long mission that still lies ahead of it.
