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
Subscribe to:
Posts (Atom)