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!!!
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
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)
Basically it's just this:
For(int servoAngle = 0; servoAngle < servoPosition; servoAngle++){
servo.write(servoAngle);
break;
}
Monday, August 1, 2016
Late Night Progress Update
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:
Subscribe to:
Posts (Atom)