This was a project that involved designing a delivery robot, brilliantly named ADR for Autonomous Delivery Robot, that would navigate autonomously. The scope of this project was limited to a small location on campus.
Project Description
Background
With the shift towards online shopping, the demand for delivery services has increased. This has led to a rise in the number of delivery robots being used to deliver packages. These robots are designed to navigate autonomously and deliver packages to customers.
In 2021, when this project was initiated, several companies had began development on delivery robots, including Starship Technologies, Nuro, and Amazon.
The IEEE HSRW project team decided to tackle this problem and gain relevant experience for future career opportunities. Additionally, such a project would allow us to apply our technical knowledge and experience working with a team again after a year of remote work.
Problem Definition
Being a student team with limited resources and experience we decided to limit the scope of the project to a single delivery task. This task was to deliver mail from Building 01 across the Spoy to Building 07
Additionally, some measurable requirements were set for the project. These requirements were:
| Requirement | Value |
|---|---|
| Range | 6km |
| Robot Dimensions | 500mm x 400mm x 400mm |
| Min Payload Weight | 10kg |
| Speed | 3km/h |
These values were arrived at after a considerable amount of head-scratching and sometimes even actual research. The speed for example was limited by regulations and safety considerations.
Team
We had a multidisciplinary team of 9 members, consisting of Mechanical, Mechatronics, and Electrical Engineering students. I was the team lead and was responsible for the overall project management and coordination. I was also responsible for aspects of the mechanical design, embedded system, and software development.
Design
The design process for this project was split into four main systems - the powertrain, the chassis, the embedded systems, and the software. Each of these systems had to be designed with the other systems in mind, and the designs were iterated on until a satisfactory solution was found. The design process for each of these systems is described below.
Powertrain Design
The powertrain was selected and sized first based upon the requirements defined during the problem definition phase and some additional assumptions.
| Assumption | Value |
|---|---|
| Robot weight - mR | 20kg |
| Nominal speed - vN | 3 km/h |
| Maximum speed - vmax | 6 km/h - 5/3 m/s |
| Maximum slope incline - | 25 ° |
| Acceleration time - t^{acc} | 2 s |
| Coefficient of rolling resistance - cRR | 0.01 (pavement) |
A calculation of the required torque and power was performed using the following formulae:
| Assumption | Value |
|---|---|
| Load Inertia | JL = (m + (½ × mW × nW)) × (R)2 |
| JL = (20 [kg] + (½ × 1 [kg] × 4)) × (0.15 [m])2 | |
| JL = 0.4950 [kg·m2] | |
| Required Speed | Nw = (60 × vn) / (2 × π × R) |
| Nw = (60 × 1.667 [m/s]) / (2 × π × 0.15 [m]) | |
| Nw = 106.1 [r/min] | |
| Acceleration Torque | Ta = JL × (NW / (9.55 × ta)) |
| Ta = 0.495 [kg·m2] × (106.1 [r/min] / (9.55 × 2 [s])) | |
| Ta = 2.750 [N·m] | |
| Load Torque | F = (m + mW × nW) × g × ( sinα + cRR × cosα )) |
| F = (22 [kg]) × 9.81 × ( sin25 + 0.01 × cos25 )) | |
| F = 93.17 [N] | |
| TL = (F × R) / η | |
| TL = (93.17 [N] × 0.15 [m]) / 1.0 | |
| TL = 14.1 [N·m] | |
| Required Torque | T = (Ta + TL)T = (2.750 [N·m] + 14.1 [N·m]) |
| T = 16.85 [N·m] | |
| Power | P = T × (NW × 2𝝅/60) |
| P = 16.85 [N·m] × (106.1 [r/min] × 2𝝅/60) | |
| P = 187.22 [W] |
Next, the drivetrain configuration was selected from the following options:
- Single-wheel drive
- Synchro Drive
- Differential Drive
- Ackerman Steering
A differential drive was selected for the project. This was because it was the simplest drivetrain configuration to implement, as it does not require rotation of a driven axis. Also, it would allow for the robot to be able to turn in place and be able to navigate uneven terrain.
A quad motor setup with independently driven wheels was selected for the project. This made the mechanical design simpler while making it easier to maintain. It also allowed us to use smaller and therefore cheaper motors. The tradeoff was the more complex motor control setup.
Motor requirements were calculated using the following formulae:
| Wheel Torque (4 wheel traction) | TW = T / 4 |
| TW =16.85 [N·m] / 4 | |
| TW = 4.213 [N·m] | |
| Wheel Torque (3 wheel traction) | TW = T / 3 |
| TW = 16.85 [N·m] / 3 | |
| TW = 5.617 [N·m] | |
| Power (4 wheel traction) | PW = P / 4 |
| PW = 187.22 [W] / 4 | |
| PW = 46.805 [W] | |
| Power (3 wheel traction) | PW = P / 3 |
| PW = 187.22 [W] / 3 | |
| PW = 62.407 [W] |
Considering extreme conditions, the peak motor requirements are 5.617 [N·m], 62.407 [W], and 106.1 [r/min].
To power these motors for the requisite distances a battery is required.
With four motors consuming a total of 249.63 watts at 24 volts, it was calculated that a 600 watt-hour (Wh) battery pack would be needed to operate the motors for two hours with a 95% efficiency assumption. This translates to a 25 ampere-hour (Ah) or 25000 milliampere-hour (mAh) battery capacity. Lithium-ion batteries were chosen, specifically the 21700 3.7V 4800mAh cells, arranged in a 7S7P configuration, providing 25.2V and 33.6Ah. These batteries were preferred over alternatives like lead-acid or nickel-metal hydride due to their higher energy density, lighter weight, longer cycle life, and better power-to-weight ratio, making them more suitable for a small wheeled robot that needs efficient and reliable power for extended operation.
Step-down converters were included to provide 5V for the embedded system components.
Chassis Design
Considerations for the chassis design included:
- Material availability
- Tools available in the workshop
- Ease of prototyping and Alterations
- Ease of maintenance
The design was divided into 3 distinct subsystems:
- The Frame
- The Suspension
- The Body
Frame
The frame was designed to be a simple box frame as this would be simplest and would require the least amount of machining. Instead of using steel tubing for the frame, aluminium extrusions were used as they were lighter, easier to work with, and would not require welding. Additionally, the extrusions would allow for easy mounting of components and would allow for easy alterations to the design.
80/20 framing system was used with profiles of 40mmx40mm. Brackets and fasteners were used to join the profiles and mount additional components including the suspension. The frame was designed to create two 'compartments' - the payload on top and the batteries and electronics on the bottom.
Suspension
Different suspension set-ups were considered including double wishbone, MacPherson strut, and trailing arm, but in the end a simple swing arm suspension was selected. This meant that each of our four wheels were independently suspended. This would allow for the robot to be able to navigate uneven terrain and climb over obstacles like sidewalks.
Steel swing arms were to be designed and fabricated, and bicycle shock absorbers were to be used. The shock absorbers were selected as they were readily available and tunable to handle the as yet unknown weight of the robot and payload.
Wheel carriers were also designed to be fabricate out of sheet steel. These would include bearings to mount to the swing arm and hold the motor shaft. Holes were included to mount the individual wheel motors.
Pneumatic rubber wheels were used as they were readily available and would provide a good balance between traction and stability. The would also help to absorb shocks and vibrations from the terrain, especially for the motors which were unsprung.
Body
The body design was left for future teams to decide once everything was finalized. A concept image was created to show an idea of what the robot could look like. This concept included a plastic body that attached to the frame and protected the electronics and batteries from the elements. It also included a strut supported hatch that would allow access to the payload compartment.
Embedded Systems Design
The embedded system was designed in conjunction with the software requirements. We considered two options:
- Off the shelf controller like PixHawk running opensource ArduPilot software.
- Embedded PC and general purpose microcontroller running custom software and ROS.
As the purpose of the project was to gain experience with embedded systems, we decided to go with the second option. This would allow us to gain experience with embedded Linux and ROS.
The embedded system was designed to be modular and consisted of two main components - the embedded PC and the microcontroller. The embedded PC was selected to be a Jetson NANO as it was readily available and had the required processing power. The microcontroller was selected to be an Arduino Nano as it was cheap and had the required IO.
The two components were connected via a serial connection. The microcontroller would handle the low level motor control and sensor interfacing, while the embedded PC would handle the high level navigation and path planning.
As the software was still in development, the embedded system was designed to be modular and easily reconfigurable, with all the sensors we would need. Individual selections were made for each of the sensors based on availability and cost:
- 9 DOF IMU
- GPS
- Wide-angle camera
- LiDAR
Software Design
Software Design was split into 5 distinct subsystems:
- Navigation to get the heading the robot should move in.
- Dashboard UI to monitor and control the robot
- Routing to plan the path the robot should take to its destination.
- Sensors and Control to interface with the embedded system.
- Simulation to test the software without the robot.
Navigation
The navigation could be done by many different approaches like:
- Simultaneous Localization and Mapping (SLAM) with point clouds generated by LiDAR
- Deep Learning based object detection and road segmentation
- GPS and compass based navigation
- Computer Vision based obstacle detection and avoidance, and road following
We hoped to try out all of these approaches, but due to time constraints we were only able to implement the last one. This was done using OpenCV and a simple PID controller. The robot would follow a white line on the ground and avoid obstacles using a simple obstacle avoidance algorithm. This was ideal as there were already tactile paving markers on the ground that could be used as the line to follow. The output of the navigation system was a Twist message that would be passed to the microcontroller.
Dashboard UI
A simple web server was created to host a dashboard UI. This UI would allow the user to monitor the robot's status and control it. It also had a leaflet map view that would show the robot's position. Roslibjs was used to pass messages to the ROS system using a rosbridge_server node.
Routing
Routing is a very complex challenge and also requires a lot of map data. As such, we decided to use an existing routing service. Graphhopper was selected as it provided a generous free tier and was easy to use with a highly customizable REST API. The list of points returned by Graphhopper was then passed to the navigation system point by point as intermediate goals.
Sensors and Control
rosserial was used to interface with the embedded system. This allowed us to use ROS topics and services to communicate with the microcontroller. The microcontroller would then handle the low level motor control and sensor interfacing. The navigation system would publish the required Twist message that the microcontroller would then translate to motor commands. The microcontroller would also publish the sensor data to the ROS system.
Simulation
As the robot was still in development, a simulation was created to test the software without the robot. Gazebo was used to simulate the robot and the environment. The simulation was not very accurate as we did not have an exact robot model and the environment was generic. However, it was sufficient to test the basic navigation and routing systems.
Conclusion
This project allowed us to tackle a complex problem and gain experience with mechanical design, embedded systems, software development, and the challenge that integrating all of these systems can be. Due to time constraints, the building of the robot and implementation of the software were left to future IEEE HSRW teams.