I’ve just started my experiments with self-balancing robots, made a small prototype using cheap 2-axis brushless gimbal hardware and some from-scratch Arduino code:
Now I want to move to something bigger, so I disassembled a self-balancing scooter for it’s battery, motors and motor drive PCB. These things have got 2 350W sensored brushless wheel motors, a 10s2p lithium battery and a dual motor controller PCB that I’m reflashing now with open firmware.
I was looking for a suitable MCU/IMU to run the self-balancing software on (don’t want to use the stock IMUs), when I found this page. Looking forward to the progress!
This is fun to watch!
I had a question about the FPV camera though, is an active control really necessary for a bot that only leans in 2 directions? Couldn’t a gyro stabilized camera be just as effective, and less “Technical”. Just curious.
Also, thought of a potential “FailSafe” for balance bot. Have a spring-loaded kick stand which is “held closed” during normal operations but is released upon fault or power failures, to prevent the bot from falling over.
Hi there! Sorry I’m not very active here. @james_pattison Thanks @mundsen The first PR is up here: https://github.com/ArduPilot/ardupilot/pull/8701 . It would be really great if you could try out the code and let us know how it goes. That design looks amazing! can you share the fusion360 files? I personally use Solidworks. I guess i should be able to import it though.
I’ve made a blog post on my work so far: GSoC 2018: Balance Bot with Ardupilot
This is work in progress and one of my many “Learning by doing” projects, so I may alter the design a lot as I go - but shared if anyone wants to test.
What motor are you using? Can you give me a link? I love your design, but there are a couple of things that came to my mind:
Most of the geared dc motors seem to use, a standard hexagonal pattern of screw holes. Here is an example https://grabcad.com/library/37-mm-dc-geared-motor-mounting-bracket-1. There are outliers, but at least one or two holes mostly are compatible. So if you could put screw holes like that on the sides to hold the motors? Or you could put an option at the bottom to screw on a standard metal motor clamp.
The way the motors are held right now is good, but it seems like it depends on the size and may be incompatible for different motor types. Hence I made the previous suggestion.
Is the partition between the motors there for a reason? It may be a bit inconvenient to get motors in and out and for wiring. If it is to strengthen the frame, can you make it a separate screw-on part?
Pixhawks come with this safety switch. Can you put an option for that, probably somewhere at the top?
The motors are 25mm - the most motors I have found used on bots like this are 25mm or Nema stepper motors.
It is no problem installing the motors + there is space for the wires - I may consider screw holes in the sides, but I do not know how strong that is going to be - the side walls can`t be more than 2-4mm because of the short motor shafts (when using 120mm wheels like me)
I plan to support the safety switch + on/off switch
I believe a lot of people have build this bot and would probably love to use ArdruRover so if this can support the older apm configuration that would be awesome. I’ve been away from drones for a few years but I want to get his project back up and finish it. I was able to get the make version to stand still but any throttle would make it fall over fast.
I think balance bot will go out officially with Rover-3.5 but until then it’s possible to load “latest” through the mission planner’s Install Firmware screen by pressing “Ctrl-Q”. I’m also planning to buy a balance bot in the near future to give it a try and help improve it if necessary.
Sadly we can’t support the old APM2.x boards. There are a lot of them out there and strangely a few manufacturers are still selling them but considering the limited resources we have, we can’t support these really old boards because they simply don’t have the CPU, RAM or flash space to run our greatly improved E
KF or new features. We stopped supporting these boards years ago, and gave the community a year+ of warning as part of that process…
ArduPilot has come a long way and we support a large number of boards, some of them very low cost while still being much more capable than the old APM2.x boards.
One of the many Pixhawks tends to be the easiest to use. If possible we recommend buying from one of the ArduPilot Partners listed on our stores page because these companies contribute financially to ArduPilot.
May I suggest to have a look at eduMIP as a platform ?
Beaglebone Blue appears to be an accepted FC board. I now have ArduRover 3.4 running happily on it, quad encoders are onboard, all that’s needed is a way to talk to them …
The C++ reference implementation (rc_balance) is running just fine, so everything needed is there
Yes, I do have it and unfortunately has been laying in my room floor for months. If @a944734 has implemented support for it in ArduPilot that would be great, I’m happy to review and test it!
Sorry if I raised false hopes here - I am far from having an implementation available.
My present status is
Ardupilot package installed, following (extraodinary well done…) instructions by imfatant
Debian 9.5 platform
Ti real-time kernel 4_4
Ardurover 3.4RC1 compiled binary. I have not found a 3.5 version built, not able (yet) to build my own
Ardurover is running fine, talking to my desktop GCS via WLAN and USB. Have R/C connection to it
via Frsky X10S and Orange DSM satellite, can move servos
What I am still missing is
Beaglebone Blue compiled Ardurover 3.5 (Roller functionality only seems to be in 3.5 ?)
Ardurover mapping/talking to onboard (!) DC motors and quad encoders
Maybe board specific parameters
The eduMIP native package (with Beaglebone Blue) itself is balancing perfectly fine (rc_balance C++ reference implementation), controlled by R/C. I will put up a video of it working soon