Some companies use an isolated network or even the complete lack of a network as a security measure to protect from unauthorized access. Working on these systems can be a struggle but it is still possible, and perhaps even more important, to use a proper version control tool like Git.
By design Git works quite happily with no remote repository. You can branch, stage, and commit files just like normal.
In the first part of this series I listed the parts required to build the mechanical assembly for a robotic arm. You might remember my delight is discovering that no instructions were included! Yes, I’m one of those silly people who assemble IKEA furniture and then look at the instructions to see if I did it correctly. (Surely having parts left over just means I have assembled it more efficiently, right…) Realising that most people won’t want to spend an hour staring at a pixelated image of the assembled arm on the amazon product page to determine the best order in which to assemble it I decided to create some instructions.
There’s a few ways you can put these arms together. I opted to copy how the arm was assembled according to the pictures on the amazon product page.
A quick note on fasteners
Before we begin there are 4 types of fasteners used in this robot arm kit. To avoid any confusion in this guide I will refer to them by a number as shown in the image below.
Machine screw #1 is used to attach the metal servo horn to the servo and also to attach the servo horn to the metal parts of the robotic arm. These screws came with the metal servo horns and were not part of the robotic arm kit. Some equivalent screws were included with the arm kit but I decided not to use them as they were shorter.
Bolt and nut #2 are used to connect all the non-moving metal parts together.
Bolt and nut #3 are used with a bearing (not pictured) to connect the 4 main moving joints of the robotic arm.
Bolt and nut #4 are used to attach the body of the servos to the robotic arm.
#1, #2, and #3 all have the same thread which I believe is an M2 thread. #4 appears to have an M4 thread.
Right, with that out of the way let’s get going! Read More
Apparently a quarter life crisis is a real thing. Not wanting to miss out on this phenomenon I decided to build myself a robotic arm. Not the sort of arm that replaces a missing limb, but the sort that are used in factories around the world to pick, place, and construct products.
Unfortunately living in an city quickly shrunk my dream of building a giant robot to a more apartment friendly size. Probably for the best!
I have absolutely no idea what I will use a robotic arm for. I suspect the desire to make one came from watching Simone Giertz and her “Shitty Robots”. These robots are designed to complete a single task, but instead fail spectacularly often resulting is a huge mess.
Since I am mainly interested in electronics and software I opted to buy a kit for the mechanical parts. There are several options out there; searching ebay, amazon, and Alibaba for “robot arm” yields 1000’s of sensible results. Most variants are built around standard hobby servo motors that are typically used in remote control cars and planes. While these motors are not exactly known for their repeatability, smoothness, or accuracy they are very cheap!
I opted for a “Mirocle Aluminium Robot 6 DOF Arm” from amazon which was £22.50. Unfortunately it has subsequently gone out of stock, but searching ebay for “6 DOF robot arm” gives many identical kits.
My kit, like most of the ones I saw, did not come with servos. I ended up buying six super cheap “Tower Pro MG996R” clone servos off ebay for £21.50 delivered. Given the price the servos are actually of reasonable quality, and have metal gears. However, if you are not a cheapskate like me, buy better servos!
The servo horns supplied with the servos were plastic. I believe my robot arm kit was supposed to come with some replacement metal ones, but they weren’t in the box. Instead, I purchased some metal ones off ebay relatively inexpensively.
Now I had everything I needed to build the mechanical assembly of the arm. I was very happy to find that no instructions were included with kit. Figuring it out myself is much more fun 🙂
Click below to read the next post:
Part 1 — Introduction (You are here) Part 2 — Building the Mechanical Assembly
Part 3 — Designing the Electronics System (Pending)
Part 4 — Developing the Microcontroller Software (Pending)
Part 5 — Developing the PC control software (Pending)
Strandbeest are an invention by Dutch artist Theo Jansen. The “creatures” are designed to live on their own on beaches in the Netherlands, taking power only from the wind. They are constructed almost entirely from yellow plastic tubes and scrap materials. Some Strandbeest are even able to detect when they are entering the sea, and switch direction to go back up the beach.
I saw a Strandbeest model on eBay and couldn’t resist buying it and building one. Below are some pictures and videos from the assembly process.
I went to Bletchley Park last week for a fascinating day trip. Bletchley Park was the location where the British code breakers were based during World War II. It was from here that Alan Turing and many other incredibly gifted mathematicians, statisticians, and translators worked tirelessly throughout the war to continuously crack and decrypt the messages sent by the Germans.
During the war the Germans used several variants of an electro-mechanical rotatory cipher machine known as the Enigma machine. The Germans believed the encryption generated by these machine to be unbreakable. Theoretically there were in the order of 1.07 x 10²³ possible combinations for the Wehrmacht (Army) version of the machine. Fortunately (for the Allied forces) a weakness in the encryption method could be exploited and using a clever technique, alongside a custom build electro-mechanical device known as the Bombe, the message could be decrypted.
To learn a bit more about how the Enigma machine worked I decided to make an Enigma Machine Emulator in C. Read More
Since I hardly ever post anything to this website I’ve decided to submit a few projects in a slightly different format. At the moment every time I have a day free to do some electronics the thought of fully documenting the project and posting it on here puts me off!
Instead, from now on, I’m going to do a series of one day builds where I have a singe day (or less) to make a specific project. I’ll use this website like a lab book, documenting my progress as I go along. The notes will be rough but there should be enough detail to follow what I’ve done. I hope someone finds them useful/interesting.
10:45 Research VGA interface and timing specifications
There are 5 main signals for VGA: * 3 Analogue signals for the Red, Blue, and Green pixel intensities. * 2 Digital signals: Horizontal sync and Vertical sync.
H sync and V sync tell the monitor where the horizontal and vertical lines begin and end. See diagram below for details:
11:30 Work out timings for my monitor
The timings of VGA signals depends on the desired resolution and refresh rate.
My monitor has a native resolution of 1680 x 1050 resolution and supports a 60Hz refresh rate. VGA timings can be a bit awkward to calculate so it is often easier just to look them up online.
I used this site which has a large selection of common resolutions.
The horizontal width in pixels = “Front porch” width + “Sync pulse” width + “Back porch” width + monitor width. For my chosen resolution is 104 + 184 + 288 + 1680 = 2256.
The vertical width in pixels is = “Front porch” width + “Sync pulse” width + “Back porch” width + monitor width. For my chosen resolution is 1 + 3 + 33 + 1050 = 1087.
The h_sync line should be normally high, and then pulsed low for 184 pixels to trigger the h_sync. The v_sync line should be normally low, and then pulsed high for 3 pixels to trigger the v_sync.
To get a refresh rate of 60Hz I need a pixel clock of 147.14MHz. This is calculated from: h_width * v_width * refresh rate = 2256 * 1087 * 60 = 147136320Hz Read More
I2C (or I²C) is a synchronous, half-duplex, serial, communication protocol commonly used to communicate between several integrated circuits on a PCB. I2C is often used to interface between a microcontroller and devices such as temperature sensors, accelerometers, and EEPROMs.
The are two different types of I2C devices, master devices and slave devices. The master controls the I2C bus and sends commands to slave devices on the bus. Slave devices respond to commands from the master. Both master and slave devices can transmit and receive data, however only the master device can initiate a communication event. In most situations there is a single master on an I2C bus, while there can be many slave devices. It is possible to have multiple master devices on an I2C bus, however this is not that common and is outside the scope of this article.
I2C communication uses two wires, SDA (Serial data line) and SCL (Serial clock line). I2C devices connect to the bus in parallel as shown in the diagram below.
I2C devices use open drain outputs for both the SDA and SCL lines. This means that each device can either pull the line low, or allow it to float. When in the floating state pull up resistors are used to pull the voltage of the line up to VCC. The reason for using open drain outputs is that it prevents two devices on the bus from trying to force the line to both VCC and GND at the same time, which would cause a short circuit.
The value for the pull up resistors is typically a trade off between the rise time of the signal and the current draw of the bus. A common choice is 4.7kOhms. If the I2C lines are long or there are many devices on the bus the capacitance of the I2C bus can be high. In order to meet signal rise time requirements the pull up resistance can be reduced (Tau = R*C). As a rule of thumb start around 4.7kohms and reduce the resistance gradually if that doesn’t work.
Each I2C device has a 7 bit address meaning there are 127 possible addresses (Although some are reserved for special purposes). The address of each device on the bus must be unique. The address of an I2C device is typically set by the manufacturer. Unfortunately there are tens of thousands of different I2C devices available so many devices have conflicting addresses. To get around this some devices allow several of the address bits to be set by connecting pins on the I2C device to VCC (1) or GND (0). The I2C specification also allows for 10 bit addresses, however these are not as common and are outside the scope of this article. If two devices with conflicting non user settable addresses must be used then either two separate I2C buses are required, or each IC must be enabled only when required via a chip select pin (like in SPI communications).
When the I2C bus is idle both SDA and SCL are HIGH. When a master device wishes to start a communication event it first pulls SDA LOW and then after pulls SCL LOW. This special sequence is known as a start condition and lets all devices on the bus know that the bus is now in use. The stop condition tells all devices that communication is complete and the bus is now free. The stop condition occurs when the master allows the SDA line to go HIGH when the SCL line is already HIGH. The start and stop conditions are shown in the diagram below.
With the exception of the start and stop conditions all other changes of the SDA line occur only when SCL is LOW. Data is clocked into devices on the rising clock edge. The clock (SCL) signal is generated by the master device. Almost all I2C devices support clock speeds up to 100kHz, many support up to 400kHz, and some can go as high as 3.4MHz.
I2C communications transmits data in 8 bit chunks. After the start condition has been set the master device transmits the address of the device it wishes to communicate with. Since the addresses are 7 bits long the address is shifted to the left and the least significant bit it set to either a 0 or 1 depending on if the master device wishes to read (1) or write (0) to the slave device. This is shown in the example below.
After each byte of data is transmitted, the receiving device acknowledges that it received the data and that the communications should continue. The acknowledge takes place on the 9th rising clock edge. The master allows the SDA line to float HIGH. If the slave has successfully received the data it pulls the line LOW, this is known as an ACK. If the slave is not present or is unable to process the data the line is left HIGH, this is known as a NACK (negative/no acknowledge). Read More
I recently purchased a torch from Amazon for a grand total of £2.29 including delivery from China. The torch had very good reviews, one even claiming that the torch would change my life! I was very sceptical about how good the torch would be; with such a low retail price cost the BOM cost would have been pennies.
After waiting 3 weeks the torch finally arrived. The torch appeared to be mechanically well made, however after inserting the battery it became clear that it did not work. Considering the cost this was hardly surprising. I decided to take the torch apart to see how it worked and what was wrong with it.
The torch came apart very easily; the main mechanical components can be seen below.
Inside the torch head the electronics for the torch can be seen. Given the price I was expecting a simple series resistor or just I direct connection to the 1.5V AA battery. Instead an IC was used to drive the LED. The markings on the IC indicate it is a CX2859. A quick search shows that this is likely to be a 3 level PWM dimmer IC. Unfortunately I could not find a datasheet or any more information about the chip.
The soldering on the board wasn’t great, but everything seemed to be connected OK.
Using the continuity tester on a multimeter I identified the torch’s circuit layout. The schematic is shown on the below.
I removed the LED and connected it to a 3V coin cell battery. The LED worked fine, meaning the issue was with the driver circuitry.
With a battery connected I checked the voltages at various points on the circuit board. Unfortunately everything seemed fine indicating that it was likely to be the driver IC that was faulty.
I noticed on the torch’s Amazon page that it would also work with a 3.7V 14500 lithium ion cell. Since I didn’t have one to hand, I tested it at 3.7V using a bench power supply. Unfortunately that didn’t work either.
I will probably just bodge a constant current driver circuit into the torch as I doubt I will be able to source a replacement CX2859 IC. As always, you get what you pay for!
A few friends and I decided it would be a good idea to make a light-up Frisbee so we could continue playing with it after it became dark. The first version featured 8 LEDs located around the edge of the Frisbee. Each LED was connected in parallel via a resistor to a small LiPo battery. This worked well and looked really good in the dark.
I decided to make a second version using a microcontroller so that the LEDs could be flashed in various patterns. Since I had several BLE112 Bluetooth Low Energy (BLE) modules left over from a previous project, I decided to make a Bluetooth controlled flashing Frisbee! Why…? because “Everything is better with Bluetooth” (Sheldon Cooper).
The BLE112 modules include a 8051 microcontroller which can be programmed using a propitiatory scripting language called BGScript. BGScript was created by Bluegiga, the manufactures of the BLE112 modules. BGScript works great for simple applications, so it was perfect for this project.
As part of a previous project I had designed a small PCB to breakout the pins on the BLE112 module to through hole 0.1” headers. The PCB was 1.3” x 1.6” and manufactured by OSH Park. In the interest of hacking the Frisbee together quickly I decided to reuse this PCB as well.