TirgoPharma System Architecture: HITO 2 Discussion

Hey guys! Today, we're diving deep into the system architecture for the TirgoPharma project, specifically focusing on HITO 2. This is a crucial stage where we define and document the entire architecture, ensuring everyone's on the same page. Let's break down the key aspects and make sure we've got a solid plan.

HITO 2 Overview: Defining the System Architecture

The core objective of HITO 2 is to clearly define and document the system architecture for the TirgoPharma project. This involves creating a comprehensive blueprint that outlines the various components, their interactions, and the overall structure of the system. Think of it as the skeleton that holds everything together! This detailed documentation will serve as a guide for the development team, ensuring consistency and clarity throughout the project. We want to build something awesome, and it starts with a strong foundation.

Key Tasks and Deliverables

To achieve this, we have several key tasks to tackle. These tasks are designed to cover all critical aspects of the system architecture, from the high-level overview to the nitty-gritty details. It's like building a house – you need a blueprint, material list, and a solid construction plan!

• 2.a) System Overview Diagram and Module Descriptions: We need to create a general diagram of the system, detailing all the modules involved. This includes the UI (User Interface), the dispensing mechanism, the robot, voice interaction, and the MongoDB database. Each module will also have a clear description outlining its function and how it interacts with the rest of the system. This is our bird's-eye view of the entire operation.
• 2.b) Hardware Specifications: This involves specifying the hardware components required for the system. We'll need to detail the PC running ROS (Robot Operating System), the Raspberry Pi 3B for the dispenser, the robot base (whether a physical robot or a simulation), sensors, actuators, and the network infrastructure. Think of it as creating a hardware shopping list – we need to know exactly what we need.
• 2.c) UI/UX Preliminary Scheme: We'll design a preliminary UI/UX (User Interface/User Experience) scheme, outlining the user flow. This includes the steps from initial startup to selection, confirmation, status updates, and the optional mission execution. The goal is to make the system intuitive and user-friendly. It's like designing the user's journey through the system.
• Diagrams: We’ll include a diagram (using Mermaid syntax or an equivalent image) to visually represent the system architecture. Visual aids can make complex systems much easier to understand.
• ROS Topics Documentation: Documenting the planned ROS topics is crucial. This includes the name and message type for each topic, ensuring clear communication between different parts of the system. ROS topics are the communication channels that allow different modules to talk to each other.
• 4.b) Mitigation Strategy and Initial Tests: We'll outline a mitigation strategy and initial tests to address potential issues. This includes minimal tests, such as publishing topics manually, to verify the system's basic functionality. It's like a mini-dress rehearsal before the big show.
• Document Submission: Finally, we'll upload the document to the repository in the agreed-upon location. This ensures that everyone can access and review the architecture. We need to keep everything organized and accessible.

Acceptance Criteria (Definition of Done)

To ensure we've met the objectives of HITO 2, we have specific acceptance criteria. These criteria serve as a checklist to confirm that we've covered all the necessary bases. Think of them as our quality control measures.

• Module Description: The HITO 2 document must thoroughly describe all modules within the system. We need to know what each module does and how it fits into the bigger picture.
• ROS Topics Documentation: The document should list all the ROS topics that the UI will use, specifying who publishes and subscribes to them. This ensures smooth communication between the UI and other system components.
• Hardware Inclusion: The minimum hardware required, along with its function, must be clearly stated in the document. We need to know what hardware we're working with and its purpose.
• User Flow: A clear and understandable user flow from the web interface to the dispensing process should be outlined. The user journey needs to be intuitive and logical.
• Document Location and Naming: The document must be in the repository with a consistent naming convention (e.g., doc/Hito2_Arquitectura.md). This keeps everything organized and easy to find.

Deliverables

The concrete deliverables for HITO 2 include:

• doc/Hito2_Arquitectura.md (or Agreed-Upon Name): This document will contain sections 2.a, 2.b, 2.c, and 4.b, covering all aspects of the system architecture, hardware specifications, UI/UX scheme, and mitigation strategies.
• Diagram (Mermaid or Image): A visual representation of the system architecture, either embedded in the document or linked to it.
• List of Planned ROS Topics: A comprehensive list of all planned ROS topics, detailing their names and message types.
• Note on Docker Container for MongoDB: Information regarding the Docker container for MongoDB and the MONGO_URI variable.

References

To help guide our work, we have several references available:

• Hito 2 Statement (PDF): The original project statement for HITO 2.
• Preliminary Design of Hito 1: Insights from the previous phase of the project.
• Current Code of the tirgo_ui Package (ros_ws/src/tirgo_ui/): The existing codebase for the UI module.
• Environment Variables Used in the Container: MONGO_URI, ROS_MASTER_URI. These variables are crucial for the system's configuration.

2.a) Diagram and Description of System Modules

Alright, let's break down the system modules. We're talking about the fundamental building blocks of our TirgoPharma system. Think of these modules as the individual organs in a body – each has a specific function, but they all need to work together seamlessly. Our main goal here is to create a comprehensive diagram and detailed descriptions for each module, so everyone understands their roles and interactions. It’s like drawing up a map of the system, so nobody gets lost!

The Modules

We've got several key modules to cover:

• UI (User Interface): This is where the magic begins – the face of our system. The UI needs to be intuitive, user-friendly, and visually appealing. It's the primary way users interact with TirgoPharma, so we need to get it right! Think of it as the front desk of a hospital – it’s the first point of contact.

  • Description: The UI module handles all user interactions, from initial login to order confirmation. It needs to display information clearly, accept user input, and communicate with other modules. We’ll be using modern web technologies to build a responsive and engaging interface. Imagine a clean, easy-to-navigate dashboard that guides users through the process effortlessly. The UI needs to be designed for ease of use and accessibility, ensuring that users of all skill levels can operate the system without difficulty. We’ll focus on clear visual cues, intuitive navigation, and real-time feedback to enhance the user experience. Integration with the backend systems should be seamless, allowing for efficient data retrieval and processing. We’ll also need to consider error handling and provide informative messages to guide users through any issues. The goal is to create an interface that not only looks good but also feels great to use.

• Dispenser: This is the heart of our system – where the actual dispensing of medications happens. It’s a crucial component that needs to be reliable, accurate, and efficient. The dispenser is like the pharmacist in our analogy, carefully preparing each prescription.

  • Description: The dispenser module is responsible for the physical dispensing of medications. It interfaces with the hardware to retrieve the correct items and deliver them securely. This module needs to be highly accurate and reliable, as any errors could have serious consequences. We’ll incorporate safety mechanisms and checks to ensure the right medications are dispensed every time. The dispenser module will also need to track inventory and provide alerts when stock levels are low. Regular maintenance and calibration will be essential to maintain its accuracy and reliability. Think of it as a precision instrument that requires careful handling and monitoring. The module will communicate with the central control system to receive dispensing instructions and report its status. This includes information such as dispensing progress, errors, and maintenance needs. The design of the dispenser module will prioritize safety and efficiency, ensuring a smooth and reliable dispensing process.

• Robot: The robot is our mobile assistant, responsible for moving items around the system. It needs to navigate the environment safely and efficiently, delivering medications where they're needed. Think of the robot as the delivery person, zipping around the hospital to get medications to the right places.

  • Description: The robot module handles the physical transportation of medications within the system. It uses sensors and navigation algorithms to move safely and efficiently through the environment. This module needs to be robust and adaptable, capable of handling various obstacles and scenarios. We’ll be working on autonomous navigation and path planning to ensure smooth operation. The robot will communicate with the central control system to receive delivery instructions and report its position and status. Safety is paramount, so we’ll incorporate collision avoidance and emergency stop mechanisms. The robot’s design will also consider its capacity and speed, ensuring it can handle the workload efficiently. Imagine a nimble and reliable courier, always ready to deliver medications on time. Regular maintenance and battery management will be crucial to keep the robot running smoothly.

• Voice: Voice interaction adds a hands-free element to our system. It allows users to interact with TirgoPharma using voice commands, making it more accessible and convenient. The voice module is like having a helpful assistant who understands your verbal instructions.

  • Description: The voice module enables users to interact with the system using voice commands. This involves speech recognition and natural language processing to understand user requests and execute them. We’ll be integrating voice recognition APIs to provide a seamless and intuitive experience. Voice interaction can be particularly useful in scenarios where hands are occupied or a user is multitasking. The module will need to handle various accents and speaking styles, ensuring accurate interpretation of commands. We’ll also incorporate feedback mechanisms to confirm that commands have been understood and executed correctly. Think of it as a virtual assistant that’s always ready to help. The voice module will need to be secure and protect user privacy, ensuring that conversations are kept confidential. Regular updates and improvements will be essential to keep the voice recognition technology up-to-date.

• MongoDB: This is our database, where we store all the important information about medications, users, and system operations. It's the backbone of our system, providing a reliable and scalable way to manage data. MongoDB is like the library, storing all the essential information about our system.

  • Description: MongoDB is the database that stores all the system’s data, including medication information, user details, and logs. It’s a NoSQL database that provides flexibility and scalability, making it well-suited for our needs. We’ll be using MongoDB to manage large volumes of data efficiently and reliably. The database needs to be secure and protected from unauthorized access. We’ll implement backup and recovery mechanisms to ensure data integrity. Think of MongoDB as the central repository of knowledge, where all the critical information is stored and managed. Regular maintenance and optimization will be essential to maintain performance. The database will be accessed by various modules, including the UI and the dispenser, to retrieve and update information. We’ll need to design the data schema carefully to ensure efficient data retrieval and storage.

Creating the System Diagram

Now, let's talk about the diagram. We need a visual representation of how these modules interact. This diagram will show the connections and data flow between the modules, providing a clear overview of the system architecture. It’s like an architectural blueprint, showing how the different rooms in a building connect.

• Tools: We can use tools like Mermaid or draw an equivalent image to represent the system diagram. Mermaid is a great option because it allows us to define diagrams using text, which can be easily version-controlled and updated. Think of it as a way to write code for diagrams!
• Key Elements: The diagram should clearly show each module and the connections between them. We’ll need to indicate the direction of data flow and the type of communication (e.g., API calls, message queues). It's like a network map, showing how the different components communicate.

Importance of Detailed Descriptions

Why are detailed descriptions so important? Well, they ensure that everyone on the team has a clear understanding of each module's function and responsibilities. It reduces ambiguity and helps prevent misunderstandings down the line. It’s like having a detailed job description for each module!

• Clarity: Clear descriptions help team members understand the purpose of each module and how it contributes to the overall system.
• Consistency: Detailed descriptions ensure that we’re all on the same page when it comes to design and implementation decisions.
• Maintainability: Well-documented modules are easier to maintain and update over time.

2.b) Hardware Specifications

Alright, let's dive into the hardware specifications for our TirgoPharma system! This is where we nail down the physical components that will bring our architecture to life. Think of it as creating a shopping list for the hardware store – we need to know exactly what we need to build our system. From the brains of the operation to the muscle moving medications, we'll cover it all. So, grab your virtual wrench, and let's get started!

Core Hardware Components

We have several key hardware components that form the backbone of our system. Each component plays a specific role, and it’s crucial to select the right hardware to ensure optimal performance and reliability. It's like choosing the right ingredients for a recipe – each one is essential for the final dish!

• PC for ROS (Robot Operating System): This is the powerhouse that will run ROS, the software framework that controls our robot and other system components. Think of it as the central nervous system of our system, coordinating all the different parts.

  • Specifications: We’ll need a PC with sufficient processing power, memory, and storage to handle ROS and the associated software. A multi-core processor, ample RAM (at least 16GB), and a solid-state drive (SSD) are recommended for smooth operation. We also need to consider the operating system – Ubuntu is the standard for ROS development. The PC should have sufficient USB ports for connecting sensors and other peripherals. It's like the brain of the system, needing to be powerful and efficient. We’ll also need to ensure that the PC has adequate cooling to prevent overheating during intensive tasks. A dedicated graphics card can be beneficial for visualization and simulation purposes. The PC will serve as the central hub for communication and control, so its reliability is paramount.

• Raspberry Pi 3B for Dispenser: The Raspberry Pi will act as the control unit for the dispensing mechanism. It's a small but mighty computer that can handle the real-time control tasks required for dispensing medications accurately. Think of it as the local controller for the dispenser, ensuring precise operations.

  • Specifications: The Raspberry Pi 3B is a cost-effective and versatile option for controlling the dispenser. It has enough processing power for the task and provides the necessary interfaces for connecting to sensors and actuators. We’ll need to install a real-time operating system (RTOS) to ensure deterministic behavior. The Pi will communicate with the main ROS PC to receive dispensing instructions and report its status. Power consumption and physical size are also important considerations for the dispenser. We’ll need to ensure that the Pi is securely mounted and protected from environmental factors. The Raspberry Pi is like a mini-computer dedicated to dispensing operations, ensuring precision and reliability. We’ll also need to consider the storage capacity for local logs and configuration files.

• Robot Base (Physical or Simulation): Our robot base is the foundation for the mobile component of our system. It could be a physical robot platform or a simulation environment for testing and development. Think of it as the legs and wheels that allow our system to move.

  • Specifications: If we're using a physical robot, we need to consider its size, payload capacity, speed, and maneuverability. We’ll also need to think about its power source and battery life. If we're using a simulation, we need to choose a suitable simulation environment (e.g., Gazebo) and create a model of the robot. The robot base needs to be robust and reliable, capable of navigating the environment safely. We’ll also need to consider the type of sensors it has (e.g., LiDAR, cameras) for perception and navigation. The robot base is like the mobile platform for our system, allowing it to move and interact with its environment. We’ll also need to consider its communication interfaces for remote control and monitoring.

• Sensors: Sensors are the eyes and ears of our system, providing critical information about the environment and the state of the system. They're essential for tasks like navigation, object detection, and safety monitoring. Think of sensors as the system's perception, allowing it to understand its surroundings.

  • Types: We'll likely need a variety of sensors, including:
    • LiDAR: For mapping and navigation.
    • Cameras: For visual perception and object recognition.
    • Proximity sensors: For obstacle detection and collision avoidance.
    • Encoders: For measuring wheel rotations and robot movement.
  • Specifications: Each sensor has specific requirements in terms of range, accuracy, and resolution. We need to select sensors that are appropriate for our application and integrate them into the system. Sensor data processing and filtering are also important considerations. We’ll need to ensure that the sensors are properly calibrated and mounted for accurate readings. Sensors are like the system's senses, providing the necessary information for decision-making and control. We’ll also need to consider their communication interfaces and data rates.

• Actuators: Actuators are the muscles of our system, responsible for performing physical actions like dispensing medications and moving the robot. They translate commands from the control system into physical motion. Think of actuators as the system's limbs, allowing it to interact with the physical world.

  • Types: We'll need actuators for:
    • Dispensing: Motors, solenoids, and other mechanisms to dispense medications.
    • Robot movement: Motors to drive the wheels or other locomotion mechanisms.
    • Gripping: Actuators to grasp and manipulate objects.
  • Specifications: Actuators need to be precise, reliable, and capable of handling the required forces and speeds. We’ll need to select actuators that are compatible with our control system and power supply. Actuator control and feedback mechanisms are also important considerations. We’ll need to ensure that the actuators are properly sized and integrated into the system for optimal performance. Actuators are like the system's muscles, allowing it to perform physical tasks. We’ll also need to consider their power consumption and maintenance requirements.

• Network: A reliable network is essential for communication between the different components of our system. It allows the PC, Raspberry Pi, and other devices to exchange data and coordinate their actions. Think of the network as the communication channels connecting different parts of the system.

  • Requirements: We'll need a robust Wi-Fi network or Ethernet connection to ensure reliable communication. The network should have sufficient bandwidth to handle the data traffic from sensors, cameras, and other devices. Security is also a key consideration – we need to protect the system from unauthorized access. We’ll also need to consider the network topology and routing to ensure efficient communication. A well-designed network is like a communication highway, allowing data to flow smoothly between components. We’ll also need to consider network monitoring and troubleshooting tools.

Documenting Hardware Specifications

It’s super important to document all these hardware specifications clearly. This documentation serves as a reference for everyone on the team, ensuring that we're all on the same page when it comes to hardware selection and integration. It’s like creating a detailed parts list for our system.

• Key Information: The documentation should include details like:
  • Manufacturer and model number.
  • Technical specifications (e.g., processor speed, memory, power requirements).
  • Interface requirements (e.g., USB, Ethernet).
  • Wiring diagrams and connection details.
• Benefits: Well-documented hardware specifications:
  • Make it easier to procure the necessary components.
  • Help with system integration and troubleshooting.
  • Ensure consistency and compatibility.
  • Provide a valuable reference for future maintenance and upgrades.

2.c) Preliminary UI/UX Scheme

Okay, let's jump into the world of UI/UX (User Interface/User Experience) for TirgoPharma! This is where we map out how users will interact with our system, from the moment they log in to the confirmation of their order. Think of it as designing the cockpit of an airplane – we need to make sure all the controls are intuitive and easy to use, so the pilot (in this case, the user) can fly smoothly. Our goal is to create a seamless and user-friendly experience that makes using TirgoPharma a breeze. So, let's put on our UX hats and start designing!

User Flow: The Journey Through TirgoPharma

The user flow is the path a user takes through our system, from start to finish. We need to map out this flow carefully to ensure that each step is logical and intuitive. Think of it as planning a road trip – we need to know the route, the stops along the way, and the final destination.

Our preliminary UI/UX scheme will focus on the following key stages:

1. Startup: This is the initial point of contact with the system. We need to think about how users will log in, authenticate, and access the main interface. It's like the front door of a building – it needs to be welcoming and secure.

   • Considerations: We'll need to design a login screen that is both secure and easy to use. Multi-factor authentication could be an option for added security. We should also consider accessibility guidelines to ensure that users with disabilities can log in without difficulty. The startup phase sets the tone for the entire user experience, so it's crucial to get it right. We’ll also need to think about error handling and provide clear messages to guide users through any issues. The goal is to make the login process as smooth and painless as possible.

2. Selection: Once logged in, users will need to select the medications or items they need. This stage should be straightforward and efficient, allowing users to quickly find what they're looking for. It's like browsing the shelves in a pharmacy – everything needs to be clearly labeled and easy to find.

   • Considerations: We can use search functionality, categories, and filters to help users narrow down their choices. Visual aids, such as images of medications, can also be helpful. We’ll need to design a clear and intuitive interface for selecting items and specifying quantities. Accessibility is also important here – we should ensure that users with visual impairments can easily navigate the selection process. The selection stage is crucial for user satisfaction, so we need to make it as efficient and error-free as possible. We’ll also need to consider how to handle prescriptions and special requests.

3. Confirmation: Before dispensing, users should have a chance to review their selections and confirm their order. This step helps prevent errors and ensures that users get exactly what they need. It's like reviewing your shopping cart before checking out – you want to make sure everything is correct.

   • Considerations: We’ll need to display a summary of the order, including the items selected, quantities, and total cost (if applicable). Users should be able to easily modify their order or cancel it if needed. Confirmation messages and prompts can help guide users through the process. We also need to consider security and privacy – users should be able to verify their identity before confirming the order. The confirmation stage is a critical safety check, so we need to ensure that it’s clear and unambiguous. We’ll also need to think about how to handle payment information and delivery options.

4. Status: After confirmation, users will want to know the status of their order. This stage should provide real-time updates on the dispensing process, delivery, and any potential delays. It's like tracking a package you've ordered online – you want to know where it is and when it will arrive.

   • Considerations: We can use visual cues, progress bars, and notifications to keep users informed. Real-time updates can help manage user expectations and reduce anxiety. We should also provide contact information for support in case users have questions or concerns. The status stage is crucial for building trust and transparency, so we need to provide accurate and timely information. We’ll also need to consider how to handle exceptions and communicate any issues that arise. The goal is to keep users informed and engaged throughout the dispensing process.

5. (Optional) Mission: This stage may involve additional interactions, such as tracking the robot's movement or providing feedback on the delivery. It's like following the delivery driver on a map – you can see exactly where they are and when they'll arrive.

   • Considerations: If we're using a robot for delivery, we can provide a map interface that shows its current location and estimated time of arrival. Users may also want to provide feedback on the delivery experience. This stage can enhance user engagement and provide valuable data for system optimization. We’ll also need to consider security and privacy – users should be able to track the robot’s progress without compromising the safety of the system. The mission stage adds an extra layer of interactivity and transparency, making the system more engaging for users.

Key UI/UX Elements

To make our UI/UX scheme effective, we need to think about the specific elements that will make up the interface. These elements should be consistent, intuitive, and visually appealing. It's like choosing the right furniture for a room – it needs to be functional, comfortable, and aesthetically pleasing.

• Layout: The layout should be clean and organized, with clear navigation and visual hierarchy. We need to guide users through the interface logically and efficiently. A well-designed layout can make a big difference in user satisfaction.
• Icons: Icons can provide visual cues and make the interface more intuitive. We should use consistent and recognizable icons throughout the system. Icons are like visual shortcuts, helping users quickly understand the function of different elements.
• Typography: The font choices and text sizes should be legible and easy on the eyes. We need to ensure that text is readable on different devices and screen sizes. Typography is crucial for readability and overall visual appeal.
• Color Scheme: The color scheme should be consistent and visually appealing. We should use colors to highlight important elements and create a positive user experience. Colors can evoke different emotions and influence user perception.
• Feedback: The interface should provide feedback to users to let them know what's happening. This includes confirmation messages, error alerts, and progress indicators. Feedback is essential for building trust and transparency.

Tools and Techniques

We can use various tools and techniques to design and prototype our UI/UX scheme. These tools can help us visualize the interface, test different layouts, and gather feedback from users. It's like using a CAD program to design a building – we can create a virtual model before we start construction.

• Wireframing: Wireframes are low-fidelity mockups that show the basic structure and layout of the interface. They're a quick and easy way to visualize the UI without getting bogged down in details.
• Mockups: Mockups are higher-fidelity prototypes that include visual design elements like colors, fonts, and icons. They provide a more realistic representation of the final interface.
• Prototypes: Prototypes are interactive mockups that allow users to click through the interface and simulate the user flow. They're a great way to test the usability of the design.
• User Testing: User testing involves observing real users as they interact with the interface. This provides valuable feedback on the usability and effectiveness of the design.

4.b) Mitigation Strategy and Initial Tests

Alright folks, let's talk about our mitigation strategy and initial tests for TirgoPharma! This is where we plan for the unexpected and make sure we have a backup plan in place. Think of it as having a first-aid kit on hand – we hope we don't need it, but it's always good to be prepared. Our goal is to identify potential issues early on and develop strategies to address them, ensuring a smooth and reliable system. So, let's put on our problem-solving hats and get ready to test things out!

Identifying Potential Issues

Before we can mitigate issues, we need to identify what could go wrong. This involves brainstorming potential problems and thinking about their impact on the system. It's like playing a game of