https://photos.app.goo.gl/uBJRCJhBmQpXQRYKA
Hello there! This is the second post on my work on the Balance Bot project. This will also be my final submission for the GSoC final evaluation, where i need to provide links to all the code i wrote. So this post is going to be peppered with links to all my pull requests. So if the regular readers over here feel there are way too many links in this post, do excuse me for the same 
.
In my previous post, I had written about our initial work on the balance bot project. When we left off, we had a balance bot which could stand up and move around quite a bit, though with some stability problems which led to frequent crashes. We also had a simulator which approximately captured the main part of the physics of our balance bot(the inverted pendulum model), but not the complete essence of it. The way the wheels and inputs were modelled were quite far from their real counterparts. If you havenât read my previous post, I would really suggest going through it once, so you get the full picture:
All the work done previously can be found in this PR:Rover: Added support for balance bots by EbinPhilip ¡ Pull Request #8701 ¡ ArduPilot/ardupilot ¡ GitHub
New wheels and motors!
Remember i mentioned about the backlash in the motors, causing instability? So we got some new motors and wheels to test out this theory and it turned out that we were right. That was the sole cause of the instability. The new motors also had a slight backlash, and I believe all geared motors have that issue to some extent. Due to this there were is slight âtwitchinessâ when standing still, but at least in this one, unlike the previous, we could leave it on and be certain that it will not topple till the batteries run out. Even better it could balance on spot and not move about. This is in Manual mode, without any velocity or distance controller to keep it on spot. This was far superior to what we had previously. Here is what Iâm talking about:
Crash checks and an elusive bug
Though the previous PR was properly scrutinised and tested, there were some minor issues which cropped up unnoticed. One was with the crash checks. There was a minimum speed check in rover, which had to be removed for balance bots, because it was triggering all the time. There was also an if condition in the controller code, which always set the D term in PID to zero. This issue came up when an additional commit was added to the PR, to maintain conformity with the rest of the rover code. It was supposed to be a non functional change, but turned into an elusive bug. The worst thing was that even though the D term was zero, the balance bot continued balancing and we blamed the shoddy performance on the motor backlash(before the new motors). This came up only when we attempted PID tuning again. These issues were fixed with these PRs:
1)Rover: min speed crash check bypassed for balance bot by EbinPhilip ¡ Pull Request #8776 ¡ ArduPilot/ardupilot ¡ GitHub
2)Rover: fixed a test case and added new defaults PID params for balance bot by EbinPhilip ¡ Pull Request #8840 ¡ ArduPilot/ardupilot ¡ GitHub
New SITL model and autotest
With manual mode working decently, we decided to shift our focus back to the simulator as a precursor to trying out other modes. We decided to change our dynamic model, which was initially the inverted pendulum on a cart to that of an inverted pendulum on wheels. The implementation was based on these sources:
1)http://publications.lib.chalmers.se/records/fulltext/163397.pdf
2)http://robotics.ee.uwa.edu.au/theses/2003-Balance-Ooi.pdf
We were able to test out all the rover modes like Acro, Steering, Auto and RTL on the new simulator. The only minor issues were some differences in some physical parameters we calculated from the real vehicle, like its moment of inertia and motor constants. I obtained those from some crude calculations and obviously they were not very accurate, but they didnât affect the functionality of the model as such. There is also this issue that the Kalman Filter(EKF2) was not agreeing well with the SITL model, so we had to default EKF_TYPE to 10. Though that is a bit intriguing, it wasnât too much of a concern since the real vehicle uses EKF2 and it worked without issues. So it could be concluded that it was just a minor glitch with the simulator code.
As i mentioned in my previous post, the SITL simulator is also used for unit testing all new code patches before they are accepted. With our simulator running in good shape, we moved on to extending the autotest script to run the balance bot code as well. Take a look:
Here are the PRs for the same:
1)Balance Bot: updated SITL, deafult params by EbinPhilip ¡ Pull Request #8942 ¡ ArduPilot/ardupilot ¡ GitHub
2)Balancebot autotest and fix for Mode Auto by EbinPhilip ¡ Pull Request #9016 ¡ ArduPilot/ardupilot ¡ GitHub
With the addition of the auto test script, all developers can now contribute to the balance bot code, without fears of breaking any functionality. With this addition, I think it is now safe to say that the Balance Bot is going to be permanent part of the Ardupilot family. Now there was only one simple thing left to do, test all the new modes on the real vehicle. But alas, there were some unforeseen complications.
Enter the party poopersâŚ
Once again, I would like to pull this diagram from my previous post(source:http://journals.sagepub.com/doi/pdf/10.5772/63933):
For the Balance Bot, we use a two stage controller. The inner loop of the controller maintains balance, using its lean angle reading from the on-board sensors as feedback. The outer loop controls the linear velocity, using the current velocity as feedback. Now comes the question, what gives the velocity feedback? In SITL, the velocity calculated by the simulator can be fed back, but this isnât the case on a real vehicle.
In typical mobile robots, velocity is estimated using wheel encoders. Those are actually great for indoor odometry. Although, in an outdoor environment, GPS can also do well for velocity feedback. That is how the Acro mode in rover is designed to work. But these GPS and IMU measurements were not accurate enough for a Balance Bot, as our outdoor tests showed.
The documentation mentions that wheel encoders are also supported by rover. Sadly, the wheel encoder libraries were designed to run on Nuttx OS, while I was running ChibiOS. I also could not switch back to Nuttx, because I was using brushed motors drivers, which use a duty cycle input for speed control and two relay pins for direction control. Tridge managed to provide me with an experimental ChibiOS firmware which could provide the duty cycle pulse. So ChibiOS was our only option. The only downside was ChibiOS didnât support the wheel encoders back then. There were a plethora of hardware and low level firmware issues associated with it, which were totally out of the scope of my project. Luckily we had wizards like Tridge and Peter to deal with it and they eventually got it working.
Another startling discovery for me was that the wheel encoders are not used in rover for velocity estimation but only for position estimates in automatic modes. By then it was getting quite late to work on it and have it tested by the final submission deadline. Randy is currently working on adapting the wheel encoder code so that it is used for velocity control as well.
Together, the issues with the wheel encoders and the velocity controller for the real vehicle turned out to be a total killjoy for me. I was expecting to put up a video of all the modes working, but that will have to wait now.
There is still good news though
Though we were unable to test all the modes on the real vehicle, the simulator tests confidently tell us that all of our code is in order. The wheel encoder support is actually a minor issue in the big picture and i have full confidence that in a week or two, we will be seeing the balance bot running all modes successfully.
Even better, Randy managed to do an outdoor test of the Balance Bot in manual mode. He made a clever addition of a feed forward term in the balancing controller PID, based on the wheel encoder reading. This actually enhanced the stability in Manual Mode. Here is the video of his test:
Balance Bot Documentation
The documentation for running balance bots is up and you can find it here:Balance Bots â Rover documentation.
Whatâs next?
- Implement wheel encoder based velocity control
- Test out all modes on the âactualâ balance bot
- PID works fine, but the LQR controller is what is more widely used for balance bots
Concluding Remarks
These last three months of work with Ardupilot has been a very great time for me. Right from learning new things every other day to working with some of the brightest minds I have ever seen, the experience was unparalleled. @tridge and @peterbarker have been very helpful and considerate as mentors and I really could not ask for better. Special thanks to @rmackay9 and @jschall for all the help and advice. Though officially my GSoC work with Ardupilot is over, I really look forward to continue working with this team and taking the Balance Bot project even further.