Close
0%
0%

Droidbot 07 - Wheeled-Quadruped

An ambitious mobile robot for testing my skills and learning new ones.

Similar projects worth following
I am attempting to design, build and program a robust, compact wheeled-quadruped robot that can operate in harsh "human-scale" environments.

It started out as a fun sci-fi based hobby project for me to learn new things, but I'm aiming to produce a prototype that has practical applications too.

Unfortunately progress is glacial.

Goals

This is an ambitious project with many challenges. It is (unfortunately) just a hobby with the resource constraints that this imposes, but assuming I don't go bankrupt, go to jail or die; I'm am putting every reasonable effort into progressing this project. It is both a creative outlet and a tool for personal growth. 

Here's a list of what I hope to achieve (both short- and long-term).

  • Large enough to operate outdoors and in limited human environments. Think R2-D2 size rather than table-top or carpet rover. Costs will be higher though. 
  • (A little) Sci-fi styling here and there. 70's and 80's childhood of Star Wars and Alien(s) having a big influence.
  • Four stowable wheeled-legs allowing staged development with modes of travel:
    1. Compact 4-wheel slow manoeuvres.
    2. Expanded (stable) 4-wheel manoeuvres.
    3. Quadrupedal walk.
    4. Compact 2-wheel balance.
    5. Expanded 2-wheel balance.
    6. Upright 2-wheel balance (think Boston Dynamics' Handle).
    7. Bipedal walk?
  • Head tracking and remote viewing for tele-presence.
  • Two main arms for remote manipulation. Possibly a smaller arm (or two) for more delicate tasks.
  • Learn Linux & ROS. On-board Raspberry Pi(s), Arduino ROSnodes and monitoring/control via laptop and/or custom remote.
  • Investigate higher level behaviour algorithms, machine vision, mapping, speech recognition, speech synthesis and AI.
  • Investigate possible practical applications. I'm thinking disaster relief with appropriate sensors and equipment. Skill transmission via tele-presence. Provision of power? Water filtration? Load carrying? Security monitoring and warning?

Maplin XT75S UA3730 Electronic Code-Lock.pdf

A Maplin electronic code keypad kit from the 80's.

Adobe Portable Document Format - 4.92 MB - 12/20/2017 at 09:46

Preview
Download

  • 1 × Raspberry Pi Have a RPi B+ and had trouble installing ROS. Will get the more powerful RPi3.
  • 2 × Arduino Mega Still WIP, so quantity may change.
  • 2 × 12mm plywood 1200x600mm approx. For main chassis. Cheap and easy to work with.
  • 1 × Generic 20x4 LCD
  • 1 × Analogue 3-axis joystick

View all 17 components

  • Ubuntu & ROS (Robot Operation System) on a RPi3B+

    Paul Crouch3 days ago 0 comments

    After reading up on different Linux distros (whoa, that's a rabbit-hole!), I installed and tried a few before settling on Ubuntu MATE. I chose it because it has a large community, lots of support, examples etc and will run on a Rasberry Pi. I preferred the MATE desktop over the standard Ubuntu one too. I installed Ubuntu MATE on an old netbook for development purposes, then ended up dual-booting with it on my old main laptop too, then of course set about installing it on the shiny-new RPi3B+ that I recently purchased...

    At the time of writing, the RPi3B+ will not run most Linux distros. That's the "B+", the "B" is fine. The architecture of the two are different and the B+ will only run Raspbian out of the box, a fact that isn't immediately obvious until you start looking into it. I had assumed that I could get the latest Ubuntu image (Bionic 18.04) and install the lastest ROS distibution (Melodic).

    Ubuntu MATE & ROS Kinetic on a Raspberry Pi 3B+?
    Ubuntu MATE & ROS Kinetic on a Raspberry Pi 3B+?

    As I understand it; Ubuntu MATE (16.04) is available for RPi2 and RPi3 but not the B+ and ROS Kinetic is available for Ubuntu Xenial 16.04 on the "armhf" architecture (Pi), but not for Debian-armhf. The latest ROS Melodic only supports Ubuntu Bionic. Kinetic is supported until April 2021, so shouldn't be a problem, but there's no Xenial/16.04 image for the Raspberry Pi 3B+. Xenial's support ends April 2019, Bionic/18.04 ends April 2023. So Bionic for armhf would be the better choice, if it existed...

    See https://droidbot07.blogspot.com/2018/10/ros-on-raspberry-pi-3b.html for details.

  • System architecture

    Paul Crouch5 days ago 0 comments

    Well, my cunning plan for load-bearing mounts seemed to like too much hard work. Instead I used M6 rivnuts on the bulkhead and strategically placed hex-socket pan-head bolts through the sensor-ring (base of head/camera shield) to secure the two together.

    With the head removed again, I mounted the sensors and began to consider how best to wire them back to whichever processor I was going to use. It got me thinking a bit more about the system architecture overall; what did I plan to use where and how was it going to inter-connect? I scribbled several diagrams on paper before moving to the digital domain. Below is the latest iteration of my imagined system architecture for Droidbot. It is an incomplete overview only, something to help me avoid major snags.

    Droidbot System Architecture
    Droidbot System Architecture

    With the larger system in mind I dug out my Raspberry Pi (2, I think) to get a better understanding of how it all works. I quickly concluded I should get the latest and greatest RPi3B+ if I wanted to do image processing and similar, so I ordered one.

    7" 1200x600 touch-screen for RPi

    While waiting for the 3B+ to come in, I again connected up the display I had bought (some time ago). It's a reasonably sized 7" HDMI display with a touch panel, it's very nice and works well.

    Touch panel for robot operator station GUI
    Touch panel for robot operator station GUI

    As part of the UI, further down the line, I'd like to have a remote touch-screen GUI at the operator's station. This panel is intended for that and it seemed like it would be up to the task with the right hardware and software behind it.

    Playing with the RPi led to a whole load of RPi/Linux/ROS fun...

  • Sensor mounting & camera shield painting

    Paul Crouch09/14/2018 at 07:24 2 comments

    With my week-in-the-sun over, I decided where I wanted to place the main sensors (after some research and experimentation with a couple of microwave Doppler modules) and made the appropriate holes in the polycarbonate strip that will become the sensor collar.

    The RGB LED strip repeatedly fell off while the shield just sat there; the adhesive tape is clearly sub-standard but this did provide the perfect opportunity to paint where I needed without too much detailed masking. I peeled off the existing adhesive tape ready to replace it with some better stuff.

    I clamped the polycarbonate strip in place, using the LED strip to set the spacing, then solvent-welded with methylene chloride again. It is good stuff.

    I masked the shield with tape and newspaper before getting too carried away with the spray paint. I do it every time; too eager, too much paint, paint runs. Arse. I let it dry and sand it back. This time I go with 2 or 3 lighter coats as I should've done in the first place.

    After masking and painting

    The result isn't perfect and I just noticed a small run that I'd missed. Oh well. It is what it is. Some more sealing and painting will be required on the top, but for now...
    Next I cut-down some replacement adhesive tape and mounted the LEDs again and they seem to staying put this time.

    Mounted LEDs again

    A test fit was next on the agenda, to check how I was going to secure it and mark cut-outs to allow clearance for the rear of the sensors. 

    Test fit

    Rear sensor clearance was a rather hacky affair with shears and a knife. Load bearing fixings are now my concern, given that I wanted to be able to lift the whole robot by its head and there are no structural members protruding to the top (by design). It may not be possible in the end, but I have a cunning plan.

  • Polycarbonate head/camera shield

    Paul Crouch08/04/2018 at 19:34 0 comments

    I'd read that polycarbonate can be welded with methylene chloride so I bought some (1 litre for less than £10 including the £5 shipping). I tested it on some scraps of polycarb and ABS and can say it solvent-welds polycarbonate and ABS extremely well. In the photo below, the top two pieces are well-and-truly fused and will not peel apart and the bottom piece, that was bonded to a failed ABS print, still has the skin of the print on it after some not-inconsiderable force was used to separate them.
    Solvent-weld polycarbonate and ABS with methylene chloride.
    Just to check; acetone barely touches polycarbonate and though it does fog it slightly it then fades. The polycarbonate strip in the photo below was dipped for a few seconds in each chemical. I would say methylene chloride is better than acetone for ABS too, certainly faster, though harder to spell :-) 
    Acetone dip on top, methylene chloride on bottom.

    Assembly

    I did a dry-fit of the parts and checked for any show-stoppers. I didn't want to ruin the material. It's not hugely expensive but it's not zero cost either and would take another week to come through.

    Dry-fit.

    The image below shows my intended plan. The main reasons for the overly complicated layering are because I didn't want the LED strip to sit proud of the main skin and I'd had an internal dimension to match for mounting.

    The plan.

    I just had to hope I'd not ruined the plastic after attempting to solvent-weld the camera shield and cap with a less-than-steady hand. Annoyingly I managed to scuff the polycarb too. As advised, I left it  overnight to fully set.
    Letting it go off over night.
    It's far from flawless, but it fits and I'm making progress! In my eagerness, I didn't take any photos of the spacer strip being bonded. I used four clamps (in the photo above) to clamp the spacer strip after I'd applied the methylene chloride with a small paint brush, then I brought the "oldest" clamp to the newest position, working my way around. If you don't look too closely it looks fine. It's a first for me so shouldn't beat myself up over it.
    Test fit for size.
    Before I mounted the RGB LED strip I again did a test-fit. The wire termination end has heat-shrink tubing on it that I cut off so it wouldn't restrict the wire routing. I'll have to re-insulate it somehow. To my surprise there was another LED under the heatshrink. I hadn't given it much thought, how else would they do it? They're not going to remove one, that's not cost effective. Just struck me as odd.
    First LED is covered up. Common practice?
    With the LEDs stuck on, I clamped the strip of polycarb (that will become the sensor collar) in place to get a feel for how it will look. The white protective film is a close match for the white that it will eventually be painted. I'll need to mask and paint the dodgy-looking welded areas too.
    Mock-up of sensor collar.

    Now I need to work out exactly what sensors I'm placing and where. Back to the CAD...



  • Early concept renders

    Paul Crouch07/27/2018 at 01:00 0 comments

    I watched a couple of Fusion 360 tutorials and had a go at modelling the legs. I had to use 360's joint functions correctly so I could adjust the leg positions for some concept renders. Here's a couple of renders to hopefully give a better idea of what I'm doing. Crude early concepts, with no wheels, arms or any details.

  • Collecting parts and building experience

    Paul Crouch07/22/2018 at 01:14 0 comments

    Since my last post, I've firmed up my design (head-only render below) and assembled the new frame from 2020 aluminium profile. The new frame still has the hash design of the original to support the lazy-susan bearing but now has a narrow box frame below that will allow the legs to fold in around it and tuck under the head.

    Render of head CAD model.

    I've purchased the necessary polycarbonate for the protective camera shield and sensor mount, though I've not had chance to assemble it. I intend to use a Microsoft Kinect 2 depth camera (for point-cloud in ROS) and a stereoscopic camera for tele-presence operation, both mounted on the ring. I have the Kinect but I'm undecided on how to do the 3D imaging. To begin with, I'll be starting with a regular camera mounted on simple pitch-roll mechanism (yaw and active camera swapping taken care of by the ring). I have purchased a Logitech C920 for development purposes as it provides HD quality images with auto-focus and comes with stereo microphones (may help get started with remote sound location, though it'll probably be limited as the camera will be behind the polycarbonate shield).

    Testing the RGB LEDs

    A water-resistant RGB LED strip (100 per meter) will provide short-range illumination for the cameras in addition to simple communication (of sorts) to anyone nearby. The LEDs will be recessed around the head, below the camera shield, above the sensor ring (the white strip in image above).

    I printed the ring-gear segments in ABS and solvent welded them together with acetone. The ring was then screwed down through holes drilled in the lazy-susan bearing. A 3DP 8T pinion gear mounts to the gearhead motor to drive the 64T ring-gear. Yes, it hurts if you absentmindedly trap a finger in there.

    Aluminium angle and 6mm polycarbonate (I used what I had handy) form the bridge which carries some electronics and a slip-ring. A small polycarbonate deck spans the width of the bridge above the slip-ring to keep an IMU (MPU6050) centered. The IMU will be used to keep the robot level and balanced. The electronics may be re-housed in waterproof enclosures if I ever get this thing mobile.

    I had an IR photo-reflective sensor counting teeth and a magnet operating a reed switch to detect the home position but I was unhappy with the performance. The resolution of the 64-tooth ring-gear and sensing method wasn't giving the results I wanted so I swapped in a 600-tick rotary encoder on a second 8T pinion.

    PID

    My DIY PID position control code was then giving reasonable results but I knew it should be capable of better. I've long known the concept of PID control but there's nothing like getting your hands dirty to really drive it home. Below is one of the many plots I made when trying to tune the PID values.

    My DIY PID code wasn't too bad for a first attempt.

    I'd type in a target position on a serial terminal and for most positions, most of the time, the head would turn reasonably enough, but still it could be better. Too much hunting that was hard to reduce without increasing the time to target.

    The results I was seeing suggested my proportional calculations were suspect. I couldn't see how the relatively simple code wasn't functioning but I also admit I'm not an expert. Time to try known-good code so I swapped to the Arduino PID library and started the whole tuning thing again. You can spend the rest of your life tweaking PID values; constantly trying to get slightly better performance under slightly different conditions. I need to draw a line under this. Find values that are good enough and move on. However, before I can do that, I need to fix the CW/CCW behaviour that I broke in the PID swap.

    Ultimately the target won't be set by a step-change entry on a serial terminal but by a more fluid parameter coming from the head-tracker or another algorithm and that's not helping with the PID tuning. I need a more analogue way of...

    Read more »

  • I'm better than me.

    Paul Crouch03/21/2018 at 13:21 4 comments

    I've been thinking about the head and drive mechanism not being particularly robust and judging by discussions in the Astromech builders forums, the public can be brutal with displayed droids. I doubt I'd be attending the same events but I want robust. I like robust.

    Frustrated with second-guessing myself and my inability to make decent progress I have to console myself with the adage; Fail Fast, Fail Often. Iterate. Prototype. Understand that every change or "failure" is simply a step toward the new and improved version. I'm learning from everything. Nothing is wasted. Honest.

    Parallel to my own internal conflicts of self-worth is the feeling that I should be putting my efforts to better use. Granted, I want to build cool robots, I can't deny that passion but it bothers me that with everything going on in the world, I'm putting my efforts into what is essentially an expensive toy. I can do better than that.

    Coincidently, about this time, the Avatar XPRIZE is announced and I read the objectives, guidelines and example tasks. The goal for my robot has always been to have a tough, usable machine and the Avatar XPRIZE objectives just felt right! I'd compromised on my early goals, aimed lower and that grinds a little but I simply don't have the resources to be able to produce anything in any timescale close to that needed for the XPRIZE. I can adopt the worthy objectives though. I should at least try. And try using low cost components, materials and methods so something could be deployed for less than $1,000,000.

    Too hard? Too easy says Evan Ackerman (Contributing Editor for IEEE Spectrum's Automaton), suggesting some interesting additions:

    "So how could the competition be made better? Fundamentally, I think there are several different ways of looking at robotic avatars—you could consider them to be remote humans, with the goal of creating an experience for a user that’s as immersive and as much like “being there” as possible, or you could consider them to be one half of a robot-human team, where both the robot and the human augment each other’s strengths and while compensating for weaknesses."

    And is in-line with my thinking:

    "An avatar designed to be part of a more practical robot-human team might be much different, depending on what the system was designed to do. To use disaster relief as an example, you might not want the robotic system to be humanoid at all. You’d want the remote hardware to be capable of extreme mobility, to be very strong and durable, and to incorporate a suite of sensors that outclass anything a human has to offer, while relying on the human to make sense of the data and provide high level control of the robot. Some challenging tasks that would take advantage of this might be:
    • Perform a dexterous manipulation task in a smoke-filled environment.
    • Locate an unconscious human trapped under rubble, and rescue them.
    • Collaborate with other humans to unload heavy supplies out of a truck.


    Exactly!

    To that end, I'm pivoting the project slightly. Aside from some redesign for robustness, the only real changes are more focus on making the arms more usable and the addition of some kind of stereoscopic vision system and remote HMI. I have no idea how far I'll get. Baby steps!

  • Head pitch, roll and yaw mechanism

    Paul Crouch03/08/2018 at 08:08 0 comments

    I've just assembled the new head mechanism and I'm quite pleased with it!

    The assembly will allow the head to pitch and roll in order to stay level in response to external disturbances (terrain mostly). I want a level head for mounting sensors and I think it'll look cool. There's a small slip-ring embedded in the center allowing 360° rotation via the gearhead motor clamped to the side. The whole thing sits on top of a linear actuator giving 150mm of vertical travel to provide clearance for pitch and roll but still allowing for a compact "stowed" mode.

    Head pitch, roll & yaw mech.

    Head pitch, roll & yaw mech.


    I was happy to finally get this assembled as progress had been slow recently with a few hurdles to get over. My cheap 3D printer has not been liking the cold either and spare time and money are of course major constraints, I guess they are for most people.

  • A different approach

    Paul Crouch02/27/2018 at 10:46 5 comments

    In order to help me decide on whether to proceed with PAMs or switch to motors, I made a crude model of a leg. It's difficult to see here but there's 4 PAMs for the hip (up/down & left/right) and 2 PAMs for the knee. The paracord "tendons" that attach to the muscles are not shown. The knee joint has a small drum built-in for the paracord to wrap around, to give (in theory) 180° of travel based on ~30mm of PAM stroke.

    PAM actuated leg concept - hip & knee
    Knee joint with drum for 2020 profile
    Ball joint for 2020 aluminium extrusion
    Training cue ball drilled, tapped and threaded onto M10 stud

    But I'm still not convinced. I've held off printing or buying any more parts until I can decide on which method I want to go with. I only buy enough of something to build a prototype and don't consider anything as wasted as I usually I learn something from it.

    In parallel to the PAM/motor dilemma, I began to dislike the direction I was going in with the overall design finding it is too restricting and, currently lacking some lower-body structure to work on, I felt I'd been caught in a loop with it; PAM actuation would mean one type of leg mounting configuration and motors require another. The head-drive felt like a bodge too (and subsequently gave substandard performance) with little room to improvements. My early "hash" chassis was becoming a hindrance. So I had a re-think.

    Below is crude model, just to get a feel for proportions, of an alternative chassis using 2020 profile. It will allow more freedom to adjust things and, more importantly, give me some lower-body structure to work on. The head will still be able to pitch, roll, yaw and move in the Z axis via the existing pitch/roll mechanism and linear actuator (not shown), though the yaw drive will probably move to the end of the linear actuator rather than turn the whole thing as I do currently.

    New approach to chassis using 2020 profile to give more space for legs and radically different appearance when unfolded.

    If using PAMs, the mounts for the hip ball-joints would be tilted back to allow the legs to fold against/into the body. They may have to be actuated too in order to achieve the desired range. PAMs aren't going to cut it if I have to add extra motors to work-around their shortcomings.

    I intend to have panels and the shape of the leg themselves give a more closed cylindrical look when folded up but a completely different look when opened out. I feel that I'll have more room for additional appendages too.

    Motors

    The more I learn about BLDC motors the more I'm favouring them. I was unsure if I could easily get a high enough current ESC that has an equal reverse speed but it seems they are available, if I understand correctly it's the calibration/setup that determines min/max scaling for forward and reverse. I have also looked at VESC and ODrive but aside from availability issues, they are both quite an investment just to try, so I'll need to be sure.

    Looking at Hobbyking outrunner BLDCs:

    57g    £9.23    7A    75W      3S        KEDA 28-30 920KV Outrunner (purchased)

    153g  £16.28   28A  450W   3-4S     KEDA 36-48 1030Kv Outrunner 4S

    291g  £24.36  37A  600W   3-4S     KEDA 49-55 750Kv Outrunner 4S

    290g £19.84   65A  1300W  5-6S    KEDA 43-62 1650Kv Outrunner 6S

    390g £29.61   50A  1300W  5-6S    KEDA 49-64 330Kv Outrunner 6S

    500g £29.61   80A  1500W  5-6S    KEDA 56-63 195KV Outrunner 6S

    670g £36.48  90A  2000W             KEDA 63-64 190KV Outrunner 10S

    275g £36.45  58A  1260W   5-7S    Turnigy Aerodrive SK3-5045-450KV

    376g £37.49   65A ...

    Read more »

  • Am I fooling myself?

    Paul Crouch02/08/2018 at 18:49 0 comments

    Do PAMs really have much benefit over motors?

    Some (subjective) pros & cons of PAMs vs BLDC motors for this application:

    Pneumatic Artificial MusclesMotors (& gearbox)
    + Powerful for their weight/cost.
    + Fast.
    - Have to trade speed for torque.
    - Do I have the budget for big enough motors?
    + Negligible weight for muscle itself.
    - Weight of valves (400g each) & compressor (2.88kg). Reservoirs planned to be 2L soft drinks bottles (tested to 90psi).
    - Fittings, pressure sensors, regulator (all non-zero).
    - Weight of motors & gearboxes or lead-screws. Small KEDA 28-30 920KV Brushless Outrunner weighs in at 57g.
    Larger Turnigy Aerodrive SK3 - 5055-280KV Brushless Outrunner: 570g.

    + Inexpensive, even including cost of 3-way solenoid valves. ~£11 per DOF.
    + Single small compressor (85lpm) for ~£30.
    - Fittings & accessories should be considered (all non-zero).
    + Small BLDC motor ~£9
    - Larger (more torque) motors cost more. £40+ for bigger BLDCs.
    - Required ESCs can be costly too(?)
    + Compliant: built-in suspension for both rolling and walking. 
    + A degree of safety around those pesky humans.
    - Difficult to position and lack of rigidity would make balancing (future!) more difficult.
    - Limited unpowered support - collapses when not powered, so no static display or maintenance.
    + Easier to position.
    + Gearing that isn't back-driveable would automatically lock limbs for static support.
    - Could be too rigid? Transfer of shock. Not compliant to terrain.
    - Air demand could outstrip supply. Compressor choice & reservoir size have major impact.
    - Compressor current ~30A.
    Current of multiple BLDC motors?
    Small KEDA 28-30 920KV Outrunner max 7A.
    Turnigy Aerodrive SK3 - 5055-280KV max 60A.

    I'm concerned about the speed-torque trade-off with motors; I guess that's solved with bigger motors but that has weight and cost implications. PAMs seem to have plenty of power but I'm fairly sure I'd be shortening the life-span of the solenoid valves by operating them at high rates and it would be a huge PITA to have to switch to motors, because of reliability issues, once I'd committed to PAMs.

    Maybe a hybrid system? Best of both worlds or twice the weight, power consumption and complexity?

View all 22 project logs

Enjoy this project?

Share

Discussions

Josh Starnes wrote 08/21/2018 at 20:37 point

Oh I love this, I love robots in general. I am here if you need any help

  Are you sure? yes | no

Paul Crouch wrote 08/21/2018 at 20:59 point

Cool, thank you. I’m bound to need help when I get to the later stages.

  Are you sure? yes | no

Paul Crouch wrote 02/13/2018 at 08:27 point

Thanks, I'm glad someone finds it of interest.

Some compliance is useful for traversing uneven terrain. Imagine trying to push a rigid trolley across cobblestones? Not being locked rigid (via suspension, pneumatic tyres etc) smooths the ride. It's a trade-off; too much compliance makes it harder to control position.

  Are you sure? yes | no

malvasio.christophe wrote 02/12/2018 at 17:24 point

Hi nice work

what about water instead of air for PAM ?

  Are you sure? yes | no

Paul Crouch wrote 02/12/2018 at 18:46 point

Thank you.

I have thought about fluid filled muscles but dismissed it because I'd lose the springiness and gain weight. I think the valving may cause issues too, certainly couldn't use the cheap 3-way solenoid valves I've been testing with. However, it may make them a little more controllable as it would remove the spring effect and a closed system would negate the air capacity concern. I'm still on the fence as to which way to go, so thanks for the reminder!

  Are you sure? yes | no

malvasio.christophe wrote 02/13/2018 at 07:13 point

Thank you to put your efforts on this project ;)

it  reminded me about my wanted wheeling chair with legs and arms ...

why springiness is a need ?

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates