Introduction

In previous discussions, we touched upon the foundational aspects of this project. It is now time to delve into the heart of our endeavour, providing a detailed exploration of the specific requirements guiding our design choices for the robotic kit. This deeper insight will reveal the rationale behind our decisions, offering a clear perspective on our objectives.
I have already shared a bit about what we need from this project in earlier discussions. Now, let’s dive deeper into the heart of what I’m aiming to create. We’ll explore the specific requirements that are shaping our design choices for the robotic kit, giving you a closer look at what drives our decisions.

Missions

The missions encapsulate the primary functions expected of the robotic kit, with an emphasis on excellence in performance. Following our earlier discourse, we have delineated three mission requirements for the robot:
As previous discussed there are three missions requirements for the robot.
1) Environment Navigation: Seamlessly moving through its Environment
2) The robot will avoid obstacles: Identify and navigate around hazards to ensure safe passage
3) The robot will follow lines: Smoothly follow lines
These missions will be further clarified as part of the user requirements

Key User Requirements

Listing all of the requirements within this post would be impractical, beyond the scope of this post and uninteresting. Those interested in seeing the full document with link provided at the end of this post.
Instead, we will be looking at more relevant requirements that will be defining the robotic system.

Mission Requirements

The initial set of requirements pertains to the missions outlined above, aiming to further specify the operational parameters of the robotic kit.

General Requirements

These are requirements are applicable to all three missions.

Goal	Target
Operate in a human environment	room, house, large room or outdoors
Move by self power	Have its own means of propulsion
Move around on the ground	Carpet, tiles, wood or concrete
Operate in optimal outdoor conditions	Dry weather with no or minimal water/dampness on the ground

Navigation Requirements

Requirements detail the expected navigation capabilities of the robot:

Goal	Target
Be able to use different types of route planning algorithms	VRF, bug, etc
Be able to use user defined waypoints for navigation	Coordinate points on a map
Able to tell where the robot is	coordinate point on a map, relation to where it started
Be able to tell how fast the robot is moving	RPM, m/s etc
Be able to tell which direction the robot is heading	Bearing
Be able to measure individual wheel speed	RPM measurement on each wheel

Obstacle Avoidance Requirements

Specifications for navigating around obstacles include:

Goal	Target
Able to detect obstacles from reasonable distance	10-20cms
Use algorithms or other methods to move around obstacles and reach the end waypoint	Bug, VRF or others
Not hit obstacles
Not get stuck avoiding obstacles

Line Following Requirements

Specifications for navigating around obstacles include:

Goal	Target
Be able to detect a line	thickness of a ballpoint pen to a blackboard marker
Be able to detect colours	At a minimum Black, Blue, Red and Green
Able to follow lines smoothly	PID style of control
Be able to turn around corners	Maybe 90deg turns? most definitely curved turns.
Potentially be able to transition from one line to another	i.e. go from black to red
Be able to find the line and start moving along it

Robotic Control Systems

This is one of the key areas where I aim to improve from my previous robot designs. Instead of just soldering wires and sticking wires to a Raspberry Pi, I want to create a truly modular system that can allow for effective modularity. To realise this ambition I will need robust requirements to allow for

Goal	Target
The system will use a databus to interface with each modules	SPI, I2C, UART or others
There will be a use of standard IO ports for interfacing with modules	RJ11, RJ45 and/or USB type C
There should be a way for the user to interface with the robotic system	Buttons and other methods of inputs
The robotic system should inform the user	Digital displays, lights, sounds or other means
The system shall be able to monitor failures and self calibrate	Use BITE or other methods checking

Power Distribution

Power distribution was an issue with my last two robot designs as they both used AA cell batteries which would die quickly. This was neither economical nor was it sustainable as I had to keep replacing the batteries. The new requirements reflect the lessons learnt from my previous ventures and should allow for further expandability.

Goal	Target
Power system should distribute power on a rail
There should be a single voltage and amp
The power input should be agnostic to country or location	I.E. use USB type C for power input
There should be a switch to turn on or off the power distribution to modules
There should be a switch to turn on or off the whole robot system
Have power converters in the modules	power regulators
Monitor power distribution

Sustainability

I don’t have the resources of large institutions for designing and building this robotic kit. which limits my options. Therefore, my goal is to ensure that I follow the principles of right first time with as little waste as possible and future reusability in mind. Thus the following requirements are meant to reflect some of this.

Goal	Target
Waste as little material during design and development	up to 20% addition material use
The energy source should be rechargeable and easily replaceable	Not use things like AA cells nor fuel cells. Not store energy source in a way that not accessible
There should be attempts made to try and reuse plastic for 3D printed parts
Before constructing, a model of the robot should be made to test the robots ability function	CAD model and a Software model of some kind

Conclusion

In this post, we’ve covered the main goals and design ideas behind our robotic kit project, focusing on how it needs to be functional, adaptable, and sustainable. We’re doing more than just building a robot; we’re creating a versatile tool designed to tackle specific problems. I’m pretty new to setting up requirements from a customer’s point of view, especially when it comes to sustainability, so there’s a lot for me to learn as I go along. I expect to get better at including these considerations in future projects.

Keep in mind that what we’ve discussed here are the customer’s requirements, which might not cover everything for the final design. We’ll need to dig deeper and refine these ideas to make sure the end product is exactly what I’m aiming for. So, in the next post, we’ll start looking into the System Level Requirements, taking another step forward in our project.