However, now that I have found an excellent development environment and am steadily improving my skills, I am intrigued by what the robot's developer, named Ramin, was able to do. At the time, I was not quite yet back into working with the NXT, and it seemed like it was much too advanced for me to even try to figure out. At, I saw a video of a robotic hand with three joints that was able to imitate another person's hand. I was looking around for some inspiration a few weeks ago and I came upon something that really impressed me.
#ROBOTC PID CONTROL CODE#
My values (especially the kp value) are extremely high due to the fact that the batteries were low.once I replaced the batteries, there was WAY too much overshoot.Īnnotated source code can be found here (4KB) Note: if you want to use my source code and have a working robot, you must use a very similar design and adjust the kp, kd, ki, adj, and scale values to fit your robot and its environment. As you can see from the video below, this controller is highly effective in creating a stable inverted pendulum. For a complete, technical PID tutorial, check out this site. The three error components work like this: kp (proportional) changes proportionally to the error, kd (differential) changes proportionally to the rate of change of error, and ki (integral) changes proportionally to the sum of all previous error values the constant multipliers weight these components based on need. The program uses three error components (kp, kd, and ki), multiplies them by three constants, adds them together to form the PID value, scales the PID value to fit in the motors' power range (-100 to 100), and sets the motor power equal to the scaled PID value. Along with the bigger wheels, as the title says, I also implemented a PID motion control system that solved all my balance problems. He gave an excellent example: it is much easier to balance a golf club on your finger than a pen. I re-re-designed the robot: Dean Hystad informed me on the NXTStep forums of the benefit that a higher center of gravity can give to a balancing robot like NXTSegway. This is the fourth public release of my NXTSegway, and I am quite pleased with the results. If anyone happens to read this, let me know what you think, and I will try to post again soon. I had to do about 30 takes of the video because of this, for when it twists too much or too little, it binds up the cube and jams it later on. Another future improvement will be structural, because at the moment the yellow claw is too wobbly and does not hold the cube steadily enough, resulting in twists != 90 degrees as you can see from the final two twists in the video. I also have not had to code an AI, because there is no color data yet, but I plan on outlining my program using flowcharts, posting it here, and letting my huge fanbase of intellectual giants poke holes in it and offer suggestions (actually Cammy I think you're the only one :-P). As of right now, ARCS has no way of actually reading the cube, but I plan to enable that with either a color sensor or a webcam (I think a webcam would be pretty tight). Note that in the video it is not solving the cube autonomously I gave it the directions and it carried them out. The video below is the product of only 2.5 days of work, so while it isn't perfect, there are plenty of ways I can think of to make it better.
#ROBOTC PID CONTROL HOW TO#
Anyway, after learning how to solve it, I thought that the logical next step would be building a robot that could do it, and the next morning I started to do just that.
#ROBOTC PID CONTROL MANUAL#
This project, which I have named ARCS (Autonomous Rubik's Cube Solver), was sparked over the weekend when I finally learned how to solve a Rubik's Cube, with some help from a solution manual my dad gave me, the same one he used when he was a kid eons ago. It's been a while since my last post, but the posts will be coming more and more frequently now that I have a new project up and running.
0 kommentar(er)
