MARVIN’s Parts
MARVIN’s design is strong influenced by the TurtleBot. There is good reason for this — the TurtleBot can be built from off the shelf hardware, it is modular, and relatively simple to build. All of these are great advantages for a software guy with little experience putting together complicated electronics.
I will be basing my design around a few major components — smaller components like connector cords or USB hubs will be briefly touched on at the end of the article.
iRobot Create 2
Serving as MARVIN’s base will be the iRobot Create 2. This was not my original choice when I set out to design the Robot — I had originally wanted a far more customized base with its own drive train. The problem with this approach was simply that I had no idea how to correctly construct such a thing with the tools I had without vastly exceeding the budget I had set aside for myself. So after some research, I decided that at least for the purposes of creating a prototype I would go with this hardware.
The Create 2 has a lot of functionality out of the box that makes the prototype stage easier.
- It already has its own motors, actuators, wheel encoders, and sensors built in.
- There is already a lot of support for interfacing with the device in ROS. The create_automy ROS package provides the drivers, mesh files, interfaces required to easily integrate the iRobot Create with existing ROS packages.
- It was significantly cheaper than trying to obtain all the tools and associated parts that would have been required by original designs. Plus it easily connects to the control board using a USB to Serial connector that comes with the Robot.
NVIDIA Jetson TX2
MARVIN’s main computing unit is the NVIDIA Jetson TX2 development board. This was chosen for a few simple reasons:
- I was able to get a discount on the device through the Udacity Robotics Nanodegree.
- It provided on-board GPU support which will allow me to take advantage of Object Recognition models built using Deep Learning ( and any custom models I decided to build for myself using TensorFlow / Keras).
- It is able to run Ubuntu Linux and ROS Kinetic.
The Jetson is not without its downsides however. It only has one USB port, which means I’ll need to make use of a USB hub in order to connect to all its components. Its GPIO pins are not well documented and only a few of them seem to work “out of the box” as actual GPIO — others appears to have other purposes assigned to them by default. These can be reconfigured it seems, but it requires far too much fiddling with the installation to be worth the trouble (for my application). Finally, the only way to provide power to it is via a barrel plug connector, which has proven to be far more difficult to find in quantities of one online than I would have originally thought.
Compared the advantages listed, combined with the practical matter that I already have one on hand, these downsides can be worked with.
Orbbec Astra
To make full use of RTAB Map MARVIN needs access to a RGBD camera. Three cameras where considered for this purpose. Originally I had wanted to use the Microsoft Kinnect, but it seems that the connecting coord I would need is no longer available at a reasonable price (most prices I found put the cost of the cord well beyond the price point of the Kinnect itself). Another option was the Intel RealSense camera — which while a very good piece of machinery by all accounts, was heavily in back order. The camera seen in the picture, the Orbbec Astra offered comparable performance, a microphone (which did not appear to be included in the other options spec sheets), and ROS support out of the box via the ros_astra_camera package. Even better, it was available within a couple of days of making the purchase which satisfied my lack of patience!
The 3D Depth camera will also double as MARVIN’s laser range finder through the use of the pointcloud_to_laserscan ROS package. This allows me to skip the cost of a laser range finder (which started at the same price as this camera) and reduce the amount of hardware needed for MARVIN to function. So far, in the Gazebo simulations, this has worked out well, however experiments with the physical robot may force me to re-evaluate this decision.
NEXUS 4P Cell Phone
I have to admit, this choice was made more for convenience than suitability. For MARVIN to meet all my requirements, it is going to need a display screen (especially for the Telepresence features). It would also be a nice to have if it could have a touch screen interface as well so users would not have to be limited to only using the Voice UX (which would not allows be appropriate). In a perfect world, I’d purchase a TFT touch screen and integrate that into MARVIN’s designed. However these can be tricky to work with, and frankly aren’t free. My old cell phone however has the advantage of already having a working display screen, it can connect to the TX2 via a wireless interface, and has a working touch interface. In addition to all these, I already own it, and thus am not required to put any further expense into the prototype.
A final side advantage to using a cell phone is that it allows me to test a “nice to have” use case that I had been considering. For the Telepresence features, it would be nice if a user could just place whatever cell phone they had into a preformed “holder” and use that as the display screen for telepresence. They could then flip between using the app as a low end video chat feature and as a remote control for the robot. I am not entirely sure of the utility of this feature, but it cannot hurt to have another possible use case for MARVIN prepared for.
Miscellaneous Parts
The parts will need a frame to connect them all together. Following the TurtleBot’s example, this will primarily be made of plywood platforms stacked on top of each other. There will be three platforms:
- Jetson TX 2, its power supply, and a generic USB hub.
- The “Table” which will allow MARVIN to carry objects from location to location on behalf of its owner.
- This is a much smaller “platform”, it will house the Orbbec Astra camera and the holding apparatus for the cell phone. I am still on the fence on how to best configure this platform, but it will likely be raised well above the others to allow people in MARVIN’s environment to easily interact with it.
Next up I’ll start going over the software that makes MARVIN work, both what’s currently completed, whats in progress, and planned for modules.
That may take a few articles actually …
