Tag Archives: Robotics

IMG_20170531_121338

Hexapod navigation (2017)

Part of UNSW Australia coursework for MTRN4110: Robot design. Our team consisted of 4 members and we maintained our code using a Github repository. The first task was to assemble the components on a platform that was to be attached to the provided hexapod. The components included: Depth sensor RGB camera, IMU, on-board computer (LattePanda supporting Win10), Arduino, battery and power management board. The on-board computer was to communicate with a remote laptop running a Matlab client using TCP over Wi-fi. We developed the code in C++ to read sensor data, send it and receive commands over TCP. This allowed us to control the robot remotely and do complex processing on a more powerful machine. The second task was to implement (on the client) localization of the robot using IMU data and triangulation (using the known obstacles and depth camera ranges to them). This involved using different mathematical tools for detecting the obstacles and for example fitting a plane to the floor to account for the current pitch angle of the robot. At this point we could move the robot using movement commands sent from the client GUI. Finally with the provided grid on the floor and randomly allocated obstacles we were to implement a path planning algorithm (we used A*) and make the robot navigate autonomously to the selected location on the client. We had some problems with localization due to poor data quality from the depth sensor camera and our instructor provided us with a laser scanner mounted in the corner of the room. We tried using the data from the laser for improvement of the localization but due to time limitation never implemented it in the final solution. Therefore the robot was able to plan the path and navigate, however not precisely. Share: Twitter Facebook Google+…

IMG_5469

InMoov updated version (2016, left the project)

In my free time from work I have been visiting Wevolver guys’ new office at Fablab London to finalize some parts of the InMoov for the Robots For Good project. We have reprinted the crucial parts with good quality about 60-70% fill and 2.4mm thickness walls. The worm gears were printed with 100% (solid) fill. It took some time, but step by step both arms of the robot came along. I have learnt a few things about 3D print quality, wall thickness, fill and 3D printer tuning (on Ultimakers at least) along the way. Share: Twitter Facebook Google+…

IMG_0517

InMoov Robot (Unbound event version, 2015)

In early November I joined the Robots For Good project started by Wevolver staff. They had an almost fully printed InMoov Robot (designed by Gael Langevin). However it happened so that they needed to have it moving in some way (at least pre-scripted movements) in 2 weeks time for the Unbound tech exhibition event in London. It was their side project as their main work is the Wevolver website and community. I was confident enough by that time to agree on the offer to help them with InMoov. And so it began. I have faced a few challenges. The main one being a close deadline and a few others involved poor quality prints of some essential moving parts such as gearboxes for shoulders. I spent a lot of time filing the gears and reprinting some parts on a handy Ultimaker 2 we had at London Hackspace at the time. I also had to take out almost every single servomotor, take it apart, take out the potentiometers and put it back together. It was required by the InMoov design, but has not been done before. It was needed because the shoulder gearboxes had worm gears and we needed the have those potentiometers to be the feedback of the actual angle the arm has turned, not how much the worm gear has turned. My soldering skills have really improved after this project. Another problem I faced was the fact that gearboxes would have too much friction. Yes, the quality of Ultimaker 2 is fairly good but still the gears would need a lot of filing before they could be used in the gearboxes. After hours of filing and packing the gearboxes with automotive grease – I could see the arms moving. The last bit of the task was to make it possible…

IMG_4123

HSRDP: Steering H-Bridge motor contoller

HSRDP is a Hackspace Robot Development Platform – a robotics group project at London Hackspace. When I first joined London Hackspace me and Pavel Viatkin have noticed it being relatively abandoned in the robotics corner. Later a senior member has informed us that we’re welcome to contribute to the project. Pavel taught me some initial hands-on mechanical and electrical basics that were useful for this project. I’ve tried welding and we’ve mounted the steering motor on the front wheel of HSRDP. Later on I ended up playing around with making an H-bridge motor controller using first simple bipolar junction transistors and later on MOSFET transistors. I had a lot to learn to say the least as I had very little hands on experience with electronics. We had a widely available L298N but it seemed to overheat when controlling the steering motor that we found. The H-bridge I’ve prototyped on a breadboard worked with some tinkering and I would call it a success except that it still overheated. The conclusion was that the steering motor needs a proper PID controller to avoid the constant oscillating around the target point, as that’s what made both motor controllers overheat. Skills improved/learned: arc welding, soldering, H-bridge, transistors, PWM, Arduino, circuit debugging Share: Twitter Facebook Google+…