• aditya mehrotra.

pathfinder robot. [semi-failed projects]


let's start at the beginning: what is pathfinder?

Pathfinder started as an ambitious but basic idea. "Robotics is a tool that’s advancing incredibly quickly in today’s day and age. A world with robotic automation as the norm is not a far-fetched fantasy. Devices like Amazon Alexa & Google Home are already in place in many homes. However, robotics has not caught on in the home, experts say, because of the high price, and the lack of a viable solution to real world problems at home. There simply isn’t a solution that people actually want, or can afford at the moment."


This project was inspired by many factors, but the problem that inspired it is very well outlined in Bill Gates article in Scientific American: https://www.scientificamerican.com/article/a-robot-in-every-home-2008-02/


So the question became, what if we made a home robot that did more than a Roomba. What if we started looking at robotics in the same way that we look at computers? One device, hundreds of capabilities. Pathfinder was a first-ditch attempt at this.

some background research

Before starting anything, it would've been good to gauge what people's opinions on this topic was. So a survey was created not to really definitively prove Gate's point or the idea we were trying to explore, but just to get some validation of the thinking.


We conducted a really fake/"jank" survey of some people around the North East USA asking a few question about robotics in the home. The full, detalied, survey-analysis writeup can be found at this link: https://docs.google.com/document/d/1epx8oHNOtN-wUNDS4s8OGNI5BeIgq4Q3Ovacv9WdY2w/edit?usp=sharing


This report found that there is a genuine need by the population for robotics at home, or at the very least there is a market for such a robotic system. Based on this survey it seemed pretty clear this was an idea worth pursuing - a home robotic system that could possibly achieve MANY if not ALL of the above functions, and at the very least some of the practical functions. The price range for the robot needs to be affordable, <$2000 preferably.


some ideas at the beginning

This is just a list of some of the initial functions written that a useful home robot could have.


(1) Security/Safety Features (home security monitoring, suspicious activity monitoring, medical emergency response, auto-911 call, etc)


(2) Peace-of-Mind Monitoring ("hey, did I leave the stove on?" --> and the robot will check, or "did the kids get home safe?" via the mobile app, check who's at the door, check if someone is downstairs or just came in?, camera view)


(3) Around-the-Home Tasks (getting you items from different places, letting the dog into the house, feeding the pets, watering the plants at least in the home, possibly cleaning the floors, make some toast)


(4) Lost-Items (keeping track of lost items helping look for lost items)


(5) Other Funsies (play me music, take a family picture!, weather, google, assistant, etc...)


(6) Automated charging and cleaning of the robotic system itself, automated return to home.


Now there was no way pathfinder was going to achieve all of these things, that was never the point of it. The point was to get a lot of ideas down on a paper, and start making a prototype that could help more ideas flow. Pathfinder was never meant to be a solution, it was an idea-generation tool which is always important in early product design.


mechanical design of the system

The mechanical design focuses on the following basic componenets, we will go through each of the individually:

(1) The Drive Base

(2) The Tower

(3) The Robotic Arm (SCARA-STYLE)

(4) Supporting Structures


the drive base

The drive base is a tiangular-style drive base meaning there are three main support units. The front two drive wheels, and the rear, unpowered ball wheels. Starting at the front, the drivebase has two, 5 inch powered drive wheels that operate on the differential drive (tank drive) robotic principal. The batteries and main controller sit inbetween these wheels for extra grip. Above the wheels are a flexible board suspension system, it provides enough dampening to help the robot drive but not an excessive amount. Moving towards the middle are the electronic systems for the devices mounted to the top of the drivebase. In the rear of the drive base, two spherical wheels allow the belly pan of the robot to slide along the floor easily.


Note: top-most piece is the flexible suspension component picture for reference.



Note: this is a front-view of the robotic system and the flex-suspension


The Drive Base serves as the mounting point and motion base for the entire robot. Most of the electronic components are mounted to the base to lower the entire robot's CG. The base also operates on the Differential Drive robotic theory for ease of navigation and programming. It is the most structural component of the device with metal supports as well as PVC plastic framing.


The Tower

The tower exists as the supporting structure for the SCARA robot arm as well as the the vision and mapping sensors. The tower consists of two verticle aluminum support beams bolted to the main chassis, three PVC plastic black walls, and other supporting structure. The entire tower rises roughly 25 inches from the top of the chassis. At the top, a Kinect Sensor and RPLiDAR A1 are mounted for navigation and vision. Inside the tower is where the SCARA Robot Arm will be mounted.


The SCARA Robotic Arm

The SCARA-style Robotic Arm is the main manipulator of the Bumblebee Pathfinder Prototype. While this may change in the future, the basic mecahnical design of the robot consists of a drive base, a robot arm, and a sensor array. This is the minimum concept that is able to achieve the tasks above with repetability. There is talk about integrating an automatic multi-changing tool system into the arm, but at the moment this is not a part of the design.


The SCARA Arm is a 5-axis arm with (1) up and down motion (2) shoulder side-side (3) wrist up and down (4) wrist twist (5) gripper. There is technically a 6th axis being the rotation of the drive base itself - but this component is not included in the architechture of the robot arm DRIVER SOFTWARE meaning it is not a component of the arm. This design gives the arm a larger workspace while not requiring massive amounts of torque about the axis. The arm is used in most of the essential functions of the robot.


Supporting Structures

Supporting stuctures for the robot include the Kinect Mount, the LiDAR Mount, the Interactive Screen Mount, and any other mechanical component not mentioned above. These componenets are essential to the system but not large enough to be categories of their own.


CAD & Design

The following represents the CAD Design and structural drawings of the robot. Note the abscence of the SCARA STYLE ARM as it has not been designed or implemented yet.

CAD FOLDER FOR ROBOT: https://myhub.autodesk360.com/ue2d08f5a/g/projects/20181126162331526/data/?tryNew=true


computer architecture


Hardware

The robot is now based on the Intel Atom Z83-W Mini PC running Ubuntu 18.04 LTS Bionic Beaver and ROS Melodic Desktop Full. The sensors include an IMU, a RPLIDAR A1, and a Microsoft XBOX Kinect Sensor v1.8. Together these make up the main componenets of the hardware architechture. Together they help the software determine the position of the robot and relay instructions to the robot component themselves. The Atom is connected to an Arduino UNO over serial USB, the pinouts are shown below:

NOTE: THE ROBOT AS OF 1.20.2019 IS NO LONGER LATTEPANDA AND ROS KNETIC UBUNTU 16.04 LTS BASED The Bumblebee Robot is currently based on a Lattepanda Ubuntu 16.04 LTS Lattepanda Xenial and ROS Kinetic Desktop Full. The sensors include an IMU, a RPLIDAR A1, and a Microsoft XBOX Kinect Sensor v1.8. Together these make up the main componenets of the hardware architechture. Together they help the software determine the position of the robot and relay instructions to the robot component themselves. The interesting part about a Lattepanda is the inbuilt Arduino Leonardo fuctionality. The board and pinout are described below.


The reason for the change from Lattepanda to Intel ATOM is because of the Lattepanda's customized nature, it requires highly specialized drivers to interface mechanical components and a special version of 16.04 LTS. We believed that it wasn't worth the time to try to develop drivers for the Lattepanda to make components work that would work on a normal Ubuntu System. We also believe that in the future we would not be running the robot based off a Lattepanda but via a PC with more traditional architechture. Therefore, we switched the robot's main controller from the Lattepanda to the Intel Atom on 1.20.2019.


Software

As stated, the Intel Atom Z83-W Mini PC is running Ubuntu 18.04 LTS Bionic Beaver and ROS Melodic Desktop Full. The motors and control interfaces are plugged into the ports of the Arduino USB to the PC. There are two main software systems, the ROS system in the Ubuntu device and the Arduino code itself. The Arduino is controlled from python over PYFIRMATA over the Firmata protocol.


The Ubuntu system is much more complicated. The ROS system reads data from the sensors and inputs them to a HECTOR SLAM algorithm that uses them to MAP the envrionment and determine the position of the robot in its environment. Then the HECTOR SLAM system sends data (publish subscribe arch) to a path planning system (undetermined at the moment) which will tell the robot where to go when commanded to do so. HECTOR SLAM was chosen because of a lack of an odometer requirement. Important locations are stored as waypoints. Programs are run for other functions of the robot such as GSPEECH that interface with the ROSCORE System.


Other functionalities we are looking into are the ROS and Ardupilot interfaces where ROS sends position data to ARDUPILOT. This is a possible architechture we are exploring.


Hector Slam/Path Planning/Control

http://wiki.ros.org/hector_slam/Tutorials/SettingUpForYourRobot

https://wiki.ros.org/navigation

http://wiki.ros.org/ros_control

http://ardupilot.org/dev/docs/ros-slam.html

https://answers.ros.org/question/40584/hector_slam-and-imu/

LiDAR Packages

https://github.com/robopeak/rplidar_ros

https://github.com/robopeak/rplidar_ros/wiki THIS ONE TELLS US RPLIDAR SIDE SETUP

Python and Arduino

https://www.makeuseof.com/tag/program-control-arduino-python/

Previous Implementations

https://answers.ros.org/question/11363/how-to-generate-map-with-hector_slam-and-kinect/

https://github.com/NickL77/RPLidar_Hector_SLAM THIS ONE ACTUALLY HAS AN EXACT TUTORIAL FOR WHAT WE'RE TRYING TO DO

Google GSPEECH Robotics

http://deeplocal.com/postermaker/

Our Resources

https://github.com/bumblebeerobotics/pathfinder/tree/master/Resources

https://www.youtube.com/watch?v=bAI4vnlQhPg Wrieless Bluetooth Control for XBOX CONTROLLER


conclusions/lessons-learned

So there were many issues with this robot. First of all, it wasn't very well built and when it drove around the upper tower that was to support the SCARA-style arm wobbled. This meant the LiDAR on top also wobbled so while SLAM navigation and other things were attempted and failed due to the wobbly LiDAR mount. This is also the reason the SCARA arm was not implemented. I think this came down to the choice of material, the PVC plastic was easy to work with but it was really floppy. Even if it was reinforced with the aluminum bars it wasn't particularly strong.


The other issues with this robot were that it wasn't very fast at getting anywhere, it required a massive battery to have any decent battery life whatsoever (18Ah lead-acid), and overall its size wouldn't have allowed it to really perform many home functions without immense difficulty (I doubt it would have been able to load the dishwasher).


Ultimately, I gave up trying to make this robot any better as there were so many issues with it since it was shoddily put together in a number of weeks that fixing it was going to be a pain. So I gave it to my brother and let him use it as a development robot, which it actually became really good at.


Towards the end of first semester I talked with a friend at the maker space where I built pathfinder and we came up with this conclusion:


"This design was a good first step as it made us realize many things about wheeled robots and robots in unknown environments. Mechanically, the system wasn't very god at navigation in any environment because it required all passing spaces to be larger than the diameter of the turning radius (or travel-radius). We acknowledge this is an issue with most robots, however we felt that a different system may perform better. One of the biggest mechanical issues with the Pathfinder system was versatility. The platform was a wheeled platform which means it could only traverse very certain types of terrain and was pretty much useless if it arrived at a staircase. There were other mechanical issues as well, but these were not listed due to the fact that they arose from build quality not design.


There were some other concerns with the system as well, including the controls and electronics base. On the controls/software side, the platform was based on ROS with an outdated controls algorithm for navigation based on SLAM. While highly affective, and super cool, SLAM isn't necessary the best way to localize a robot (at least the odometery-based SLAM we were using). The controls file system was also way too complicated and the Arduino-based motor drivers were difficult to interface with and deal with. The electronics system, because of the ratio of the power of motor to overall weight of the robot, was quite inefficient. To get anything more than a "decent" runtime, we needed a minimum of a 12V-18aH battery on the robot. This is a large and heavy battery and should not be required in an well designed robotics system.


Overall, what came out of the Pathfinder prototype was a new respect for how difficult making an intelligent, robust, and versatile robotics system actually is. We didn't see the Pathfinder design (at the time we decided to break from it) as a design we would iterate upon many times in the future to create a home robotics product (thought we may return to it in the future). We also saw the software network as not intelligently executed for what we were trying to achieve. We believed, overall, we could create a more innovative, and intelligent design."


Other things taken away, the Lattepanda is a really bad micro controller :) mostly because the custom file system and drivers make it hard to get traditional libraries for programming to interface with the devices on board!


Definitely a project that will return... learned a lot will see more of this in the future, likely in a very different form.


#robotics #difficult #systemdesign #slam #kinect #ros #design

16 views0 comments
© copyright 2019 | aditya mehrotra