Mod-Bot

summary_

Mod-Bot was the prototype of a concept my coursework mates and myself envisioned back in 2016. The idea was to augment robotic vacuum cleaners with modularity and reconfigurability in order to improve its cleaning efficiency and effectiveness. Whereas individual deployment would potentially allow swarming to be deployed to improve efficiency, unified deployment would allow the robot to utilize its maximum suction power, thus increasing its effectiveness.

Year 2016
Team Stevanus Satria, Lee Jia Wen, Cai Ruihe
My Role Arduino Programmer, Designer
Software Arduino IDE
Hardware GCC LaserPro Spirit GLS

background_

2016 was the year robotic vacuum cleaner started gaining traction in Singapore. More and more households began adopting one to assist them in the mundane task of cleaning their living spaces. Like any new technology, they were also quite pricey. A simple robotic vacuum cleaner without any smart features could have easily cost around S$500.

Interestingly, most of these robots have a circular body. They were generally driven by a differential drive mechanism and were equipped with 1 or 2 mini brushes which swept the dust particles towards the suction inlet underneath.

Looking at the diagram above, it became apparent that one of the biggest weaknesses of robotic vacuum cleaners was its inability to reach the corners of a space. No matter how the robot navigated itself, the corner of a room would always be a blindspot unreachable by its brushes. There was a research group in SUTD that aimed to tackle this issue by prototyping a reconfigurable cleaning robot. Dubbed “Hinged-Tetro”, it was able to reconfigure itself based on the degrees of freedom provided by the hinges connecting the blocks together.

Despite the increased versatility offered by Hinged-Tetro, it was still constrained by (a) the limited number of possible configurations and (b) the constant surface area occupied by the robot at any given point. What we aimed to do was to remove the second constraint altogether by coming up with a design that would allow the individual blocks to be fully detached from each other. We also hoped to improve on the first constraint by coming up with a design with more possible configurations.

research_

connecting mechanism_

The main challenge of this project was designing a reliable and energy-efficient mechanism to connect and disconnect the individual blocks as necessary. We acknowledged that having a latch mechanism powered by a motor was likely to work, but the short timeline and our university’s manufacturing capabilities were limiting factors to us designing a mechanism that would catch nicely without having the actuator exert a constant force to keep it locked when the blocks were connected. With an active mechanism ruled out, we had to go with a passive mechanism. Considering the same limitation with latch tolerance as the above, we realized that the only way we could make this work was by using magnets.

drivetrain_

In line with our desire to make the design energy-efficient, we wanted the robot to be driven by a single unit when connected. As such, we would need a grippy drivetrain for the main block (we called it the Mother Bot) with high torque motors. As for the reconfigurable blocks (we called them Child Bots), we still needed them to be able to drive on their own when necessary, yet pose negligible interference to the mobility of the overall robot when connected. After looking around, we found a unique wheel and its corresponding drivetrain design that would allow us to achieve just that.

That unique wheel is an Omni wheel. An Omni wheel or poly wheel is a kind of wheel that enables motion parallel to its axis of rotation. This is courtesy of the presence of small discs all around the circumference of the main wheel. Having three of them mounted equidistant from one another allows an object to move in any possible direction and orientation, as shown in the diagram above. Such a drivetrain design suited our Child Bots perfectly as it would enable them to disconnect from the Mother Bot no matter which orientation they were originally connected to the latter. It would also provide total freedom of mobility to the Mother Bot no matter how many Child Bots were connected to it.

With all these in mind, we decided to proceed with a 3-Omni-Wheeled drivetrain design for the Child Bots, and a simple differential drive mechanism for the Mother Bot.

fabrication and assembly_

After deciding on the overall design of the robot, we went ahead to split the tasks amongst ourselves. While I was assigned the task to program both the Mother Bot and the Child Bot, we all worked together to fabricate and assemble the design. Thanks to Ruihe’s impeccable computer-aided design (CAD) skills, both the Mother Bot and Child Bot turned out beautifully.

Unfortunately, due to budget constraints, we were only able to fabricate one Child Bot. We were also unable to procure better parts with additional functionalities such as motors with encoders for the Child Bot. As such, a lot of the coding to illustrate the feasibility of this design involved manual tuning on our end.

programming_

I coded a simple forward, backward, turn left, and turn right functionalities into the Mother Bot, tuning them to the best of my abilities to ensure that it goes relatively straight on the terrain it would be demonstrated on. The way it worked was that as long as the key bound to the desired direction of motion was pressed on the laptop, it would continue to move in that direction. Turning would be done on the spot, again for as long as the key bound to the direction of rotation was pressed.

The Child Bot, however, was much more tricky to program. I went ahead with binding a key on the laptop to a specific reconfiguration path. When the key was pressed, the Child Bot would dramatically accelerate away from the Mother Bot. The idea was for the friction generated on the wheels to overcome the magnetic force connecting the Child Bot to the Mother Bot. Once the Child Bot disconnected itself from the Mother Bot, it would follow a pre-programmed reconfiguration path, before reconnecting itself on a different side of the Mother Bot.

Unfortunately, this did not always work. Initially, we thought that the magnetic force was too strong for the friction to overcome (admittedly, an Omni wheel generates much less friction compared to a normal wheel). However, when modifying the configuration of the magnets did not yield much improvement, we realized that the problem was actually due to the limitation of the Romeo BLE Mini we procured: it was unable to drive all three Polulu motors in a consistent manner. As such, even when driving all three motors with the maximum output possible, the Child Bot sometimes failed to overcome the magnetic force connecting it to the Mother Bot. Furthermore, even when it successfully disconnected itself, the separation distance and direction was not consistent. This, with the lack of a localization mechanism, meant that the hardcoded path may not reposition the Child Bot correctly for the subsequent reconnection to be successful.

Nonetheless, despite these challenges we were able to tune both the robot’s magnets configuration and the code to produce a reasonable success rate of around 70% for our demonstration.

evaluation_

All in all, given the tight budget and time constraints, we were pretty satisfied with how Mod-Bot turned out. It definitely looked stunning; the transparent acrylic and intelligent component placement design by Ruihe translated nicely from CAD to assembly. However, the constraints highlighted above meant that the firmware had to be tuned to a specific terrain and reconfiguration path. Nonetheless, we firmly believed that this was a highly workable design, and with more time and budget we were confident we could yield a much more consistent performance out of it. You can take a look at how the magnetic connection mechanism worked in the footage below: