The overall problem that we are trying to solve is being able to rapidly deploy a system of automated movement. Instead of the objects around us being stationary, what if we could enable them to move around and interact with us. We could use robot modules that link together to combine steps of movements. It would be a reconfigurable way of making the stationary objects move around.
An example mission of this would be for use in natural disaster settings during the humanitarian efforts. The robot modules would be unpacked from a backpack, then configured and linked together to perform a task. Tasks can vary depending on the scenario, such as sorting supplies to go to a specific area, or even digging out areas to let standing water flow away from shelter locations. By having the robots help with tasks the effort is in parallel with the human, freeing up time for the human to do complex decision making jobs.
Being able to achieve the level of parallelization is a key part to the problem; the robots won’t be very helpful if they have to be controlled all the time. They have to be able to do their task as autonomously as possible and when there is human input they have to understand what is trying to be communicated.
The goal of this is to eventually get the robots out in the field helping. It will take a long time with a lot of failures to get to that point. It’s all with another moonshot in mind: if the robots will be good enough for Earth, then what is stopping us from making them good enough for other planets as well. The robots could be tasked with starting to build structures on Mars, or go exploring, try to grow a plant (challenging in difficult environments).
The first step towards working on the problem is to create one of the robot modules.
For the final project, I’m creating the Rapidly Deployable Automation System (RDAS) Drive module.
The dimensions of the robot will be based around a 1u CubeSat. When the robot unfolds from its cube, it will drive around. Using its distance sensor, it will detect and avoid obstacles. The position of the robot will be tracked using encoders on the wheels.
Control from the human will use a Tele-operational Headband that tracks the movement of the wearer’s head, and sends the data to RDAS Drive to adjust the motor speeds.
Here are projects that are somewhat similar to RDAS. There are even more, but these are the top 3.
Similar in the way that RDAS will be using the same dimensions. The LightSail CubeSat is similar to RDAS Drive in the way that the sides fold outwards. Differs in the functionality, but eventually more people will start making CubeSat robots and landers for use on different planets.
Similar in the way that it is out in the field, sometimes in harsh environments. Differs in the way that this is a one robot system, whereas RDAS would be distributed across many modules.
Similar in the way that multiple moving parts are connected together. In MTM’s case, this is constructed to move an end-effector. In RDAS’s case, it would be to move an outside object, which may be moved between the various modules to go to a different place. Differs in the overall purpose and construction. There are some neat things that MTM does with Gestalt, and I will look to this for ideas when starting more on linking multiple robots together.
A complete bill of materials will be completed with the final project, but here is a rough overview:
Estimated cost for RDAS: ~$60
There are many things wrong with RDAS Drive v0.1, here are the things that I triaged to be fixed in v0.2:
Better internal area: Time: 8 hours
Can there be proper dimensions of areas that attach to the sides such that they can fit when folded up into the main area? Is there a better way of attaching the vertical pieces for the main area? How tall exactly can this go?
Less screws: Time: 15 hours
Is there a way there can be less screws in the design? Perhaps by using 2 screws only on the links, and then 4 screws for each corner. But then how will things be attached to the sides?
Wheel angle: Time: 6 hours
Is there a way the wheels can be mounted on a angle, so that way when it touches down, the wheel can be flat on the ground, rather than on its ‘edge’? Can the amount that the wheel sticks out be minimized? Is it better to have the wheel stick out more or less for movement? How can the base sliding on the ground be improved?
Encoders: Time: 15 hours
Not exactly a question, but since the robot is going to be re-designed, and v0.1 is currently missing in action, have to fix it.
Total time: 44 hours
Here are the other tasks needed for making the robot:
Total time: 65 hours
Just in case I can’t connect to the mcu on June 10, will have to make a video about the final project
Time: 15 hours
Time: 20 hours
The timing doesn’t really work out, though these are overestimates. So it’s likely some tasks won’t be able to be met. The tasks that will be skipped will be the ones that would drag down the schedule from being able to have a functional robot on time.