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
I’ve been designing this robot for a while now, the goal is to have it recognize faces and say hello if it recognizes the person.
I’m using a pixhawk drone brain for the balancing part using ardupilot balance bot code to get it all working with minimal redevelopment. So, thanks a bunch for the project and all the awesome code and discussions that you guys have posted. I wouldn’t have been able to do it without you.
The reason why I am posting is that part of my design is to have a retractable “LEG” to come down and support the robot while it is in park mode. This will require the balancing to be turned on and off depending on whether the leg is down or up. Also, it will require the balance bot to fall in a particular direction when the leg is down and it wants to “Park”.
Does anyone have any suggestions on the best way to accomplish this using the existing code? I was thinking that a special mode could be created that would allow it to only fall in one direction, but my programming ability is perhaps not fully up to snuff to carry this off.
Hi @Ebin_Philip ,
first of all thanks a lot for your great job on the balancebots.
reading all the comments above I realized that at the beginning encoders were not mandatory( @rmackay9 ) but now I don’t find any references saying that.
so here is my question; Is it possible to build a balance bot without motor encoders, since the main feedback for the robot to stabilize is the pitch angle.
Yes, I think it could work without wheel encoders especially if you’re only planning to use Manual mode… but even Acro and other modes would probably work as long as the vehicle has a GPS.
By the way, you’ll definitely want to use the upcoming Rover-4.3.0-beta5 which includes pitch control improvements.
thanks @rmackay9
that’s great news. I’ll give it a try ASAP.
so just for the confirmation, am I right that the encoder is being used only for the non-gps navigation and/or helping EKF?
The wheel encoders are normally used only by the EKF as a substitude for the GPS. They can also be used with the “wheel rate controller” to ensure each wheel turns at the correct speed but in recent testing I think we’ve determined that this doesn’t add any value.