I know this blog is supposed to be about robots and documenting my robots, but I think I'm starting to like this whole "blogging" aspect and just ranting about my thoughts.
So, without further ado, some thoughts.
(Grendel by John Gardener is an amazing book)
Recently, for both my physics and English class we had to learn about the 4th dimension and beyond (it was almost like I was destined to learn about this stuff). Basically, the fourth dimension is time, and the fifth dimension is the connection of time. Think of the fourth dimension as being events from the 3rd dimension and the fourth dimension is a collection of those events, then the 5th dimension strings those events together. The sixth dimension is even more above the 5th and basically is all the different paths and time-lines from the 5th dimension.
So this basically means that everything that happened and will happen in time, in my and yours, our, time-line, has already happened. We have already finished reading this post and we have already died. Now, as 3rd dimensional creatures and residents we only experience time in the present and we can only recall (to a certain precision) the past. We do not concretely know the future, even though it already happened and exists.
To some, this may be depressing, we may have already failed in whatever present aspirations we had. However, after some pondering I realized that that doesn't matter. So what if it's true that we failed or succeeded in the future? We don't know that, so it doesn't matter to our present selves. We do not know if we live in the time-line of success or failure, but this means all the more that we should live and experience life as best we can. You may have already failed in the future, but that doesn't mean you can't succeed in the present and vice versa.
Perhaps it's because I'm a hopelessly wistful romantic teen who just had some weird feelings with romance (future Roy, you know what I mean even if you don't want to admit it), but this idea is comforting to me.
Yeah, that's it for now, I need some sleep.
Sunday, November 27, 2016
Big Update
Wow, it's been quite a while. Guess I'm not the best at constant updates. Anyway, now I have a whole load of changes to unload from months.
1. arm camera and control are NOT finished. I've found that the time it takes to send data to the arduino through serial is too slow and that the computer vision node is in real time so complications occur where the reaction time is just pathetically slow and no progress towards the object's real location is made.
I'm thinking of changing the nodes from subscribers & publishers into a client and server so I do not have to worry about the computer vision node being in real time while the control node is in 5 seconds in the past.
Perhaps I shall first take the readings from the computer vision node, calculate the movements needed for the arm to try to get the object, then blast all the movement commands at one time, then have the camera check once the arm has finished moving if it grabbed the object (the camera will just see if the majority of its view is filled with green, then it'll know it grabbed the object).
2. The motors are fully operational as seen in this video:
However, there is a twist! This video is outdated for a couple of reasons. After taking this video I tried to fix up the motor driver since its connections were not the most reliable. Unfortunately, my soldering skills are not the best and I ended up overheating the board. Along with that, I also melted the insulation of a wire on the circuit somehow while testing the broken motor driver. I had to spend what little money I had left for another motor driver and fortunately, I was able to solder the connections on that one without too much error.
After that fiasco I decided it was time to screw down the motor driver and change the wiring of the Tiva C Launchpad so it would be right side up (Whoa! Female to Male connectors?!). I also stuck the breadboard in place (I'm hesitating to move everything to a soldered prototyping board, as I like being able to disconnect connections and power easily for testing). When I finish this prototype I'll consider changing the breadboard to a prototyping board.
Some other mechanical changes include: hot-gluing the camera on the arm upright, rolling up wires with zip ties, finding the right size screws for the arm's base connection to Fetch's main body, building a container for the battery to sit in and not shift around, tightening the wheels' connection to the motor axle (darn you tiny hex keys), and finally adding some wooden "struts" to the top of the second layer so the laptop won't crush the wires leading up there.
I also made a small voltage regulator board for the kinect sensor with a NTE966 and 0.33μF and 0.1μF capacitors. Also I modified the "Y" power/usb cord for the kinect so it can use Fetch's battery! Still not sure why the brown wire was the 12V and white was the ground. I thought it was just the darker color wire being ground or just black (ground) & red (power).
I have also soldered the inertia measurement unit (IMU), the MPU 6050, and it's ready for testing!
Here are some pictures of the new and updated Fetch!
I have also gotten gmapping to work for SLAM!!!
The model is the chefbot's model, I'll need to change the dimensions to account for Fetch's arm. I notice gmapping (even with teleop) eats up a lot of processing from my laptop, it gets pretty hot.
TODOs:
test the IMU (MPU 6050)
test the kinect (if the power is reliable)
test the encoders
test the ultrasonic sensor with the tiva c launchpad
don't test Fetch's motors without it being on a platform (I learned the hard way by paying with my fingers' non-crushed bliss)
combine all the code for the sensor testing
figure out a more efficient algorithm for arm control and arm camera nodes
change the dimensions of the virtual model to account for Fetch's arm
test gmapping with physical Fetch and its sensors
1. arm camera and control are NOT finished. I've found that the time it takes to send data to the arduino through serial is too slow and that the computer vision node is in real time so complications occur where the reaction time is just pathetically slow and no progress towards the object's real location is made.
I'm thinking of changing the nodes from subscribers & publishers into a client and server so I do not have to worry about the computer vision node being in real time while the control node is in 5 seconds in the past.
Perhaps I shall first take the readings from the computer vision node, calculate the movements needed for the arm to try to get the object, then blast all the movement commands at one time, then have the camera check once the arm has finished moving if it grabbed the object (the camera will just see if the majority of its view is filled with green, then it'll know it grabbed the object).
2. The motors are fully operational as seen in this video:
After that fiasco I decided it was time to screw down the motor driver and change the wiring of the Tiva C Launchpad so it would be right side up (Whoa! Female to Male connectors?!). I also stuck the breadboard in place (I'm hesitating to move everything to a soldered prototyping board, as I like being able to disconnect connections and power easily for testing). When I finish this prototype I'll consider changing the breadboard to a prototyping board.
Some other mechanical changes include: hot-gluing the camera on the arm upright, rolling up wires with zip ties, finding the right size screws for the arm's base connection to Fetch's main body, building a container for the battery to sit in and not shift around, tightening the wheels' connection to the motor axle (darn you tiny hex keys), and finally adding some wooden "struts" to the top of the second layer so the laptop won't crush the wires leading up there.
I also made a small voltage regulator board for the kinect sensor with a NTE966 and 0.33μF and 0.1μF capacitors. Also I modified the "Y" power/usb cord for the kinect so it can use Fetch's battery! Still not sure why the brown wire was the 12V and white was the ground. I thought it was just the darker color wire being ground or just black (ground) & red (power).
I have also soldered the inertia measurement unit (IMU), the MPU 6050, and it's ready for testing!
Here are some pictures of the new and updated Fetch!
I have also gotten gmapping to work for SLAM!!!
The model is the chefbot's model, I'll need to change the dimensions to account for Fetch's arm. I notice gmapping (even with teleop) eats up a lot of processing from my laptop, it gets pretty hot.
TODOs:
test the IMU (MPU 6050)
test the kinect (if the power is reliable)
test the encoders
test the ultrasonic sensor with the tiva c launchpad
don't test Fetch's motors without it being on a platform (I learned the hard way by paying with my fingers' non-crushed bliss)
combine all the code for the sensor testing
figure out a more efficient algorithm for arm control and arm camera nodes
change the dimensions of the virtual model to account for Fetch's arm
test gmapping with physical Fetch and its sensors
Saturday, October 15, 2016
Finished arm_camera_node.cpp and arm_control_node.cpp
Update!
Finished the arm_camera_node.cpp and arm_control_node.cpp
The code can be seen here: https://github.com/RX-00/Fetch
Some problems with the code itself is that the transmission and actual movement of the sevos are rather slow probably due to sending info from the cpp program to the arduino over serial. However, this is not a critical problem as fetch just needs to know how close the target object is based on the camera and distance sensor to know when to grab the target object.
Next steps are to work on are:
-creating ultra_sonic_distance_node.cpp
-getting SLAM to work
-fixing the motors & finish the electronics
-work on the kinect sensor adaption
Here's a pic of the camera code in action, this one is a bit older than this update so now the noise is even more cleaned up!
Finished the arm_camera_node.cpp and arm_control_node.cpp
The code can be seen here: https://github.com/RX-00/Fetch
Some problems with the code itself is that the transmission and actual movement of the sevos are rather slow probably due to sending info from the cpp program to the arduino over serial. However, this is not a critical problem as fetch just needs to know how close the target object is based on the camera and distance sensor to know when to grab the target object.
Next steps are to work on are:
-creating ultra_sonic_distance_node.cpp
-getting SLAM to work
-fixing the motors & finish the electronics
-work on the kinect sensor adaption
Here's a pic of the camera code in action, this one is a bit older than this update so now the noise is even more cleaned up!
Tuesday, September 6, 2016
Late Update (Back though!)
Been gone for a while, mainly due to summer AP U.S. History work. But
now that I finished that up and started school I have kind of more time
to work on my own projects!
However, even while focusing on summer work during the small breaks and random short, but sweet free time I had I worked on Fetch.
I've wrote two nodes for controlling the arm and the camera on the arm.
Along with that, I've also planned out the ROS framework for Fetch and a flowchart for its behavior.
There is a second flowchart for more advanced behavior after the initial programs are finished, perhaps it could even be used for a Fetch 2.0.
The next steps are to finally get the motors working and then move onto SLAM (Simultaneous localization and mapping) and working out how to get Fetch to objectively drive around its mapped environment looking for a target object.
However, even while focusing on summer work during the small breaks and random short, but sweet free time I had I worked on Fetch.
I've wrote two nodes for controlling the arm and the camera on the arm.
Along with that, I've also planned out the ROS framework for Fetch and a flowchart for its behavior.
There is a second flowchart for more advanced behavior after the initial programs are finished, perhaps it could even be used for a Fetch 2.0.
The next steps are to finally get the motors working and then move onto SLAM (Simultaneous localization and mapping) and working out how to get Fetch to objectively drive around its mapped environment looking for a target object.
Saturday, August 6, 2016
Arm + Motor Troubles
So! For the past couple of days I got the arm to slowly pick up objects, the video for it is somewhere stuck in mail server hell, but I do have the program. Among other things is my trouble/frustration with my motor circuit (shown above). I contacted the creator of the Chefbot, which is what Fetch's motor and frame is based off of. Hopefully he (Lentin Joseph) has some insightful suggestions! I'll eventually post the video of the arm in use...
Here's a screen-shot of the code for the arm + ultrasonic sensor (the arm grabs stuff based on the distance from the ultrasonic sensor)
I'm especially pleased with my function for slowing down the servos when they move, the function works perfectly! I've seen some other more complicated solutions, but I feel as if mine is quite simple and effective.
Basically it's just this:
For(int servoAngle = 0; servoAngle < servoPosition; servoAngle++){
servo.write(servoAngle);
break;
}
Here's a screen-shot of the code for the arm + ultrasonic sensor (the arm grabs stuff based on the distance from the ultrasonic sensor)
I'm especially pleased with my function for slowing down the servos when they move, the function works perfectly! I've seen some other more complicated solutions, but I feel as if mine is quite simple and effective.
Basically it's just this:
For(int servoAngle = 0; servoAngle < servoPosition; servoAngle++){
servo.write(servoAngle);
break;
}
Monday, August 1, 2016
Late Night Progress Update
Due to my long hours at work I don't have much time every night and staying up past midnight doesn't result in the best quality progress...
But I digress, today I tested out the ultrasonic and its readings with the Arduino IDE, it works fine, except for one big problem. The pom pom seems to bounce off/disperses the sound waves so the readings return -1, nothing is detected. In order to fix this I simply made a new target out of green card-stock, a 4 cm by 4 cm by 4 cm cube.
The arm itself is working fine after testing it out with an old program of mine that allows a user to manually control the arm's servo with keyboard inputs. I need to figure out the right sequence for the shoulder and elbow to move in order for the claw to be position in front of the target cube to grab it without hitting the target cube while the arm lines itself up.
I found out a crude hack for connecting the lipo battery to the breadboard with some simple jumper wires. However, I'm still waiting for a proper charger for the battery to arrive from shipping. I tested if the buck converter was still outputting 5 V with my multimeter since the lipo battery pumps out around 15 V (out of the box) and the buck converter is returning a close 4.9 V.
That's about it for tonight! I'll post some pictures of the new target object with the arm and the battery in the morning.
But I digress, today I tested out the ultrasonic and its readings with the Arduino IDE, it works fine, except for one big problem. The pom pom seems to bounce off/disperses the sound waves so the readings return -1, nothing is detected. In order to fix this I simply made a new target out of green card-stock, a 4 cm by 4 cm by 4 cm cube.
The arm itself is working fine after testing it out with an old program of mine that allows a user to manually control the arm's servo with keyboard inputs. I need to figure out the right sequence for the shoulder and elbow to move in order for the claw to be position in front of the target cube to grab it without hitting the target cube while the arm lines itself up.
I found out a crude hack for connecting the lipo battery to the breadboard with some simple jumper wires. However, I'm still waiting for a proper charger for the battery to arrive from shipping. I tested if the buck converter was still outputting 5 V with my multimeter since the lipo battery pumps out around 15 V (out of the box) and the buck converter is returning a close 4.9 V.
That's about it for tonight! I'll post some pictures of the new target object with the arm and the battery in the morning.
Sunday, July 31, 2016
Programming
So here's the code I written so far for Fetch. On the left and upper right is the code for driving the motors around with the Tiva C Launchpad. The bottom right is the code for the Ultra Sonic Sensor and the arm for the Arduino Mega, though both controllers use .ino files.
I reveal here that I use Linux *gasp*. I originally started using Linux a while back in order to use and learn ROS (Robot Operating System) by myself, and ever since then I've never looked back. Though I do dual boot with Windows 10 just in case.
Fetch will be using ROS' amazing framework to function, luckily I've had experience with it in the past with either work or my own self learning. Fetch will also be implementing live video processing. Fortunately, I love C++ (and C too!) and use OpenCV for work and my own personal shenanigans on a daily basis.
I also reveal here that I use Emacs, er rather Spacemacs, a modified version of Emacs! (Sorry Vim users, but Emacs truly is the way to go). In the past I used various other text editors or sometimes IDEs. This continued until an older friend of mine introduced me the wonders of Emacs. Took a solid week during an in-school break to fully master it, but that learning curve was truly worth it! Now I can't live without emacs on my side.
relevant xkcd:
Fetch Itself
So here's what Fetch looks like with it's frame all put together, took around a week to fully finish building the frame and now I'm working on getting the circuits to actually work with my code after soldering all the components together. The kinect sensor on top will be Fetch's main sensor for mapping and navigation. I haven't decided what computer I want to use as the brain for Fetch. At first I was planning on using my nice ol' thinkpad, but that only has two USB A ports when I need 2 for each micro-controller (Arduino Mega and Tiva C Launchpad), 1 for the Kinect Sensor, and one for the camera on Fetch's arm. And getting a USB hub may not work as each controller/sensor needs its own dedicated port either for serial or for data, but I'll have to see.
Arm + Ultrasonic Sensor
Here's the Open Source MeArm that I modified slightly from its joints and claw for Fetch. The camera is simply a web camera that I took apart and modified to fit inside a quick little plastic case I put together. It's meant to aid in Fetch's object tracking. Underneath it is an ultrasonic sensor that is meant for Fetch's navigation and obstacle avoidance along with aiding the Fetch's obtaining of target objects.
Circuits
So here's the current jungle of a circuit that I made for Fetch, it consists of four 5 V to 3.3 V converters, a 12 V to 5 V Buck Converter, a motor driver, and finally a Tiva C Launchpad.
Bottom Base
So here's the bottom base of Fetch.
Starting from left to right and top to bottom; the Dual VNH2SP30 Motor Driver Carrier MD03A, TivaC TM4C123GXL Launchpad, and a breadboard with 3.3 V, 5.0 V, to 12.0 V. The top of the breadboard includes four Logic Level Converter Bi-Directional Module 5V to 3.3V, and a DC Buck Converter for 12 V to 5 V. The battery case is simply 12 V from eight 1.5 V AA batteries, which is a stand in for the Turnigy LiPo Battery I'm going to use. Finally there's an Arduino Mega with a motor shield on top, then there is the slightly modified open source MeArm with a web camera module that I took apart and modified sitting on top of the claw.
Starting from left to right and top to bottom; the Dual VNH2SP30 Motor Driver Carrier MD03A, TivaC TM4C123GXL Launchpad, and a breadboard with 3.3 V, 5.0 V, to 12.0 V. The top of the breadboard includes four Logic Level Converter Bi-Directional Module 5V to 3.3V, and a DC Buck Converter for 12 V to 5 V. The battery case is simply 12 V from eight 1.5 V AA batteries, which is a stand in for the Turnigy LiPo Battery I'm going to use. Finally there's an Arduino Mega with a motor shield on top, then there is the slightly modified open source MeArm with a web camera module that I took apart and modified sitting on top of the claw.
Underneath the Bottom Base
These motors are 131:1 Metal Gearmotor 37Dx73L mm with 64 CPR Encoder.
They should be enough to carry the frame of Fetch along with the arm,
controllers, laptop, kinect sensor, and electronics. The wheels are polulu 90mm black wheels and while they are not in the shot there are also a couple of casters from Lowe's to make sure Fetch stays upright.
Hello, World
I heard that it's a good idea to document my progress on my projects for future me and future people to take a look at. So, that's the exact function of this blog. As of the starting of this blog I, Roy Xing, am a rising junior in High School. Unfortunately my previous self ventures have already been completed and scrapped for future projects (as of starting this I'm still a lowly high school student without proper funding haha).
Here I'm going start with publishing the parts and progress of a particular robot that I'm working on, Fetch. As the name implies the robot is meant to fetch objects. The frame of the robot is inspired and modified based off of the Chefbot made by Lentin Joseph. The entire robot is scratch built as I firstly didn't have the money for a Create or Kobuki and there's just something about building your own frame that's so satisfying.
The Goal: Fetch will be able to autonomously map out its room with a depth sensor (an Xbox 360 Kinect Sensor) and navigate around its environment to locate and obtain a particular object (a green pom pom for example).
How: By me building the robot
Why: This is a tricky part to answer with in-depth insight. Am I doing it for school? No. Am I doing it for work? No. Am I doing it to impress others? No.
If I had to sum it up quickly my answer would simply be, because I want to. Now I know that isn't much of a satisfying answer, but if I went more in-depth it might get all feelsy and sappy peering into the past of a probably angsty 16 year old who still hasn't been able to get into a nice relationship.
However, there is a feeling of enjoyment and devotion I have towards creating things. Starting from making papercrafts as a child, to moving onto battlebots as a middle schooler, and now creating full autonomous robots as a high schooler there has always been a feeling. A feeling of accomplishment, struggle, enjoyment, an intangible sense of more. I want to create.
Welp, that got sappy at the end, to be expected of kid who's still a teen. But yeah.
TL;DR: This blog is about the on-going documentation and progress of a robot named Fetch.
Here I'm going start with publishing the parts and progress of a particular robot that I'm working on, Fetch. As the name implies the robot is meant to fetch objects. The frame of the robot is inspired and modified based off of the Chefbot made by Lentin Joseph. The entire robot is scratch built as I firstly didn't have the money for a Create or Kobuki and there's just something about building your own frame that's so satisfying.
The Goal: Fetch will be able to autonomously map out its room with a depth sensor (an Xbox 360 Kinect Sensor) and navigate around its environment to locate and obtain a particular object (a green pom pom for example).
How: By me building the robot
Why: This is a tricky part to answer with in-depth insight. Am I doing it for school? No. Am I doing it for work? No. Am I doing it to impress others? No.
If I had to sum it up quickly my answer would simply be, because I want to. Now I know that isn't much of a satisfying answer, but if I went more in-depth it might get all feelsy and sappy peering into the past of a probably angsty 16 year old who still hasn't been able to get into a nice relationship.
However, there is a feeling of enjoyment and devotion I have towards creating things. Starting from making papercrafts as a child, to moving onto battlebots as a middle schooler, and now creating full autonomous robots as a high schooler there has always been a feeling. A feeling of accomplishment, struggle, enjoyment, an intangible sense of more. I want to create.
Welp, that got sappy at the end, to be expected of kid who's still a teen. But yeah.
TL;DR: This blog is about the on-going documentation and progress of a robot named Fetch.
Subscribe to:
Posts (Atom)









