FIORA

Land on a project idea and validate whether our planned hardware and software stack can realistically support an autonomous indoor delivery robot.

What we did

• Brainstormed multiple robotics project directions for the 9-week build. FIORA — an autonomous indoor material delivery robot that:
  • Transports documents, materials, and small packages between designated locations
  • Navigates indoor environments autonomously
  • Detects and avoids obstacles
  • Provides a touchscreen interface for delivery requests and robot status
  • Offices
  • Warehouses
  • Hospitals
  • collage
  • Other indoor facilities
  • Raspberry Pi
  • Arduino UNO R4 or ESP32 S3 PICO
  • 4 × encoder geared motors
    • GB37 12V 60 RPM
  • 4 × mecanum wheels
  • 2 x L298N motor drivers
  • SLAMTEC RPLIDAR A1M8
  • IMU MPU-6050
  • DWIN 7-inch touchscreen
  • ROS 2 Jazzy
  • SLAM Toolbox
  • Nav2
  • LiDAR-based mapping
  • Encoder-based odometry
  • IMU-based motion feedback
  • Explored Telegram as the communication interface for FIORA.
  • Delivery request
  • Destination selection
  • Delivery status updates
  • Battery/status notifications
  • Delivery completion notification

Problems and blockers

• LiDAR
• Wheel encoders
• IMU
• ROS 2
• Motor controller
• Odometry
• Wheel synchronization
• Motion control
• The foam-sheet prototype chassis needs reinforcement around motor mounting points.
• The battery must safely supply both motors and electronics.
• The DWIN touchscreen requires separate UI design and DGUS configuration.
• LiDAR-based mapping and navigation still need to be validated on the actual robot.
• Telegram Communication
  • Internet connection is required for Telegram communication.
  • Telegram API/token security must be maintained.
  • Network delays may affect command and status updates.
  • Raspberry Pi must stay connected and online.

Decisions

• Finalized the project name: FIORA
  • Autonomous indoor material delivery
  • ROS 2 + LiDAR + SLAM Toolbox + Nav2
• Selected TB6612FNG motor drivers for the prototype.
• Selected YDLIDAR X2 for indoor mapping and navigation.
• Selected a DWIN 7-inch touchscreen for the user interface.
• Decided to keep advanced features modular so they can be added after the core system works.
  • 4G connectivity using SIM7600
  • Charging dock
  • Delivery queue
  • QR-based delivery confirmation
  • Smart cargo locking
  • Voice notifications

Next week

• Fabricate the chassis
• Install motors and mecanum wheels
• Mount motor drivers
• Individual motor operation
• Encoder feedback
• Mecanum wheel movement
• ESP32 motor control
• Begin communication between the ESP32 and main computer.
• Set up the ROS 2 environment for LiDAR and navigation testing.

Links

• Code:
• Photos / CAD:

Weekly logs

Start with Week 1 and fill one in each week.

Goal this week: starting to build a prototype of base

What we did

Our model was inspired by Bella, a delivery robot, so we took a similar design as our reference. We planned to start by building the base using a foam sheet. We cut the sheet into a circular shape with a radius of 40 cm to form the base of the model and took measurements of the mecanum wheels. We then cut the sheet according to the wheel measurements which the length (L) is 90mm and width (W) 34mm , completing the basic base structure of the prototype.

the base. At the same time, we realised that our motor-to-wheel hub adapter could not directly fit into the wheel hub. We got stuck at this stage, so we searched online for a suitable adapter. However, the available options were too expensive, so we decided to make one ourselves.

We then started designing a custom motor-to-wheel adapter. We started exploring CAD, and it was a long process.

Problems and blockers

• The wheel adapter did not fit the wheel hub, and the available adapters were too expensive.
• Designing a custom adapter in CAD took extra time and required us to learn new CAD techniques.

Decisions

• decided to design a custom motor-to-adapter instead of buying.
• Continued exploring CAD to create a suitable adapter.

Next week

• Complete the CAD design of the custom adapter.
• 3D print and test the adapter.
• Design the motor mounting structure and continue assembling the prototype.

Links

Goal this week: continue building the FIORA prototype and work on the motor mounting and wheel adapter.

What we did

We continued working on the design of the motor-to-wheel adapter. First, we searched online for a CAD model of the wheel adapter on platforms like GrabCAD. We found a CAD model with a design similar to our wheel adapter and printed it.

However, we then faced another problem. The measurements of the printed design were different from the measurements required for our wheel, so the adapter was too large and could not fit properly. This was our second mistake. We searched again for a CAD file with the exact required measurements, but unfortunately, we could not find any suitable existing design. As a result, we decided that designing our own adapter from scratch would be the most practical solution. we stared to make a 3D model of the adapter. First, we measured the dimensions of the hexagonal hole at the center of the wheel to design a suitable coupler. We then used these measurements to create and print the coupler. we joinde the coupler to the center hole, it was fit but shoud give a push aslo it was too tight. Then it broke very quickly. When we checked why, we realised that we had designed it to be too thin, which made it weak and unable to withstand the load...

We modified the design further and started designing the motor hub as well, but it did not fit properly. We checked the measurements again to make sure there were no measurement errors, and everything was correct. We then researched why this variation was occurring and tried several different designs. We printed and tested many models, but they failed each time. In total, we designed and printed more than 15 different models, with each attempt helping us understand and improve the design

We realized that the main problem was that whenever we printed a CAD model, the actual printed part would come out around 1 mm bigger or smaller than the measurements we designed. We wanted to understand why this was happening, so we looked for someone who had more experience with 3D printing. That’s how we ended up talking to Kurian, the COO of TinkerSpace.

Kurian explained that the problem was mainly due to tolerance in 3D printing. The dimensions of a printed part may not always be exactly the same as the CAD model because factors like the printer, material, and heating can affect the final size. So, we need to adjust the measurements slightly and test them to get the right fit. There is no fixed value that will work perfectly every time, so it becomes a trial-and-error process. Based on this, we decided to reduce the measured dimension by around 1 mm and print it again. If it fits, we can use that result to further adjust the design. We understood that making the adapter is going to take several rounds of designing, printing, testing, and modifying until we get the perfect fit. Finally, we printed a coupler that fits on both sides. It is not a perfect fit yet, but it can be adjusted and works well enough for us to move forward. We decided to stick with this design and move on to the next step,which is designing a mount for the motors and completing the base.

Problems and blockers

• The first CAD model we printed was bigger than our wheel, so it didn't fit properly.
• We couldn't find an existing CAD model with the exact measurements we needed.
• Our first coupler was too thin, so it broke when we tested it with the wheel.
• Even though our measurements were correct in CAD, the printed parts were coming out slightly different in size.
• We had to try more than 15 different designs and prints before getting a coupler that was usable.
• At first, we didn't know that 3D-printing tolerance could make such a big difference when trying to get a tight fit.

Decisions

• Since we couldn't find a suitable existing model, we decided to design the wheel adapter ourselves.
• We decided to keep some tolerance in the design instead of using the exact measured dimensions.
• We will continue with the process of designing, printing, testing, and changing the design until we get the fit right.
• For now, we are going ahead with the current coupler because it fits well enough on both sides and allows us to continue with the rest of the robot.
• We decided to move on to the motor mounting and start working on completing the base.

Next week

• Start designing the motor mounts for the GB37 motors.
• Figure out the best position for the motors on the base.
• Make some improvements to the current wheel coupler so that it fits better and is stronger.
• Print the motor mounts and test them with the motors.
• Continue working on and completing the FIORA base.
• Test the motors, couplers, and wheels together to see how everything works under load.
• Make changes to the designs based on what we find during testing.

Links

`# Week 3

Goal this week: # Week 3

Continue working on the FIORA prototype by designing the motor mounting. Our main focus was to get the wheel and motor connection working properly so that we could move forward with completing the base. and start the electrical side

What we did

-We started working on the motor mount for the motors. At first, our plan was to simply buy a motor mounting bracket.

At first, we thought that all we had to do was screw the motor mount directly onto the base. But since we were already spending a lot of time getting the motor-to-wheel adapter and the coupler right, we had already started learning more about 3D modelling and 3D printing. So we thought, why not try designing the motor mount ourselves as well? That way, we could make it according to our own requirements instead of depending on a ready-made mount.

So, we started designing the motor mount. First, we took the measurements of the motor's front face plate and the front-end shield and started designing the mount based on those measurements. Our first priority was to make sure that the front part of the motor would fit correctly into the mount. Only after getting that part right would we design the rest of the mount to attach it to the base.

So, we made a basic model and started with a 3D print to test the fitting. Once the model was printed, we placed the motor into it and checked how well it fitted. It was fitting properly, which was a good sign. Now that we knew the motor could fit into the mount, we could continue working on the design a new model to attach the mount to the base.

<div align="left">

</div> So, we completed the first stage of the mounting. Now we had to attach the mount to the base. First, we decided to make a square-shaped mount using the same dimensions as the previous model. The motor was fitting perfectly, but it was too tight. so we sanded it with sandpaper

Another major problem was that we had taken the full length of the motor while designing and printing the mount. Because of this, the mount was covering almost the entire motor. So, we made another smaller square-shaped mount, but that one turned out to be too small. We had to try again, and this time we thought, why not try a different shape for our model? So, we designed a triangular-shaped mount, and this one became more suitable for our model.

We placed the motor into the mount, connected the coupler to the adapter, and then placed the whole setup on the base. That's when we found another problem. The length of our coupler was too big, so we had to move the motor mount a little further back to get the wheel into the correct position.

But when we moved the mount backwards, the mounts on the left and right sides started touching each other. Because of this, the motor and wheel could not be positioned properly, and the wheel was no longer aligned with the wheel cutout in the base. The wheel was supposed to sit inside the cutout and come through it properly, but because of the mounting position, it was getting blocked and could not fit into the cutout correctly.

So, we realized that we had to redesign the coupler first before continuing with the motor mounting.

Problems and blockers

• The first square-shaped motor mount was fitting the motor, but it was too tight.
• The motor mount was covering almost the entire length of the motor.
• The smaller square-shaped mount turned out to be too small.
• The coupler was too long, which forced us to move the motor mount backwards.
• Moving the mount backwards caused the left and right mounts to touch each other, affecting the position of the wheel and preventing it from aligning properly with the wheel cutout.

Decisions

• Instead of buying a ready-made motor mounting bracket, we decided to design and 3D print our own mount.
• We tried different shapes for the motor mount and found that the triangular-shaped design was more suitable for our model.
• We decided to redesign the coupler before continuing with the motor mounting.

Next week

• Redesign the coupler with a suitable length.
• 3D print and test the redesigned coupler.
• Finalize the motor mount position.
• Attach the motor mount properly to the base.

Goal this week: redesign the coupler so the motor and wheel assembly fits properly inside the base and get into electronis

What we did

So, we started redesigning the coupler. We first looked at the coupler design we were already using and checked where there was any extra or unused space. Honestly, there was quite a lot of space that was not being used.

After the metal shaft entered the coupler, there was around 4 mm of space left towards the wheel adapter. Out of that, around 3 mm was free space, while only about 1 mm was being used by the motor-to-wheel adapter.

So, we decided to make better use of that space. We redesigned the coupler by extending the hexagonal section further towards the wheel adapter. This allowed the hexagonal part of the coupler to go deeper into the hexagonal hole of the wheel adapter.

After printing and testing the new design, we found that the coupler was going fully into the wheel adapter as we wanted. So, that part was completed. After that, we placed the whole setup on the base and checked whether the wheel was sitting correctly inside the wheel cutout. And yes, it is.

Finally, we assembled everything together, and at last, everything was fitting properly.

so now we are going to our next stage and thats electronics.

We then started working on the electronics side of the project. And, just like everyone else, our first task was to get the motors running. For this, our first core microcontroller was the ESP32-S3 Pico, and we used the TB6612FNG motor driver. We set up the circuit on a breadboard and tested it to make sure everything was connected and working properly.

We first uploaded the code to the microcontroller and then connected the motor driver to test it. After a few initial tries, it started working. We then used the setup to test the motors and make sure they were rotating properly.

But suddenly, the setup stopped working. At the same time, we started getting laptop notifications saying that there might be some problem with the ESP32. We immediately checked the ESP32 by touching it, and it was extremely hot. So, we quickly disconnected the data cable and checked the setup.

When we checked the cable as well, we noticed that it had also become hot. We rechecked the ESP32, and unfortunately, it was already burned. We still don't know the exact reason why it happened.

Problems and blockers

• The coupler had a lot of unused space, so we had to redesign it to make better use of the available space.
• The ESP32-S3 Pico became extremely hot during testing and was eventually damaged.
• We could not identify the exact reason why the ESP32-S3 Pico burned.
• The data cable also became hot during the incident.

Decisions

• We redesigned the coupler by making better use of the available space and extending the hexagonal section further into the wheel adapter.
• We decided to start the electronics testing using the ESP32-S3 Pico and TB6612FNG motor driver.
• After the ESP32-S3 Pico failed, we will need to test with another controller before continuing the electronics integration.

Next week

• Test another controller and motor driver setup.
• Get the motors running again.
• Continue with the electronics integration of FIORA.

Our main goal this week was to continue working on the electronics, find a reliable motor controller and driver setup, and get all four motors running properly. and starting to designing 3D model body for fiora.

What we did

Since we didn't want to waste more time, we decided to try another ESP32 model. We switched to an ESP32 DevKit, and initially, it worked without any problems. We were able to run our tests with it, but suddenly, that board also stopped working. We suspected that there might be some issue with the power supply, but we couldn't confirm the exact cause. we

So, we decided to move to an Arduino Uno instead. Since we were changing the controller, we also had to change the motor driver. We first tried using an L298 motor driver. It worked, but we noticed that it produced a lot of heat during operation. Because of this, there was also a noticeable power loss, which made it less suitable for our setup.

We started looking for another motor driver that would work better for our rover. That's when we found the Arduino L293D Motor Driver Shield. It was completely new to us, so we had to spend some time understanding how it worked and figuring out the connections. Once we figured it out, we started testing it. We also needed a way to control the rover wirelessly, so we added an HC-05 Bluetooth module. We uploaded the required code to the Arduino and connected the HC-05 to the controller.

For the first test, we used a Bluetooth car controller app and controlled a single motor through Bluetooth. The motor responded correctly, so we then connected all the motors to the motor driver shield and tested them again. All the motors were working properly.

After confirming that the electronics were working, we assembled the motors, motor driver, Arduino, Bluetooth module, and battery onto the base. Finally, we tested the complete setup by driving the rover.

And this time, everything worked properly. The rover moved as expected, which was a big step forward for us.

Now, we were planning to start making the 3D model for FIORA. Alen was working on designing the 3D-printed model, while Shamil was working on building the prototype body from his side. We had already drawn a model, and our plan was to make the final body similar to that design.

How the Drawing Guided the Design

The drawing gave us a basic reference for how we wanted FIORA to look and how the different parts should be arranged. We used it as a starting point while designing the 3D model, especially for the overall shape, size, and placement of the main components. Instead of designing everything from scratch, we could use the drawing as a guide and gradually modify the 3D model to match the planned design.

At the same time, Shan came and told us that we needed to use LiDAR for the project. It was a SLAMTEC RPLIDAR A1M8, a 360-degree laser range finder. We didn't really have much of a choice, so we agreed to use it.

This was our first time working with LiDAR, so we knew we had to spend some time learning about it and figuring out how we could use it with FIORA.

Problems and blockers

• Continue testing and improving the motor control system.
• Start working with the RPLIDAR A1M8.
• Learn how to connect and read LiDAR data.
• Start integrating the LiDAR with the Raspberry Pi and FIORA. *Continue developing the 3D model and prototype body.

Decisions

• We decided to move from the ESP32 to an Arduino Uno for the motor control.

• We decided not to continue with the L298 motor driver because of the heat and power loss.

• We selected the Arduino L293D Motor Driver Shield for controlling the four motors.

• We added an HC-05 Bluetooth module for wireless control during testing.

• We decided to include the SLAMTEC RPLIDAR A1M8 in FIORA and start learning how to use it.

• We decided to use our existing body design as the reference for developing the 3D-printed body.

Next week

• Start working with the RPLIDAR A1M8.

• Learn how to connect and read LiDAR data.

• Start integrating the LiDAR with the Raspberry Pi and FIORA.

• Continue developing the 3D model

Our main goal this week was to start working with the RPLIDAR A1M8, understand how it works, and get the LiDAR data running on the Raspberry Pi. We also planned to continue working on the 3D body design and improve the rover's overall setup.

What we did

so this week w strated with LIDAR-

We needed to understand how LiDAR would fit into FIORA. Since FIORA is planned to be an autonomous indoor delivery robot, the LiDAR can help the robot detect its surroundings and understand the environment around it. The RPLIDAR A1M8 can scan the area around the robot and provide distance measurements, which can later be used for mapping and navigation. we started with a basic setup to understand how the RPLIDAR A1M8 works. We connected the LiDAR to the Raspberry Pi 5 and first focused on getting the raw scan data from the sensor.

Our first goal was not to start autonomous navigation immediately. We wanted to make sure the LiDAR itself was working correctly and that the Raspberry Pi could communicate with it. Once we were able to receive the scan data, we could move on to understanding how the data could be used for mapping and navigation in FIORA.

While we were working on the LiDAR, Shan told us that there was someone in the TinkerSpace community who had worked with LiDAR before. He said he could connect us with that person so they could help us set up the LiDAR and mapping.

That was how we met Devadath. He is an AI engineer who also works on hardware-related projects and has good knowledge of IoT and related technologies. With Devadath's help, we started working on setting up the LiDAR.

At the same time, we started thinking about how we could actually use the LiDAR to make FIORA deliver something from one point to another. We wanted to have a system where a user could select a destination and the robot would deliver the item to that location.

Our first idea was to use WhatsApp. We thought we could create a bot using the WhatsApp API and set a few fixed points on the LiDAR map. The user could then select one of those points, and FIORA could make the delivery to that location.

why we initially chose whatsapp

The main reason we first thought of using WhatsApp was because almost everyone already has it on their phone. We didn't want people to download another app or go to a separate website just to use FIORA. They could simply use WhatsApp, which they already know and use regularly, and send the delivery request from there. We felt this would make the system much easier and more convenient for everyone.

So, we explained our idea to Devadath and discussed our plan to use WhatsApp for communicating with FIORA. He explained that the WhatsApp API is not an open API that anyone can simply use for a personal project. It has to be accessed through Meta's official system, with the required setup, permissions, and verification. Because of these restrictions, we could not simply create a WhatsApp bot and start using it for our project.

Since this made WhatsApp difficult to implement for our project, we started looking for another option. The next option we considered was Telegram, since Telegram provides an API that makes it easier to create and use our own bot. So, we decided to explore Telegram as the communication method for FIORA.

So, we thought of using Telegram instead. The plan was to use the Telegram API to create a bot through which users could select a delivery destination and send the delivery request to FIORA.

We discussed this idea with Shan and he agreed with the approach. well most of the basic 3D design and base of FIORA were also almost completed, so we could start focusing more on the software, LiDAR, and delivery communication side of the project.

Problems and blockers

• We were working with LiDAR for the first time, so we needed to understand how it works and how to set it up properly.
• Using WhatsApp for the project was difficult because its API requires an official setup, permissions, and verification.
• We had to reconsider our communication method and look for an alternative to WhatsApp.

Decisions

• We decided to use the RPLIDAR A1M8 for detecting the surroundings and collecting distance measurements.
• We decided to explore Telegram as the communication method for FIORA.
• We planned to create a Telegram bot through which users could select a delivery destination and send requests to the robot.
• We decided to focus more on the software, LiDAR, and delivery communication since the basic 3D design and robot base were almost completed.

Next week

• Continue learning about LiDAR mapping and how it can be used in FIORA.
• Work on setting up the Telegram bot for communication with the robot.
• Explore how users can select a destination and send delivery requests through Telegram.
• Continue improving the 3D body design and overall robot setup.

Goal this week

Our main goal this week was to continue working on the RPLIDAR A1M8 and understand how to use its scan data for mapping and navigation in FIORA. We also planned to complete the 3D model of FIORA and start printing the body parts. Along with this, we wanted to improve the overall design and move forward with both the LiDAR setup and the physical build of the robot.

What we did.

We first wanted to check whether we could create a map using the LiDAR. So, we connected the RPLIDAR A1M8 to ROS 2 and used RViz2 to visualize the scan data. We then manually mapped the surroundings to understand how the LiDAR scans the environment and how the data could be used for mapping in FIORA.

The red lines shown in RViz2 represent the obstacles detected by the LiDAR's laser. After connecting the LiDAR to the prototype body, we manually drove the robot using Bluetooth to test how the LiDAR scanned the surroundings.

We started our mapping and design work at TinkerSpace, so we planned to map the entire space. However, we came across a problem during the initial mapping process. The LiDAR was mounted at the centre of the robot's body. This meant that if any part of the robot's body hit an obstacle, the LiDAR might not detect it because the obstacle could be outside the LiDAR's scanning position.

We discussed this problem with Devadath, and he suggested a solution. He explained that RViz2 has an option to account for the robot's body dimensions. We could specify the diameter of the robot's body so that the mapping and navigation system could consider the robot's size instead of relying only on the LiDAR's position.

Following his suggestion, we added the dimensions of our prototype body in RViz2 and configured it accordingly. After making these adjustments, we continued with the mapping process.

https://github.com/user-attachments/assets/bc92c07e-f1ff-470a-ac00-ad31e8d23390

After making these adjustments, we reached that stage of the process and were ready to continue mapping the TinkerSpace area. We had completed the initial setup and solved the issue of accounting for the robot's body size in RViz2. From there, we continued working on mapping the surroundings using the LiDAR and manually driving the prototype.

Problems and blockers

• The LiDAR was mounted at the centre of the robot's body, so it could not detect every obstacle that might come into contact with the outer parts of the robot.
• We needed to configure the robot's body dimensions in RViz2 to account for the actual size of the prototype.
• We were still learning how to use LiDAR scan data for mapping and navigation.

Decisions

• We decided to use ROS 2 and RViz2 to visualize the LiDAR scan data and work on mapping.
• We manually drove the prototype using Bluetooth while testing the LiDAR and mapping process.
• We added the prototype body's dimensions in RViz2 to account for the robot's size.
• We decided to continue mapping the TinkerSpace area using the LiDAR.

Next week

• Improve the mapping setup and test the accuracy of the generated map.
• Use SLAM (Simultaneous Localization and Mapping) to create a map of the surroundings.
• Add fixed delivery points to the Telegram bot so users can select a destination.
• Work towards enabling automatic delivery, where FIORA can navigate to the selected point and deliver the item.

Our main goal this week was to continue working on the LiDAR mapping and SLAM setup for FIORA. We also planned to improve the mapping accuracy, add delivery points to the Telegram bot, and work towards enabling automatic delivery to the selected destination. Along with this,starting to print our 3d model.

What we did

with the help of devadath nammal slamil mapping cheyyan thudangi. mapp cheyth oro placum save cheythu. ahtinte edak raspberry pi off ayikond inrikkunund aayrunnu. enthu kond enn vicharichal lack of power supply aan. njngal use cheyyunath power bank aan so athin avishyam ulla ahtreyum ambiar athil illa. so this week shan condecterd a BIR sprint to boost up oru project. athukond thanne ellavarum oru mich aayirunnu undaye nammal angootum ingottum okke help cheyth. nammudeth mathram allathe mattulavarude projectsilum work cheythu. so njgal thirich nammude projectilek thanne vannu and started working on it and we also finished our design and shanine kanichyu avide aan oru shocking . nammude design mattanam enn paranju cause it is atleast 4 feet tall. so print cheyth edukanael thanne weeks edukum and kore filement should use. so njgalk ath cheruth aakanam. nammude design okke mattendi verum cause cheruth aavumbol chelathokke mttendi verum . so ath oru vellath adi aayrunnu.