This project idea was born from another project that we at makerspace did, as sometimes happens, when you make something to work temporarily, but later see how well it worked you realize it’d be cool to have a proper thing.
And this time it was when we were photographing Makerspace Hack’n’Tell transitional prizes.
Hack’n’Tell is an event we host every first Saturday of each month where anyone can come and present projects that they did. After presentations, everyone who came can vote for the best project and the winner gets a prize for a month (until next event) and in that time he can add something or modify the prize however he wants and at the end of the year the prizes become something really impressive :)
Anyway, we made a lightbox and began planning how could we photograph them in a way to show most of them. Since the prizes have something to look at on every angle, it’s pretty difficult to photograph it in such a way to show everything in a few photos. After a few tries one makerspace member remembered a project he did about ten years ago for a similar reason. It’s supposed to rotate an object 360 degrees with high precision and automatically take photos on every turn. It was perfect for this. We placed it inside our temporary lightbox and shot everything we needed.
Unfortunately, there isn’t any progress article of that rotator (named “Sukeklis v2” btw), but there are progress photos which can be seen below. It’s pretty nicely built and control is simple too – a few http commands to control and get info fully.
If you were reading my blog you probably know that I play airsoft for several years.
Here the sites that we play in don’t change often and in most places airsoft grenades can be used.
In Lithuania, airsoft grenades are essentially firecrackers with up to 1g of powder placed in a small container and filled with BBs, dry peas or anything that is kinda round and represents shrapnel. Very simple, effective and you don’t have to pick it up after using.
So, in that time I noticed that a device that ignites a grenade when I want to at a set location would be very useful when taking back positions from enemy whenever they would barricade themselves in and I dubbed thee – REMDE. For open fields, I’ve come up with a solution that I wrote about here to fling grenades much farther than I could by hands.
The device functions very simply – the bare minimum is made up of two devices – the transmitter and the receiver.
Whenever I go into a nice position that I know enemy is going to sit there when they take it, I place the receiver down somewhere, attach an e-match (the very same used for firework shows) to it and attach the grenade to the e-match.
Now when I need to, with one button, I can check it’s status if I have multiple receivers and I forget if I had used it. With another button I can send a command to ignite the e-match.
I do a lot of projects, but try to only do one or two at a time. It’s how I manage things and time doing them best and I don’t get confused. Sometimes though, my parts from various shops take more time than usual to arrive and I get stuck at a position where I don’t have anything to do.
That’s how this project was done in a short while between other projects that are on hold.
Anyway, first time I had such an idea was when someone brought in random electronic component mixture in a box. There were A LOT of them. Some are old Russian components, some are modern, some I never saw before. And sorting them would be just not worth the time and painful.
There is something that can be done with them apart from dumping them all into the trash container and one thing is casting them into epoxy.
Just about a week ago we finished making a fog machine that can produce a WHOLE lotta fog. It was made for the NoTrollsAllowed hackercamp and everyone loved it. It’s always exciting to go into a tent where you can’t see anything in arms length :D
The idea popped up when we were trying to think of something new to bring in for NTA and we were inspired by a YT video.
And we did much of what he showed the same way from parts we found laying around in the workshop. Only thing we bought were a capillary copper pipe and pumps.
At a workshop that I go to we have a music station that’s been playing rock and metal music for a very long time.
The player used was a generic MP3 player hacked to get power from a 5V charger and since it’s very old it has just(!) 2GB of storage, so not many songs fit on it and you can imagine the playlist repeats itself quite often.
Some time ago we talked about something and an idea popped up to make an upgrade to the music station. We had an RPi 1, wifi adapter and 16GB flash drive laying around, so I put those together to make a music station. And with that you also need a some kinda system to actually play music.
I experimented with various different OS’e just for that – Volumio, RuneAudio (and the other version RuneAudio+R E2), Pi MusicBox and Moode Audio.
Welp, I never thought I’d be doing this, but making a gokart began when a friend said that he has a kinda brand new 4-stroke, 400cc engine and doesn’t know what to do with it. It was at this moment that I spontaneously said – well let’s make a go-kart then.
I didn’t think much about it and my projects up to that point weren’t so big in size or effort, but anyway, I took it on and I’m glad I did. I learned a lot and having a gokart is LOTSA fun!
I am still making this and this post is a part one where I’ll try to briefly explain things that I did to have a thing that you can actually drive a bit.
When I began I didn’t know anything about how to build one, didn’t know much about how to properly work with metal, didn’t know how to weld and other things, but very much thanks to Kaunas Makerspace and people there I was able to make something.
Without any plans or models, I figure things out as I go from examples I find online either in written form, pictures or videos, and there is plenty of material to see.
Apparently gokart builds are a popular thing in Murica and you can find loads of information on YT, forums or all kinds of websites with sometimes in-depth explanations of how stuff works which was super helpful.
A very long time ago, I acquired cheap Microlab desktop speakers from a friend who agreed to trade them in exchange for beer.
At the time I needed them and he didn’t. Right away after plugging them in I noticed that they are pretty shit in quality (would make an annoying humming noise even when powered from a USB charger and the audio quality was terrible), however they are really cheap so… I used them for a while and then set them aside to collect dust.
For those wondering why the speakers made that noise – it’s because of a ground loop. Connecting the speakers through a ground loop isolator would solve this problem.
Now I thought that it would be nice to have those speakers portable for situations where one would be cool to have, but I didn’t need those Microlab desktop speakers. So I thought I could re-purpose them and learn something in the process (like more advanced 3D modeling and how to use a laser-cutter more).
Not long ago I was tasked to make a tool to manage Moodle courses by moving them through categories, creating and cleaning them up. Now I had to make some way to “refresh” the course participants and that means unenrolling teachers and managers, assign different roles, suspending students, adding students, all that stuff.
This was going pretty good and easy until I hit upon a web service function
core_enrol_edit_user_enrolment. It’s an
External function that updates a given user enrolment, it is needed to suspend students from a course.
From the official API docs, we can see that it takes in required arguments courseid (User enrolment ID), ueid (User enrolment ID) and status (Enrolment status).
The problem here is with a ueid (User enrolment ID) argument because there’s no function that returns such an ID. At least I wasn’t able to find one easily accessible and I had to make my own web service function to get that ID.
At the Kaunas Makerspace that I visit very often to do various projects, most tools there are donated, some are bought and some tools are self-made (like a spot-welder that I used to connect batteries).
In the case of cordless drills the situation was never good. There are a few of them, but all are missing batteries or have dead packs and sometimes when you need to screw or drill something a bit it’s a little annoying, so we made a few from old LiPo (18650) cells that we salvaged from laptop batteries for Meec cordless drills. They have a very neat battery holder design – batteries simply slide in.
Making of the battery pack is easy, hardest part was to make a case for them and of course a charging station.
So some time ago I was asked to make this apparatus – a (flash?) light with intensity controlled remotely. The idea was that it could be hanged in some place and aimed at what needed to be illuminated and after that you should be able to remote-control the light intensity.
The light source (doesn’t need to be very bright) must be able to have enough power to last for at least a week sitting in idle (only listening to radio signals) and a few hours of constant illumination at night. Depending on the darkness of the night the light source intensity could be adjusted. However the distances over which it would be controlled are 200-300m.
The whole receiving and lighting part needs to be modular – battery, controller and light must be separate for easier handling.
This is pretty easy, fun and a straight-forward task to do with arduinos, but the radio modulation presented a challenge, since it’s the first time I have touched these and SPI as well.
Turns out that there aren’t many solutions to this. There exists a few radio modulators, but they all go up to 100m at best AFAIK. However there is one – LoRa and that’s what I used.
Reading different sources I could gather that a normal distance for LoRa is a few kilometers and that’s what it was designed for. The distance you could reach obviously depends on the environment you’re in, the equipment you use (antennas, power source) and the settings you set for modulators.
LoRa is able to reach such distances with the cost of transfer speed. Meaning it’s ideal to send some sensor values from time to time and not for something that needs to pass a lot of data or pass that data very fast.
So I got to know all the requirements and started to sketch out ideas of how I might construct this.