Ever Wonder How The Bots On Robot Wars Were Built?

Building a robot that can do anything well is a tough challenge. Building one that can stand up to another robot trying to violently put it out of commission is an even harder task. But it makes for some entertaining television! It is this combination that thrust a few creative robot building teams into the world of Robot Wars.

SMIDSY in the pits for series 5 of the UK Robot Wars TV show. From left to right: [Andy Pugh], [Robin Bennett], and [Mik Reed]. RIP [Mik].SMIDSY in the pits for series 5 of the UK Robot Wars TV show. From left to right: [Andy Pugh], [Robin Bennett], and [Mik Reed]. RIP [Mik].SMIDSY, short for the insubstantial excuse heard by many a motorcyclist “Sorry Mate, I Didn’t See You”, is a robot that competed in several seasons of the British incarnation of the Robot Wars TV show. It wasn’t the most successful of machines because its weapons were slightly weedy compared to some of the competition, but it was one of the more robust and reliable platforms on the circuit at the time thanks to its combination of simple uncomplicated construction and extremely good design. I had the pleasure of being on the team that built and competed with SMIDSY and carry from it some of the more found memories from that decade.

A few weeks ago I learned that a friend from that period in my life had died following an illness. I hadn’t seen [Mik] for a few years as our lives had drifted apart, but if we were to turn back the clock nearly a couple of decades you would find us and about twenty other fellow members of the Ixion British motorcyclist’s mailing list hard at work building a Robot Wars robot.

The hard work and determination make this a great story. But even more so it’s fun to look back on the state of the art of the time and see some clever workarounds in a time when robot building was just starting to be approachable by the average engineer.

The Cutting Edge of 1990s Fighting Robot Design

SMIDSY in one of its earlier incarnations.SMIDSY in one of its earlier incarnations.

Our robotics team first convened in 1997 to brainstorm a robot design that matched the basic parameters of the televised competition. The nascent SMIDSY would have to be robust and well-armoured, with no extraneous parts that could be broken off. It would have to be fireproof, capable of withstanding inversion, and able to deliver exceptional power and traction.

The layout evolved into a flat rectangular machine with wheels rather than tracks or legs. Those wheels poked out the top and bottom of the chassis such that it could propel itself either way up. The weapon was envisioned as a set of hinged jaws that could double as a wedge or flipper, and our principal means of aggression was to be either pushing our opponents into one of the arena traps, or flipping them over and rendering them immobile. We also fitted a set of steel spikes on the rear, but these were not a spectacularly useful weapon.

Framing with Heavy Metal

The first SMIDSY chassis, showing the Sturmey Archer gearboxes in situ.The first SMIDSY chassis, showing the Sturmey Archer gearboxes in situ.

The final robot was designed by [Andy Pugh], who has appeared on these pages before with his motorcycle remanufacturing. It took the form of a folded and spot welded sheet steel monocoque chassis with four go-kart wheels. Each wheel had inside it a Sturmey Archer in-hub bicycle gearbox, and the pair of wheels on each side of the machine had bicycle chains linking them to a motor mounted centrally in the chassis. The jaws were hinged at the front top and bottom of the chassis, and were operated by the electric seat rails used in Jaguar cars of the day.

A Protective Coat of Gas Pipeline Detritus

Any robot entering the competition would require sufficient armour to withstand attack from both the other competitors and the house robots used by the TV production company to ensure that their blatant fixing of any semblance of competition remained on track show delivered entertainment to its viewers. We reasoned that the armour priorities lay in the sides of SMIDSY rather than its top and bottom, thus we used a relatively thin polycarbonate/aluminium sandwich for the latter and much more substantial polypropylene at the sides.

The side panels came from an unusual source, British domestic natural gas pipelines are made of a distinctive thick-walled yellow polypropylene pipe that is designed to withstand accidentally being hit with a backhoe digger. It is extraordinarily tough stuff, and the curve in SMIDSY’s side panels was the curve of a section cut from this pipe. There was a period when members of the TeamIxion Robot Wars crew would scour the roadsides of the country spotting discarded off-cuts of yellow pipe left behind by British Gas road works, and eventually we had quite a collection of different sections.

Fire Ist Verboten

The PVC cooling air duct used on the first SMIDSY chassis, with the motors side-by-side and before installation of gauze over the air exhaust holes in the motor housing. The later chassis had the motors in-line, and used an aluminium duct.The PVC cooling air duct used on the first SMIDSY chassis, with the motors side-by-side and before installation of gauze over the air exhaust holes in the motor housing. The later chassis had the motors in-line, and used an aluminium duct.

The robots themselves were strictly forbidden from using any form of flame, but no such issues faced the TV company. Both the arena and the house robots featured gas jet flamethrowers, and thus SMIDSY would have to be completely fireproof.

Its internal compartments were sealed, but this raises an additional issue of overheating. The solution was to build a forced air cooling system into the robot. A powerful centrifugal fan drove a set of ducts and clip-on cowls that passed air at high speed through the motors and speed controller compartments, with all air intakes and outlets covered by stainless steel gauze. This system gave us complete protection from flames despite more than one effort from the house robots to use them on SMIDSY. The system proved to be one of our secret weapons as many teams suffered a motor or controller failure from overheating while we completely avoided this fate.

Over-Volting Motor Tech of the Time

Permanent magnet motors were ubiquitous among British Robot Wars teams at the time. The Bosch GPA750 24V 1HP permanent magnet DC units were found in automotive applications such as truck wiper motors. With our forced air cooling we could run them at twice their rated voltage, making SMIDSY with its reliable 4 wheel drive an extremely powerful machine with the traction to use it.

SMIDSY's chassis, showing the Iskra motor and later disc weapon.SMIDSY’s chassis, showing the Iskra motor and later disc weapon.

In the 1990s it was still rare to see a motor controller featuring a microcontroller, at least at our level. There were teams that had some success with their own designs, but the majority had off-the-shelf drivers such as the 4QD ones we used. These were PWM controllers employing a traditional hybrid of analogue and digital circuitry, and they took a DC input from a variable resistor. Some teams had RC model servos turning a real variable resistor, we had a little board that interfaced the servo output of our receiver with a solid state potentiometer. Our power came from lead-acid gel-cells, as did that of most other teams. We used packs of the cylindrical single cells instead of the 6V or 12V batteries, and our cells lived in the compartments on each side of SMIDSY between its wheels.

The Arms Race

It’s fair to say the version of SMIDSY that appeared in the first TV series did not shine. There are innumerable fan sites upon which you can find the combat details, however we are here to talk about the machine’s engineering. Following that less-than-stellar performance it was decided that while the basic design had proved reliable, we needed a more useful weapon.

We settled on a spinning disc at the rear of the machine. There was not enough space to hold it so a new wider SMIDSY chassis was produced. It retained the same layout as the original with a few enhancements such as the motors being in line rather than alongside each other. The disc weapon comprised two water-cut steel discs with a pulley between them, fed by a V-belt from an Iskra 1HP DC motor mounted on the chassis. The Iskra’s shaft emerged near the top of the robot and its belt needed to be aligned at its centre, so a pulley was constructed that sat over the motor like a top-hat. The whole was driven from another 4QD board, and when it was spun up it made for a fearsome weapon that would happily chew up almost anything we threw at it.

So… What happened?

I encounter many roboteers in my travels round the world of hackspaces, some of whom are faces from the old days, and others devotees of the current incarnation whose knowledge of SMIDSY’s battles puts my recollections to shame. From them I have learned about the current state of the art in fighting robots, and it is a world away from the technology of a machine such as SMIDSY. Where we had relatively simple hobby grade 49MHz PPM remote control they have much more advanced 2.4 GHz PCM systems. In the place of their brushless motors we had permanent magnet motors with PWM speed controllers from the age of discrete components rather than microcontrollers. Our power came from lead-acid gel-cells rather than lithium-ion packs. It is certain that a machine like SMIDSY would not be even slightly competitive against a modern equivalent, but there is still plenty of interest to be found in other aspects of its construction.

A SMIDSY skin from 2002. Those Gnashing Jaws Of Doom probably had more of the Toothless Gums Of Disappointment about them, but we thought it sounded good at the time.A SMIDSY skin from 2002. Those Gnashing Jaws Of Doom probably had more of the Toothless Gums Of Disappointment about them, but we thought it sounded good at the time.

SMIDSY appeared in a total of five series’ of the UK Robot Wars TV shows, as well as a set of TV specials, and (cloaked in a red covering and under the name Sprocket) in a robot Olympics show. We also took it on the road to a series of Robot Wars live shows, ensuring that many of the team’s members had a chance to take the helm.

We never made it to the quarter-finals in any of the competitions, our fate was always to see off all comers in the heats but to be denied progression by eventual finalists or winners. I’ve written here in the past about the dangers of appearing as a contestant in a TV show, it is fair to say that the TV production company used the house robots to ensure what they saw as good programming rather than necessarily fair competition. But we came out of it all with something more than would be granted by success in the final rounds. Nearly twenty years later I would wager we all still have our SMIDSY T-shirts somewhere. Indeed I was once approached at a motorway service station while wearing mine by a couple of fans of the show’s presenter [Craig Charles] (who some of you may also recognise as Red Dwarf‘s [Dave Lister], and who I found to be a top bloke). I have a battle-damaged vinyl SMIDSY outer covering, and the episode serves as a conversational reference in hackerspace discussions. We eventually sold the robot to another team who continue to take it on the road with their live show to this day. So the ‘bot is gone and in a few days we will pay our respects at [Mik]’s memorial, but memories of the fun we had engineering as a team I will carry with me forever.

Posted in Engineering, Featured, robot, robot wars, robotic combat, robots hacks, SMIDSY | Leave a comment

Stecchino Game is all about Balancing a Big Toothpick

Stecchino demo by the creator

Self-described “Inventor Dad” [pepelepoisson]’s project is called Stecchino (English translation link here) and it’s an Arduino-based physical balancing game that aims to be intuitive to use and play for all ages. Using the Stecchino (‘toothpick’ in Italian) consists of balancing the device on your hand and trying to keep it upright for as long as possible. The LED strip fills up as time passes, and it keeps records of high scores. It was specifically designed to be instantly understood and simple to use by people of all ages, and we think it has succeeded in this brilliantly.

To sense orientation and movement, Stecchino uses an MPU-6050 gyro and accelerometer board. An RGB LED strip gives feedback, and it includes a small li-po cell and charger board for easy recharging via USB. The enclosure is made from a few layers of laser-cut and laser-engraved material that also holds the components in place. The WS2828B LED strip used is technically a 5 V unit, but [pepelepoisson] found that feeding them direct from the 3.7 V cell works just fine; it’s not until the cell drops to about three volts that things start to glitch out. All source code and design files are on GitHub.

Games are great, and the wonderful options available to people today allow for all kinds of interesting experimentation like a blind version of tag, or putting new twists on old classics like testing speed instead of strength.

Posted in arduino, Arduino Hacks, balance, balancing game, Dad Inventors, enclosure, francais, game, laser cut, led hacks, led strip, MPU-6050, open hardware, open source, Papas Inventeurs, ws2812b | Leave a comment

LED Strips Are So Hot Right Now

Sometimes there will appear a figure that flies in the face of reason, and challenges everything you think you know about a subject. Just such a moment came from [Chris Taylor] at Milton Keynes Makerspace when he characterised a set of LED strips, and the figure in question was that he found an LED strip creates the same amount of heat as its equivalent incandescent bulb.

We can hear your coffee hitting the monitor and your reaching for the keyboard to place a suitably pithy comment, because yes, that’s a pretty unbelievable statement. But it’s no less true, albeit that the key to it lies in its details. If you have a 100 W incandescent bulb, 88% of the energy is radiated as light and infra-red, leaving 12 W heating the bulb itself. To get the same light output from an LED meanwhile we’d only need 17 W, of which 11.9 W would be left to heat the LED. Which means that an LED strip can get as hot as an incandescent bulb with equivalent light output, and he’s run some tests to prove it.

If you’ve worked with LEDs, you’ll know that they get hot. But to learn that they have the potential to get as hot as their incandescent equivalents is something of a eye-opener, and should demonstrate the need for adequate thermal mitigation. It’s easy to take them for granted, and we’ve taken a look before at some of their safety pitfalls.

Disclosure: [Jenny List] is a member of MK Makerspace.

Posted in LED efficiency, led hacks, led strips, leds, news | Leave a comment

A DIY Nine Channel Digital Scope

Have you ever found yourself in the need of a nine channel scope, when all you had was an FPGA evaluation board? Do not despair, [Miguel Angel] has you covered. While trying to make sense of the inner workings of a RAM controller core, he realized that he needed to capture a lot of signals in parallel and whipped up this 9-channel digital oscilloscope.

The scope is remote-controlled via a JavaScript application, and over Ethernet. Graphical output is provided as a VGA signal at full HD, so it is easy to see what is going on. Downloading sampled data to the controlling computer for analysis is in the works. [Miguel] runs his implementation on an Arty A7 development board which is currently available for around a hundred dollars, but the design is transferable to other platforms. The code and some documentation is available on GitHub and there is a demo video after the break.

Oscilloscopes occupy a special place in hacker lore, be they analog home-made ones, units used to play Quake, or being tricked into working outside their specifications. The last one even features comments that recommend the use of an FPGA similar to the one used here.

Posted in digital Oscilloscope, diy oscilloscope, FPGA, oscilloscope | Leave a comment

Want A Leak-Proof Camper? Better Fire Up The 3D Printer Now.

Ah, the great outdoors.  Rejuvenating air rife with mosquitoes and other nasties, and spending some time hanging out in the woods sleeping in a 3D printed camper. Wait– what was that last one again?

Yep, it’s exactly what it sounds like. A Canadian team headed by [Randy Janes] of Wave of the Future 3D, printed a camper at [Create Cafe] in Saskatoon, Saskatchewan, using high-flow nozzles on one of the largest 3D printers in North America. These layers are 10.3mm thick!!

This trailer is one single printed piece, taking 230 hours — nine and a half days — of straight printing with only a few hangups. Weighing 600lbs and at 13 feet long by six feet wide — approximately 507 cubic feet, this beats the previous record holder for largest single piece indoor print in size by three times over.

As a prototype, this is an impressive feat, but what about going forward? [Janes] has said that he’s already been approached by buyers because of the prospect of completely customizeable design — this prototype can convert into an ice fishing hut — and boasts no seams which means no leaks! If you’ve never woken up to a soaked-through sleeping bag, it is not pleasant.

We can’t 3d print a whole car — yet — but we can produce replacement car and motorcycle parts and hack them into awesome near-future functionality.

[Thanks for the tip, Qes!]

Posted in 3d Printer hacks, camper, camping, canada, high-flow, Nozzle, Outdoors, record | Leave a comment

An Introduction to Storm Detector Modules

Lightning storm detectors have been around for a surprisingly long time. The early designs consisted of a pair of metal bells and a pendulum. When there was a charge applied, for example by connecting one bell to the ground and the other to a lightning rod, the bells would ring when a lightning storm was close by. In the mid 18th century, these devices were only practical for demonstration and research purposes, but very likely represent the earliest devices that convert electrostatic charge to mechanical force. A bit over a hundred years later, the first lightning detector was considered by some as the first radio receiver as well.

As soon as I found out about storm detector chips, I knew I would have to get one working. For about $25, I ordered an AMS AS3935 module from China. This chip has been featured before in a number of excellent projects such as Twittering lightning detectors, and networks of Sub-Saharan weather stations. While there’s an Arduino library for interfacing with this IC, I’m going to be connecting it up to an ESP8266 running the NodeMCU firware, which means digging into the datasheet and writing some SPI code. If any of the above tickles your fancy, read on!

Unlike the earliest charge-based detectors, this one works by picking up the RF signal produced by distant lightning strikes using a small 500 kHz antenna and doing some digital signal processing.

The detector is capable of differentiating between lightning strikes and other types of RF noise, then using the signal from the lightning strikes to estimate the distance to the stormfront, up to 40 kilometers away. This is quite nice for two reasons: it detects active storms from quite a bit further than you can with your eyes and ears, and it gives you a reasonable idea of how fast the storm is coming in.

It’s easy to think of possible applications. Golf courses, sports fields, pools, and beaches would all benefit from earlier storm detection. Besides outdoor activities, datacenters, airports, and construction crews also need to know about incoming lightning storms.

On my end, I live in Southeast Asia and rainy season can be a little epic. Downpours are very localized, incredibly intense, often cause floods, and occur with little warning. Like most residents I drive a motorbike, and being stuck in traffic or on the highway in that intensity of rain is miserable. Given the option, it’s usually better to stop, have a coffee, and let it pass.

Weather reporting isn’t terribly useful for planning trips because most showers are very localized, short, and frequent. The weather report throughout rainy season is simply “28 degrees Celsius, 75% chance of showers” every day, so adding a storm detector to my motorbike seemed practical and fun. Even if it only works some of the time, it would be fantastic. In fact, I’m surprised I’ve never seen this as a product – if it works, someone please do this.

To the Lab!

Back to our detector, there exists an Arduino library to interface with it, if that’s your style. It looks easy enough to use, but my personal preference is to use NodeMCU and the ESP8266, although it has no built-in library for this chip.

Luckily, we have a datasheet (PDF) for the AS3935, and the chip supports both SPI and I2C interfaces. I had been looking for an excuse to explore SPI in Lua on the NodeMCU, and this was perfect. Since we’re just using plain SPI, hopefully the code will be easier to port to other platforms as well.

Let’s start with the basic setup. To use SPI, the datasheet says that the Select Interface (SI) pin needs to be pulled to ground. I also wanted to use the on-chip voltage regulator, so the EN_V chip needed to be pulled high. Finally, the chip pulls an interrupt pin high on every event detection to let the connected microcontroller know that something interesting has happened.

To improve noise immunity on this pin, I used a 1kΩ pull down resistor to ground (not shown below). The latter was probably not necessary but helped reduce false positives during testing while handling the circuit without an enclosure.

Default pins for SPI 1. Source: NodeMCU Documentation

Next, we connect all the pins required by SPI. There are 4: Master Out Slave In (MOSI), Master In Slave Out (MISO), clock (SCK) and Chip Select (CS). I’ve included a small table detailing what these pins are under NodeMCU, keep in mind they’re likely to be different on other platforms.

An important point is that the CS pin is not automatically managed by the NodeMCU during SPI communications. You’ll need to set its value like any other GPIO pin, which we’ll cover later. Before you begin programming, I highly recommend you double-check all your pins are connected correctly. I lost an hour that way and felt silly.

We start by initializing SPI and the relevant pins:

spi.setup(1, spi.MASTER, spi.CPOL_LOW, spi.CPHA_LOW, 8, 256);
IRQ = 2
gpio.mode(CS, gpio.OUTPUT)
gpio.mode(IRQ, gpio.INPUT)

On the NodeMCU, SPI 0 is used to communicate with the onboard flash memory, so we’ve selected SPI 1, with mostly default features and 8 bits per data item. Of note is that we’ve set a clock divider of 256 on the SPI frequency. This is because the AS3935 supports a maximum SPI frequency of 2 Mhz and the NodeMCU defaults to a much faster speed (at least 20 Mhz). Note that the chip should not be set to an SPI frequency of 500 kHz, as this is the resonant frequency of the lightning detector antenna(!).

We’ve also set the chip select pin as an output on D8, and connected the interrupt pin (IRQ) as an input. IRQ will be raised high on each new event, and remain high until you read the interrupt register to determine the event type. Using it as a proper interrupt or trigger on the NodeMCU did not work reliably, so a normal input pin that we can poll will have to do for now.

Referring to the datasheet, reading from and writing to the AS3935 requires that we send eight bytes over SPI. The first two bits determine whether you are requesting a read or write, and the next six determine the target register. If you are reading from the chip, you first need to set CS low to initiate the read (before sending a request), then raise CS high-low-high when done. Let’s extend our program to read the interrupt register each time the chip outputs an event:

function reason() gpio.write(CS, gpio.LOW) tmr.delay(30) spi.send(1,0x43) tmr.delay(30) read = spi.recv(1, 8) print(string.byte(read)) gpio.write(CS, gpio.HIGH) tmr.delay(30) gpio.write(CS, gpio.LOW) tmr.delay(30) gpio.write(CS, gpio.HIGH) tmr.delay(30)
end function poll() x = gpio.read(IRQ) if x == 1 then reason() end tmr.alarm(1, 100, 1, function() poll(0) end)

In the code above, we poll the IRQ pin every 100 ms to see if it is high. If so, we set CS to low to indicate we are about to request a read. Then we send the command 0x43, which translates to binary 01000011. The first two bits (01) request a read, and the last six bits (000011) indicate we want to read register address 0x03. The last four bits of the response will contain the detected event type. Once the command is sent, we read eight bits from the SPI port and print the result, then finally set the CS pin high-low-high to signal we’re done reading.

The result of the above code is an irregular stream of ‘4’ (0100) to the terminal. If I touch the antenna, it outputs a ‘1’ instead. Looking at the datasheet, an interrupt reason of 0100 is a ‘disturber’: a radio signal at the frequency of interest, but not lightning. In big Asian cities, there’s always someone arc welding nearby; it twinkles like stars below when arriving on a nighttime flight. Interrupt reason 0001 means a problem with high electrical noise, which makes sense as well. A lightning event would output ‘8’ (1000), but it’s presently dry season so that’s unlikely at this time.

We can now successfully receive data from the device, but it’s not particularly useful yet. Next time, we’ll cover how to write to the configuration registers to set it up to work more practically, and have a bit of creative fun with what we do with the data.

Posted in Featured, how-to, lightning detector, lua, Microcontrollers, NodeMCU, radio hacks, Skills, spi, tool hacks | Leave a comment

What to do with Your Brand New Ultrasonic Transducer

We wager you haven’t you heard the latest from ultrasonics. Sorry. [Lindsay Wilson] is a Hackaday reader who wants to share his knowledge of transducer tuning to make tools. The bare unit he uses to demonstrate might attach to the bottom of an ultrasonic cleaner tank, which have a different construction than the ones used for distance sensing. The first demonstration shows the technique for finding a transducer’s resonant frequency and this technique is used throughout the video. On the YouTube page, his demonstrations are indexed by title and time for convenience.

For us, the most exciting part is when a tuned transducer is squeezed by hand. As the pressure increases, the current drops and goes out of phase in proportion to the grip. We see a transducer used as a pressure sensor. He later shows how temperature can affect the current level and phase.

Sizing horns is a science, but it has some basic rules which are well covered. The basic premise is to make it half of a wavelength long and be mindful of any tools which will go in the end. Nodes and antinodes are explained and their effects demonstrated with feedback on the oscilloscope.

We have a recent feature for an ultrasonic knife which didn’t cut the mustard, but your homemade ultrasonic tools should be submitted to our tip line.

Posted in blade, drill, how-to, inverter, saw, tool, tool hacks, tune, tuning, ultrasonic | Leave a comment

3D Printed Raspberry Pi NAS with Dual Drive Bays

While it might not pack the computational punch you’d usually be looking for in a server platform, you can’t beat how cheap the Raspberry Pi is. As such, it’s at the heart of many a home LAN, serving up files as a network attached storage (NAS) device. But the biggest problem with using the Pi in a NAS is that it doesn’t have any onboard hard drive interface, forcing you to use USB. Not only is this much slower, but doesn’t leave you a lot of options for cleanly hooking up your drives.

This 3D printable NAS enclosure designed by [Paul-Louis Ageneau] helps address the issue by integrating two drive bays which can accommodate 2.25 inch laptop hard disk drives and their associated IB-AC6033-U3 USB adapters. The drives simply slide into the “rails” designed into the case without the need for additional hardware. There’s even space in the bottom of the case for a USB hub to connect the drives, and a fan on the top of the case to help keep the whole stack cool. It still isn’t perfect, but it’s compact and doesn’t look half bad.

The design is especially impressive as it doesn’t require any supports, an admirable goal to shoot for whenever designing for 3D printing. As an added bonus, the entire case is designed in OpenSCAD and licensed under the GPL v3; making modification easy if you want to tweak it for your specific purposes.

This certainly isn’t the strongest Raspberry Pi enclosure we’ve ever seen, that title would have to go to the ammo case that does double duty as a media streamer, but looks like it would make a great home for that new 3 B+ you’ve got on order.

Posted in 3d printed, 3d Printer hacks, enclosure, nas, Network Hacks, Raspberry Pi | Leave a comment

Bring Deep Learning Algorithms To Your Security Cameras

AI is quickly revolutionizing the security camera industry. Several manufacturers sell cameras which use deep learning to detect cars, people, and other events. These smart cameras are generally expensive though, compared to their “dumb” counterparts. [Martin] was able to bring these detection features to a standard camera with a Raspberry Pi, and a bit of ingenuity.

[Martin’s] goal was to capture events of interest, such as a person on screen, or a car in the driveway. The data for the events would then be published to an MQTT topic, along with some metadata such as confidence level. OpenCV is generally how these pipelines start, but [Martin’s] camera wouldn’t send RTSP images over TCP the way OpenCV requires, only RTSP over UDP. To solve this, Martin captures the video stream with FFmpeg. The deep learning AI magic is handled by the darkflow library, which is itself based upon Google’s Tensorflow.

Martin tested out his recognition system with some cheap Chinese PTZ cameras, and the processing running on a remote Raspberry Pi. So far the results have been good. The system is able to recognize people, animals, and cars pulling in the driveway.  His code is available on GitHub if you want to give it a spin yourself!

Posted in Computer Hacks, darkflow, opencv, rtsp, security camera | Leave a comment