Upright Rover is a self-balancing robot which was designed by SainSmart. They really made it simple. As you can see, there are only 8 wires on the robot and 8 wires on the controller. So let's find out how it works!


3x Potentiometer

2x UNO R3

2x USB Cable

2x Sensor Shield

2x 24L01

2x Joystick

2x Gear Motor

2x Wheel

2x Motor bracket

2x Coupling

1x T-Plug

1x 9V Battery Snap

1x MPU6050

1x L298N

1x Balancing Robot Platform

1x Wireless Remote Controller Platform

1x Box &wires & connectors

You can find the kits on this website.

Step 1: Opening Box and Soldering

There are so many boards!

Following the instruction on the website, we may solder the motors first. And it says that wires and capacitors can be connected to any electrode, so just do it. And about the T-plug, it need to be soldered as shown in the diagram. We should pay more attention to the T-plug or we will damage the motor drive controller board.

Step 2: The Bottom of the Robot

Assembling the bottom is easy. The expanded diagrams on the website is pretty cool and helpful. Just remember one thing, assembling the motor bracket before you put the motor on it.

Step 3: The Middle and the Top of the Robot

No difficulty.

Step 4: Wiring and Connecting of the Robot

I copied it from the website.

Positive electrode -> VCC

Negative electrode -> GND


5V -> 5V


IN1 -> D3

IN2 -> D4

IN3 -> D5

IN4 -> D6

ENA -> D9

ENB -> D10



Potentiometer1 -> A0

Potentiometer2 -> A2


As not everyone solders the wires in the same way, if the wheels turn in the wrong direction swap the D3 and the D4 or the D5 and the D6;After adjusting the robot so that it can stand up, try to control it with the remote controller. If it can go forward and go back normally but cannot turn, please swap D9 and D10.


If the potentiometers can not stick on the board tightly, you can solder the pins with a little bit solder wire.

Step 5: The Bottom of the Remote Controller

Screws and shims are needed for each tapped hole.

Step 6: The Middle of the Remote Controller

No difficulty but a pity. You can only tight two of the screws which were designed for the UNO R3. Because the other two of the tapped holes on the UNO R3 are too close to the components on it.

Step 7: Wiring and Connecting of the Remote Controller

Space between the four pillars is for the 9V battery.

Step 8: The Top of the Remote Controller

Step 9: Finish!

Assembling only takes me an hour, but my battery is still on shipping. So let's watch the tutorial video first!

<p>Just made V2 of this kit (https://www.sainsmart.com/sainsmart-balancing-robo... Had a lot of fun, but be prepared for some trouble since the manuals are all wrong and made for different boards. After some tweaking it works as expected except I have not gotten the LCD display to work yet</p><p>Key lessons learned (V2 of the kit)</p><p>- Do not trust any pictures from Sainsmart on the wiring. You need to check each wire yourself if it connects to the right thing</p><p>- Text descripton of wiring connections above in this instructable is correct for the robot itself. But the position of the wires on the boards is different since boards are not the same as the pictures. See my pictures below for help</p><p>- For me it was NOT enough to add solder to the pins of the 3 blue pots (legs are too thin). If felt like they fitted but there was no connection. Check the values in the serial monitor. If they do not change when turning screw you have a problem. I ended up soldering proper logs on the blue pots and then they started working.</p><p> - The holes in the top-plastic plate of the robot does not fit the Arduino board at all (only one screw has right position). This means high risk of shorting stuff if it slides when the hole contraption topples over. I drilled two new holes in plastic top-plate and now boards stay put</p><p>- For correct wiring of the Remote use manual from V3 of the robot: <a href="https://s3-ap-northeast-1.amazonaws.com/sain-amzn/20/20-011-405/20-011-405-manual.zip" rel="nofollow">https://s3-ap-northeast-1.amazonaws.com/sain-amzn/...</a> </p><p>- The code in this file &quot;SainSmart Instabots Upright Rover V2.zip&quot; (Sainsmart V2 product page) is not perfect but should get the robot going. Look in video of this instructable above for adjusting the 3 pots and choose the right values</p><p>For testing the robot</p><p>- Start without remote until robot is fully working and balances</p><p>- It will drift a bit on its own and sometimes fall over. This is due to code sample is trusting that angle=0 means exactly upright. This is not always true</p><p>- you can fix that yourself with some ongoing dynamic offset calculations but out of the box the robot should kinda balance most of the time</p><p>Despite the somewhat iffy manual and holes being in the wrong place, I had a lot of fun building this, so for me it was great value for money</p>
<p>Sorry for posting it here, but there was an instructable about the 6dof+remote combo for sainsmart that has been taken down and im looking for the working code like crazy. If anyone made the project please contact me cause all the code sainsmart provided didnt work properly.</p>
<p>where is the code !??</p>
<p>Regarding the software code that is provided by sainsmart for our balance bots - need to be aware that the 'sampling time' had been set to 0.08. I decided to choose 0.001, which I assume to have units of seconds. As mentioned in a previous post, the &quot;</p><p>lastTime&quot; parameter doesn't appear to be initialised. So the intialisation should be something like: </p><p>unsigned long lastTime = 0;</p><p>And it also appears that the &quot;lastTime&quot; parameter is probably the same as &quot;preTime&quot;. So the part that says:</p><p>float dt = (now - preTime) / 1000.0;<br> preTime = now;</p><p>Could be changed to this:</p><p>float dt = (now - lastTime) / 1000.0;<br> // preTime = now; // (remove this line, preTime = now;)</p><p>Also notice that the units of 'dt' is in seconds. But the line that says:</p><p>timeChange = (now - lastTime);</p><p>has units of milliseconds.</p><p>And the line that says: </p><p>if(timeChange &gt;= SampleTime){</p><p>appears to be comparing 'timeChange' (which has milliseconds units) with 'SampleTime' (which has units of seconds). So something appears to be messed up here.</p><p>Next, the lines:</p><p>Input = f_angle;<br> error = Input;<br> </p><p>should be changed to:</p><p>Input = 0;</p><p>error = Input - f_angle;</p><p>The next part is really weird..... the part that says:</p><p>errSum += error * timeChange;</p><p>It's weird because 'error' has units of degrees, while 'timeChange' has units of milliseconds. So the units of 'errSum' appear to be in units of (degrees x milliseconds).</p><p>Finally, as mentioned in a previous post, if you want to use a potentiometer for setting Ki, then the line:</p><p>//ki = analogRead(A3)*0.001;</p><p>needs to be changed to:</p><p>ki = analogRead(A1)*0.001; //ie. the analog pin should be A1, not A3.</p>
<p><a href="https://www.instructables.com/member/KennyL15" rel="nofollow">KennyL15<br></a>Any chance you could post your whole modified code for us to see what you have done?</p>
<p><strong>I purchased the SainSmart InstaBots Upright Rover Kit Pro, and have had numerous issues with over 20 useless email exchanges with them, with no result. Still no working product.</strong></p><p><strong>The first thing I noticed when unpacking was the terrible quality of the boards, socket were not aligned the connector pins usually 90 degrees to the board were at all different angles, some about 80 degree. On first go it was impossible to get the Mega expansion board to line up with the Mega board. I had to get long nose pliers and adjust all the pins, some off by10 degree. After about 30 minutes the 2 boards could go together. Repeated process for the UNO expansion board. Immediate impressions, this stuff is junk.</strong></p><p><strong>After fully assembling the kit neither the remote nor the Rover worked. So started debugging, pulled it all apart.</strong></p><p><strong>First I could not program the remote UNO. I eventually discovered that the expansion shield when connected to the UNO, </strong><strong>stops the UNO USB port working ? I downloaded the program without the shield on. I tested the expansion board on a Funtronics UNO and the same issue, the usb port stopped working.</strong></p><p><strong>Issue 1: So the UNO expansion shield is faulty. I replaced the SainSmart InstaBots SS-SBR-2.0 Sensor Shield with another brand I had at hand. </strong></p><p><strong>so down $6.11.</strong></p><p><strong>Next once the program was downloaded the LCD screen was garbled, junk characters. I started to try different libraries </strong><strong>and eventually found one that worked. The code and library provided does not work, as this LCD comes from various</strong><strong> manufacturers, this was not a Sainsmart board provided.</strong></p><p><strong>Issue 2: LCD library and code not for the board provided. </strong></p><p><strong>Next the Rover. I had connected an 11V external supply and the motors did not work. I traced through the circuit and found the regulator </strong><strong>was only outputting 2 Volts. Having circuit diagrams for this boards would help been a great help and maybe I could have repaired it. But no circuit diagrams on their site, pathetic. </strong><strong>The absence of SainSmart documentation is unbelievable. Compare this to other reputable providers such as Funtronics. </strong><strong>I had a Duinotech brand L298 board and got that going, just to check the code and connections, all OK, motors work.</strong></p><p><strong>Issue 3: The SainSmart Protoshield Shield Mega expansion board is faulty. so down $11.99.</strong></p><p><strong>I Expected 1 hour work to get this going and now I have nothing. Only due to a very poor quality kit. With over 30 years of electronics this poor quality is unbelievable. A series of emails to their support provided absolutely ridiculous and laughable advice.</strong></p><p><strong>Finally they agreed to replace the fully parts only if i returned the two faulty boards to China. Given I have spent over days debugging and testing their poor quality parts I find this ridiculous. It will cost me more than the kit itself to package the goods, take to post office, take time off work and then send. Other reputable companies, e.g. Funtronics etc just replace goods without waiting for returns.</strong></p><p><strong>I also cannot believe that Sainsmart do not provide circuit diagrams for any of there products making them mostly useless. As a result I am going to buy another brand proto boards and just make up the plugs and motor driver. At least I then know the circuit for future expansion.</strong></p><p><strong>So now trying to get my money back. My advice is not to buy this kit or any products from Sainsmart as the chances they are faulty are high. I just cannot believe 2 items faulty.</strong></p><p><strong>The customer service is a joke, I never once got any technical help from them. USELESS !! Now their support has gone totally silent on me.</strong></p><p><strong>I really empathised with the story below that had the regulator fall off the board in the package. This sums up the quality on their products.</strong></p>
<p>Amigo comprou o Kit Pro tamb&eacute;m, eu estou tendo o mesmo problema, mas ele n&atilde;o sabe resolver. Voc&ecirc; poderia me passar o programa de e-mail e visualizar a biblioteca? Agrade&ccedil;o antecipadamente.</p><p>werdn@msn.com</p>
<p>Forgot to mention that while trying to get the Meg shield on the board I saw that the motor plug pins short onto the top of Mega USB connector. So I filed them down and covered with insulator. I guess many people would get caught with this and short circuit the power. Some thing they don't bother fixing or telling poeple about.</p>
<p>Hello everyone! I quickly mounted version 2.0 robot with three trimmers, to be clear, I have uploaded the files on the robot and on the joystick, all right up there. the problem is that the robot is uncontrollable, the engines still running and I can not keep him straight in the self-balancing. I read here in the forum that the downloaded file Sainsmart there are mistakes, if someone can kindly post the files and if you can eliminate the three trimmers, and because when the robot is in the horizontal position, the controller remains in wait? Thank you in advance and I send you my greetings.!</p>
<p>Hi, I assemble this kit buying the parts and building the chassis. So far so good, except that the link between 24L01 constantly lost and recovered, making it impossible to maneuver the robot. I still have no definitive cause, but may electromagnetic interference generated from the engines, is damaging the link.</p><p>Anyone have any experience with this fault. It is able to solve this by installing capacitors between the motor terminals? Any ideas?</p>
<p>I am very grateful for the help I received thus far, but I ran into one more problem. The remote came with a LCD display, and I do not have a clue how to wire this in. Could you please help me with this?</p>
<p>In the pdf manual.... </p><p><a href="https://s3-ap-northeast-1.amazonaws.com/sain-amzn/20/20-011-405/20-011-405-manual.zip" rel="nofollow">https://s3-ap-northeast-1.amazonaws.com/sain-amzn/...</a></p><p>Photo 'D' shows you the back of the LCD panel, and shows where to connect the wires to the 'shield'.</p>
<p>hi nice project man i buy it and it's really nice , and i have some questions could you please help me</p>
<p>The instructions say nothing about the robot's battery. What type of battery do you recommend?</p>
<p>Close to 12V DC battery is recommended. I chose to go with a </p><p>&quot;Fire Bull 11.1V 3300mAh 25C 3S Lipo&quot;. But I seriously recommend using a safety Lipo bag for both charging and storing these Lipo batteries. They have high energy in a small case. So if anything fails inside them, they're known to burn down houses etc. If you don't want to go down the Lipo path, then could just make up a battery Nimh battery pack that gets you to about 12 V DC.</p>
<p>Thanks. I got the battery you recommended, LiPo bag and a charger ordered.</p>
<p>Most welcome Stuart. Have fun with the bot. These things are definitely great to play and tinker with.</p><p>Kenny</p>
<p>The sensor shields that came with my Instabot are different from those shown though they are still made by SainSmart. The photographs of the wiring in the remote control are poor so I can not read what wires go where on my shield. Could somebody let me know in words how to wire this similar to the way it is stated for the robot wiring?</p><p>Thank you</p><p>Stuart</p>
<p>True. The factory instructions could certainly be polished up a bit. Anyway, for the left joystick, you have GND, +5V, Vrx, Vry, and some other pin that won't be used. Those pins can then be connected (using wires) to G, V, A1 and A0 (in that order) on the shield. G stands for GND. V stands for supply voltage, and A1 and A2 will be the analog inputs.</p><p>The right-hand joystick will have the same pin format. Connect them to G, V, A3 and A2.</p>
<p>Thank you very much</p>
<p>Is this the proper place to discuss the Upright Rover Kit Pro Updated with the Upright Rover 3.1 software?</p>
<p>I think this instructable is based on V2 and below. I got a V3, but haven't assembled it yet. But I reckon there will be differences - since V3 has some wheel encoders added.<br> </p>
<p>Thanks for the reply. It appeared to be only about the V2. I have 2 V3's and they are both partially working. I found some bugs in the software and wanted to pass them along.</p><p>I am still working on the Gain and PID settings. I occasionally see oscillations near upright.</p><p>One of my units had a defective MPU-6050 board. I ordered a new one to replace it and that solved the problem.</p>
<p>Most welcome! Thanks for the heads-up about some issues in their code. <br>Was surprised to see that they packaged their software by bundling the <br>Arduino Sketch 1.6.5 r2 in there. I wonder if that's even legal. Plus their software download is like 122 MB!!</p>
<p>Just want to add that - in the stock software code provided by sainsmart - the &quot;if&quot; statement, ie. &quot;if(timeChange &gt;= SampleTime)&quot; might as well not even be there. This is because 'timeChange' is in units of milliseconds, while 'SampleTime' is in units of seconds..... so timeChange will be a huge value in comparison to 'SampleTime'. This means that the 'if' condition will always turn out to be true, so might as well remove that 'if' statement. This brings about a very interesting thing. If the value K is set to 1, then the stock code actually works quite well. It works nicely, but probably not in the way that the author intended - especially since the units of timeChange and SampleTime are not even the same. This sort of indicates that the author produced a code that actually works, but perhaps not realising 'how it works'. It appears that the &quot;if(timeChange &gt;= SampleTime)&quot; condition is going to run every single time (as already explained). This would mean that the time steps will actually be much smaller than 'SampleTime' (due to the coding mistake). Therefore, 'dt' is going to be tiny. And, if assuming that the initial value of 'f_angle' is zero, then the equation:<br><br>f_angle = A * (f_angle + omega * dt) + (1 - A) * r_angle;<br><br>will actually reduce to:<br><br>f_angle = (1 - A) * r_angle;<br><br>And if K = 1, and if SampleTime is chosen to be 0.001 seconds (which is what I chose), then the equation can be further reduced to approximately:<br><br>f_angle = f_angle + 0.001*r_angle;<br><br>But since there is a coding error in the code, where the author sometimes forgot to convert to units of seconds, the choice of K = 1 and SampleTime = 0.001 has the effect of compensating for the coding error (milliseconds versus seconds). This means that the author's value for 'error' and 'errSum' are larger than they should be by a factor of 1000. And 'dErr' is smaller than what it should be by a factor of 1000. However, it seems that such 'coding mistakes' in the values can be compensated for by setting suitable values for Kp, Ki, and Kd.</p>
<p>Hi all, I have the V1 of this robot and have assembled it but cannot get the KP, KD, and KI values right to make it balance. Does anyone have any advice on what they should be(e.g. what affects what they are) or how long it normally takes to get the right ones(I have spent an hour already). </p><p>Thanks</p><p>Richard</p>
<p>Make sure to keep the serial baud rate set to 115200 baud. Because even if you're not using wireless communications (for the moment), then setting a lower baud rate actually slows down the arduino system, and things will tend to be uncontrollable. Setting PID values usually shouldn't take long. Start with zero values for all 3 parameters. Then increase Kp until you get fairly zippy activity. But don't overdo it. Then increase Kd until some nice corrective control behaviour is achieved. Only use very small values of Ki.</p><p>But before you do all those adjustments, you need to make sure that the motor voltage offsets are set to some suitable values, so that the motors will at least move when a control voltage is applied to them. That's to overcome 'deadzone' effects. Also, some calibration should also be done for the angle measurements, which is why they include an angle offset for accounting for fixed error in the two-axis angle measurement method used in the software.</p>
<p>Hi, I did what you said(zeroing all the values and then increasing the Kp value) but I could not fairly zippy activity where it was even sort of balancing, it seemed to be able to balance itself when it was going forwards but when it started to fall backwards its motors would would go extremely fast and then it would just fall over.</p><p>I calibrated the MPU6050, but I am unsure how to find the correct values for the motor voltage offsets the motors at there default value the motors move when the robot starts to fall so I am unsure what I am looking for when I change their values</p><p>Thanks</p><p>Richard</p>
<p>For the time being, you could probably just leave the motor offsets as-is, such as '20' for each motor. As for zipping too fast, I just have all parameters at zero, then I use the screw driver to wind up the Kp value until the wheels just begin to turn (while manually holding the bot above the ground and having the bot tilted), then I put the bot on the floor, and gradually increase Kp until the bot tries to balance, then will just add a tad more Kp to get a bit more response from the motors.<br><br>A good Kp setting will certainly allow the robot to balance by itself - but with a wobbling behaviour. It will still balance and not topple over in any case. If your bot isn't balancing in one direction, then it'll be necessary to see if all your MPU6050 sensor readings are giving out sensible values. If they are good, then the issue will be in the other hardware and/or software.<br><br>The software that comes with the sainsmart bot is pretty good. Although, I do notice that who-ever wrote it was a bit sloppy by not initialising &quot;lastTime&quot;. This is referring to the line of code. &quot;lastTime&quot; is used in the code, but is never initialised to say &quot;0&quot; or anything. It probably doesn't matter, but I'm thinking that if they're going to introduce code to everybody, then they should get it right first.<br><br>unsigned long lastTime;<br><br>Also, in their code, they commented out the line:<br><br>//ki = analogRead(A3)*0.001<br><br>.... but, if somebody wanted to make ki settable with a potentiometer, then the &quot;A3&quot; variable should actually be &quot;A1&quot;. So that's pretty sloppy as well.<br><br>For testing, what you'll need to do is to make sure that your 'f_angle' value is around 0 degrees when you hold the bot roughly vertically in your hand (off the ground). If you tilt the bot slightly in a +ve degree angle, then the wheels should start spinning one way, and when you gradually make the bot go back to a vertical position, then the wheels should slow down again, and if you tilt the other direction, then the wheels should spin in the opposite direction. If it does that, then you're on track to getting nice controlled balancing action.</p>
<p>Hi, I tried what you said, lifting the bot up and then winding the Kp up until the wheels begin to turn then placing it on the ground and gradually increase the Kp value but I could not get it to a stage where it be considered balancing I brought the Kp value up to about 110 the wheels move in the right direction when the bot is turned but it seems to continually go in that direction sometimes and then just crashes over, this more so happens when it is falling forwards rather than backwards. I checked the values from the MPU6050 and the ax and the gx value looks a little strange with sometimes them increasing considerably in value. I kept the robot roughly stable while I was collecting these values, and this dropping and rising considerably in value continued through out the rest of the data.</p><blockquote> ax = -420 ay = 604 az = 14944 gx = -292 gy = 624 gz = 1255 </blockquote><blockquote> ax = -200 ay = 328 az = 14920 gx = -233 gy = 622 gz = 1270 </blockquote><blockquote> ax = -396 ay = 684 az = 15308 gx = -292 gy = 701 gz = 1300 </blockquote><blockquote> ax = -636 ay = 552 az = 14952 gx = -296 gy = 700 gz = 1299 </blockquote><blockquote> ax = -360 ay = 444 az = 14716 gx = -218 gy = 684 gz = 1298 </blockquote><blockquote> ax = -12 ay = 492 az = 15200 gx = -256 gy = 732 gz = 1317 </blockquote><blockquote> ax = -324 ay = 656 az = 15132 gx = -291 gy = 835 gz = 1361 </blockquote><blockquote> ax = -120 ay = 660 az = 14776 gx = -187 gy = 954 gz = 1302 </blockquote><blockquote> ax = -68 ay = 500 az = 14948 gx = -88 gy = 1025 gz = 1234 </blockquote><blockquote> ax = -388 ay = 504 az = 15200 gx = -109 gy = 1276 gz = 958 </blockquote><blockquote> ax = -764 ay = 376 az = 15060 gx = -39 gy = 1616 gz = 475 </blockquote><blockquote> ax = 320 ay = 772 az = 15308 gx = 134 gy = 1387 gz = 263 </blockquote><blockquote> ax = 368 ay = 172 az = 15092 gx = -71 gy = 1705 gz = 1185 </blockquote><blockquote> ax = -1240 ay = 480 az = 15144 gx = 19 gy = 1692 gz = 823 </blockquote><blockquote> ax = -1712 ay = 768 az = 15620 gx = -39 gy = 1384 gz = 329 </blockquote><blockquote> ax = -468 ay = 1688 az = 18756 gx = -579 gy = 1430 gz = 447</blockquote><p>I did calibrate my MPU6050 using <a href="http://www.i2cdevlib.com/forums/topic/96-arduino-sketch-to-automatically-calculate-mpu6050-offsets/" rel="nofollow">this script</a>, and I changed the Angle_offset value so that at a roughly vertical position the f_angle was around 0.</p>
<p>Excellent work Richard. Yep...... looks like the readings are having an issue. I reckon that once you sought out that issue (eg.... by testing with another MPU6050 or completely compatible MPU9150, your bot will then work excellently.<br><br>You may or may not have a failed MPU6050......but it looks like that is the source of the problem right now. Ax and Ay are going crazy. We need Ay, but don't need Ax. Looks like Az is giving sparse values too. Mine has variation too, but nothing like the variation in yours. I'll give examples of mine (from my MPU9150, which is directly replaceable). Once you get things going properly (with good readings), then I recommend - to begin with - set a K value of 0.98, so that the estimated angle relies almost entirely on gyro angle measurements at the beginning of a set of measurements. I use:<br><br>float K = 0.98; //instead of 0.8<br><br>And, also set a sampling period of 0.001 (instead of the default 0.08)<br><br>float SampleTime = 0.001; //normally 0.08<br><br>I also choose not to remove power from the motors at any stage, so I modified the code slightly to things like this:<br><br>if(LOutput &gt;= 0){<br>digitalWrite(TN1, HIGH);<br>digitalWrite(TN2, LOW);<br>}<br>else if(LOutput &lt; 0){<br>digitalWrite(TN1, LOW);<br>digitalWrite(TN2, HIGH);<br>}<br><br>if(ROutput &gt;= 0){<br>digitalWrite(TN3, HIGH);<br>digitalWrite(TN4, LOW);<br>}<br>else if(ROutput &lt; 0){<br>digitalWrite(TN3, LOW);<br>digitalWrite(TN4, HIGH);<br>}<br><br>====<br><br>I took some photos of my bot just to show you. The bot is standing on my old EA (Electronics Australia) bench supply. The bot is currently being powered via a 12V, 2 Amp AC/DC adapter supply (with the yellow strip sticker). The bot is standing perfectly still - thanks to the help of the tiniest bit of resistance (anchoring) by the small power cable. The bot is able to stand motionless by itself on carpet too, thanks to some dampening effect from the carpet. It balances very well (but not absolutely motionless) on hard floor. But I'm certainly happy with what it's doing for now.<br><br>Some of my raw values from MPU9150 below: I actually took lots more samples, but better not pollute the discussion page with too much data. The samples certainly don't jump from say 200 to say 1000 etc.<br><br>1 -284 240 16756 75 -173 382<br>2 -272 320 16820 91 -224 394<br>3 -252 264 16944 76 -199 365<br>4 -260 240 16944 93 -207 389<br>5 -248 172 16904 70 -212 365<br>6 -336 200 16820 66 -202 400<br>7 -304 260 16876 85 -190 388<br>8 -280 280 17032 61 -188 370<br>9 -200 116 16752 82 -199 376<br>10 -276 336 16784 64 -222 353<br>11 -288 200 16812 82 -204 402<br>12 -348 248 16944 84 -186 388<br>13 -204 252 16804 78 -177 387<br>14 -212 292 16832 69 -219 395<br>15 -268 352 16904 98 -199 376</p>
<p>Hi Richard, I made a very short video today of my bot to show you what you can expect once you've got the sensor readings sorted out.</p><p><iframe allowfullscreen="" frameborder="0" height="281" src="//www.youtube.com/embed/5DzuO9g-Xxk" width="500"></iframe></p>
<p>Hi, thanks for the video. I was able to get the MPU6050 ay's fluctuations down to the same as yours however I was still unable to get the robot to balance, I did notice however that it appears that a larger angle was needed on one side of the robot to get the wheels to move in that direction than on the other, I tilted the bot and on one side the angle decreased faster than it increased when tilted the other side</p>
<p>I just built a second one with bigger motors and and a bigger base <br><iframe allowfullscreen="" frameborder="0" height="281" src="//www.youtube.com/embed/nOLECk08fzs" width="500"></iframe><br>Has anyone done anything with sonar sensors for object avoidance ?</p>
<p>Just finished building the robot, wired everything correctly but when power on the robot both wheels started to spin, tried to adjust the pots but still can't stop the spinning. In monitor I can see the kp and kd values are changing. if lay down the robot both motors stop. what's wrong?</p>
<p>Hey bro! You just did a good job! And about your problem, I think you should put the 24L01 wireless module on the shield and everything will be OK!!</p>
<p>Hey mylemonjuice, I face the same problem(two wheels just keep spinning) as jimkan's and I have put 24L01 wireless module on the shield. But still have the same problem:(</p>
<p>I think my wireless module must be broken because the wheels just turn</p>
<p>Initially I thought the wireless has nothing to do with the balancing but after inserted the wireless module wheels stop spinning, I was able to tuned the kp, kd and ki and make balanced, using the wireless controller works but there must a speed control in the code to slow down the bot or it will stumble, currently I move the robot forward with joystick and quickly move it backward to slow it down. btw, you need to reverse the A0 and A1 in balancing_remote code to make it Y axis for forward and backward, the default is X asix (side way).<br><br>Joystick_1_X = analogRead(A1);</p><p>Joystick_1_Y = analogRead(A0); </p>
<p>Hi, I have the same problem even after connecting the wireless module. same thing motor spinning all the time in one dirction . any advice?</p>
<p>You probably have to adjust offset gyro</p>
<p>i have the same issue</p>
<p>Back again. I've now found that this balancing bot kit with the 3 potentiometers actually works &quot;a little bit&quot; (including the software that is provided). Although, I must say that somebody out there (eg.... the manufacturer of this bot kit) needs to tell people what's going on with the '3' potentiometer' story, while the currently broadcasted instructions (and software) makes use of just two potentiometers (one for setting proportional gain Kp, while the other sets derivative gain Kd). The remaining potentiometer that is meant to sit in the middle was supposed to be used to set integral gain Ki, except this value is now manually set in the software (so that the manually set value is currently Ki = 0).<br><br>After putting this bot together, my recommendation is to duplicate the provided arduino sketch software, and get rid of all the motor controlling code, and then add some of your own simple code so that you can monitor the basic accelerometer and gyroscope values coming out from the MPU6050 accelerometer/gyro board. That is.... use some serial.print and serial.println commands to print out ax,ay,az, gx,gy,gz, r_angle, f_angle, omega, kp,ki,kd. Then at least we can check the values to see if they're good or not.<br><br>Also, my recommendation is - instead of using the 'serial monitor' window of the arduino sketch software for inspecting serial data coming into the computer (via USB), it is better to use another software, such as the free PuTTY (for reading serial information). This is because I notice that the arduino sketch serial monitor window can't handle the bombardment of incoming serial text information. The arduino sketch serial monitor window just locks up from the bombardment of incoming text, where-as PuTTY seems to just keep receiving text without freezing/lockups.<br><br>An issue that I encountered was that the supplied MPU6050 was showing y-axis accelerometer value (ay) of +32767.... and it was stuck at this value (permanently). All other values ax, az etc looked fine..... as they actually changed values when the bot was manually tilted etc. This suggested that the MPU6050 was faulty. I have a bunch of MPU9150 boards, which is conveniently directly pin compatible with the 6050 board. I took out the MPU6050 and put in the MPU9150. No more issue with the 'ay' reading. I then checked the suspect 6050 again. Same issue. The 6050 was busted for sure. So it was no wonder that the bot inclination angle obtained by the software was wrong.....because the values for 'ay' were stuck at +32767. Hence the importance of making sure the sensors (accelerometer and gyro readings) are putting out expected values.<br><br>I haven't got a battery for this bot yet. Ordered from ebay, but not yet arrived. So I'm currently powering up the motor with a bench power supply (set to about 12 Volt DC). I used alligator clips to connect to the 'T-connector' - making sure that I use the correct polarity, and making sure to handle the bot carefully so as not to cause power supply short circuits. It's sort of a precarious situation, but it was ok by me for testing.<br><br>Without carrying a battery, the bot is balancing a bit, with Kp of 26, Kd around 3 to 4, and Ki = 0. I only just got the bot to do the balancing act about 15 minutes ago - with the power supply wires still hooked up. Precarious situation with the power supply wires connected like that. I will wait until the battery arrives before doing any more tinkering.<br><br>For this bot, I was testing it without the remote control. So the bot was trying to balance on its own. The wireless remote control was left unpowered. In fact, I haven't even tested the wireless communications yet - which reminds me that it is a good idea for the manufacturer to give users diagnostics software to test the wireless communications side of things - just to make sure everything is ok in that area.<br><br>My comments...... the bot can be made to balance. The instructables video shows it working, so at least everybody knows that the kit should function more or less eventually. What surprised me is not too many people in the thread came back to say '100% working'. My opinion about the kit. Not too bad in itself, but a better procedure needs to be put together for everybody to follow. And need to include advice for trouble-shooting.<br><br>Another important comment is that it is not possible to use every metal screw and metal hexagonal post (standoff) in the way that the bot assembly procedure indicates. It's not possible to do that - because some screw holes in the UNO board are too close to plastic headers. And some metal hexagonal posts will cause short circuits. The solution is to use nylon/plastic screws and nylon/plastic posts whenever you see fit. Sides of nylon screw heads can be clipped/snipped using toe-nail clippers, so that the screw can then be inserted right next to a plastic header. You may need to get the nylon screws etc from a electronics store.<br><br>Also, I mentioned that the kit didn't have any screw that was long enough for mounting the wheel brackets. Fortunately, I had my own screws that were long enough. So, there's certainly room for improvement in terms of supplying the right parts for the right job.<br><br>I previously mentioned that I noticed (in the instructable photos) two do-it-yourself pins poking out of the GND and 5V terminals of the header of the L298N h-bridge motor controller circuit board. I figured out that these manually inserted 'pins' (which doesn't come with the kit) are simply used for linking (using wire) with the Vcc and the GND terminals of the sensor shield board. The L298N board is supplied with 11.1 Volt, but the L298N also has an onboard regulator circuit, which develops a regulated 5V output. This 5V can then be used to power up the sensor shield board. So my opinion about those do-it-yourself pins..... that's one way to do it. Another way would just be to have two ground wires coming out of the GND terminal of the L298N board, and have 1 wire coming out of the 5V terminal.<br><br>I also notice that the legs of the potentiometers are very skinny, and do not match the wider holes of the sensor shield header. I think that it'll be necessary to solder the potentiometer legs to thicker pins, or come with with a plan to ensure good electrical contact with the sensor shield. At the moment, the loose-fitting potentiometers can lead to Kp and Kd values changing unexpectedly.<br><br>One more comment - to finish on a good note, it was noticed that when this bot is powered up through the USB cable only (no other power source connected), the bot was still able to spin 1 of the wheels in the proper control direction. It didn't have enough power to spin both wheels, but it was nice that USB power could at least get a wheel to turn and see the control action whenever we tilted the bot. </p>
<p>I'm just toward the end of assembling this Sainsmart balancing bot. I'm building the version that has the 3 potentiometers. I'm following these instructables instructions, and just reading the various comments in this thread, but can't help wondering - has anybody actually ever got this balancing bot to work properly? I mean, like - fully functional? From these thread comments, it just appears that nobody says something like 'hey! Great...works perfectly now!'. I am seeing comments like 'ok....balances, but something isn't working after a short while'.<br><br>Anyway, one comment I have is - there appears to be a lack of a proper instruction manual. Another comment - the instructables procedure photo is visibly showing 2 do-it-yourself pins poking out the GND and the 5V header of the L298N dual H-bridge circuit board, which doesn't appear to be discussed anywhere in the procedure.<br><br>The 'sensor shield' that came with my kit isn't the same as the one in the instructables photo. Mine has a logo on the shield board that looks like an alien wearing a white space helmet or something.<br><br>The procedure also doesn't tell people to pull out and remove the jumper pins on the L298N board.<br><br>Also, we are supplied with metal screws and metal hexagonal standoffs posts - to be installed on the Arduino UNO. The issue here is that 1 of the metal screws won't fit into one of the UNO holes, because the surrounding plastic headers get in the way of the metal screw head. And the metal post actually creates a short circuit on the underside of the UNO. Therefore, it's necessary to get (from somewhere) a nylon screw, and modify its plastic screw-head by snipping off bits of it. And then use a nylon hexagonal post, which prevents short circuits.<br><br>Furthermore, there were no metal screws that were long enough to mount the two metal wheel brackets, so I needed to use my own screws. So the point here is that the kit is not really complete. I'm just hoping that my bot will actually work properly, especially since I can't see too many people indicating that they got theirs to work properly.<br><br>It might help if the instructables procedure shows how the battery is meant to be installed in the bot.</p><p>I'm glad that this instructables procedure in this thread shows fairly clearly how to put the bot together. I'm thankful for that. However, the instructables photos show 2 potentiometers, while the kit has 3 potentiometers. And the video indicates that only 2 potentiometers are set (for setting proportional gain and derivative gain), while integral gain is set by software. Some inconsistency going on here in the instructions, especially since the video even starts off by indicating '3' potentiometers....but we only hear of 2 being used.<br>Fingers crossed, and wish me luck. I think I'm going to need it. I'll make sure to report back if the bot is actually 100% successful. Thanks.</p>
<p>Hi everyone,</p><p>just built the v3 and after getting through lots of missing hardware,a bad balance shield and a few other issues I am trying to program the boards.</p><p>my problem is when I go to verify or upload either the controller or robot code it says error compiling....and in sub notes it says fatal error no such file or directory #include&lt;mirf.h&gt;</p><p>I know everything is set up right as I can select a blink sketch and download it on either of the boards fine.</p><p>any ideas? I may be missing something very obvious as I'm newer at this</p><p>thanks in advance</p>
<p>Hi! I am so glad to find there is an active forum for this project ? </p><p>The regulator (pictured below) was loose in the package. Should I solder it back on? From the back it looks like it was attached with an adhesive. I&rsquo;m fine with doing it myself, though my only soldering experience is on wire and battery connectors.</p><p>Ive got a 3 cell 11.1 Lipo and have wired a xt60 connecter to the VIN and ground. Im worried to connect it and fry anything. This is my first arduino project. </p><p>Thanks so much! </p>
<p>That regulator should have been soldered -- looks like a factory error. I suspect that the 'adhesive' was to secure it to the board as a heat-shield. You could solder it yourself if you have a fine point soldering iron and some good solder. Your battery hook-up looks OK.</p>
<p>I received the replacement board from SainSmart, which is very similar but has some differences. It does have the 3 potentiometers, the h bridge, MPU6050 and 24L01 so it seems like its made for similar functions as the original. </p><p>My main concern is that the power connector does not indicate which connection is hot and which is ground. I just picked up a multimeter but have never used one and haven&rsquo;t found any videos specifically showing how to determine the polarity. Any advice on determining which way the plugs would be greatly appreciated ?</p><p>I did solder the regulator on as you suggested and was happy with it but then realized that an m7 diode rectifier was also missing (see picture) so Ive just been waiting for the replacement board from sainsmart. I did have to wait for it to come from China but they shipped it the day after I contacted them, with a tracking number and I didnt have to send the original board back. </p><p>I&rsquo;ve learned a ton I wouldn&rsquo;t have without the problems but hoping to get it up and running now. Thanks again for your help! </p>
<p>AshleyWebb76,</p><p>Here is a brief description of the board that you received:</p><p><a href="http://www.sainsmart.com/robotics/instabots/sainsmart-instabots-robot-controller-shield-for-arduino-mega2560-r3-robot-arm-control.html" rel="nofollow">http://www.sainsmart.com/robotics/instabots/sainsm...</a></p><p>Bob W.</p>
<p>Ashleywebb76,</p><p>On mine, as I look into the three holes where the power wires go, the LEFT one says Ground, the RIGHT one says VIN the the CENTER one says 5v. I think you want the red wire from your 12v battery to the RIGHT hole.</p><p>Bob</p>

About This Instructable




More by mylemonjuice:SainSmart InstaBots Upright Rover(Self-Balancing Robot With Arduino) 
Add instructable to: