Golem - A Flying Robot - Idea for a project
Baba Gyani Triviani said:
"Look up in the sky, it's a bird, it's a plane... No, it's Golem!"
I had been to Ayana, a hackathon in PESIT recently and saw quite a few hardware hacks. With the arrival of Arduino into the market, robots seem to have become quite ubiquitous, which is a good sign. Students, most of the time, design and build single purpose robots, that could be a line following one or a maze solving one. Rarely are they developed as systems.
The Raspberry Pi is an interesting device - The size of a credit card, it comes with 2 USB ports, an ethernet port, a power in port, an HDMI port, a video out and a sound out along with an SD card slot. The cost is supposed to be around $25. The advantage of a Raspberry Pi over Arduino is that, Raspberry Pi runs a full fledged Linux distribution on it, meaning that it is an onboard computer rather than just a microcontroller and thus allows for cooler and harder things to happen easily, like image processing, for example.
For some time now, I have wanted to build a flying robot that has the following specifications. Go through it if you are interested and let me know what you think.
First and foremost, the idea is to have the robot developed in terms of modules and independently. This may seem obvious to experienced people but it is something that students don't use for an approach. To see an example of what I mean, and this example is pertinent to the project, consider the control of the robot - The robot can move back and forth and this instruction comes from a remote control. The remote control could be a video game joystick, a Kinect, a custom controller, or something else. The robot should not concern itself with 'who' is sending this instruction. Once the instruction is received, it should simply process it. This allows for complete decoupling of the controller and the robot. People who work with web services are, I am sure, very familiar with this concept. You get a JSON and you how you use it is up to you. The advantage is, the people who are building the robot itself know the 'contract' or what to expect from the controller. It is up to the controller maker to implement it. And they can work independently
Disclaimer:
It's been a long time since I worked on these kinds of things - So most of what I say here will be pulled out from memory and/or simply visualised. Some might be outdated, some could be grossly incorrect. Let me know if there are better alternatives. This is just a brainstorming post. I have done no research, so some things could be impossible or be done elsewhere and I am not aware of it.
Ok, now for the characteristics of the robot itself.
Moving on ground, achievable by using H-Bridge
Moving in air, if all propellers turn at the same speed, I am guessing it will be level. If two slow down, the bot will tilt and move in that direction...
"Look up in the sky, it's a bird, it's a plane... No, it's Golem!"
Project Golem
(Note: Golem is a mechanical robot in 'Batman of the future' which is controlled by a guy remotely such that movements of his hands translates to corresponding movements of the robot, much like the movie 'Real Steel')I had been to Ayana, a hackathon in PESIT recently and saw quite a few hardware hacks. With the arrival of Arduino into the market, robots seem to have become quite ubiquitous, which is a good sign. Students, most of the time, design and build single purpose robots, that could be a line following one or a maze solving one. Rarely are they developed as systems.
The Raspberry Pi is an interesting device - The size of a credit card, it comes with 2 USB ports, an ethernet port, a power in port, an HDMI port, a video out and a sound out along with an SD card slot. The cost is supposed to be around $25. The advantage of a Raspberry Pi over Arduino is that, Raspberry Pi runs a full fledged Linux distribution on it, meaning that it is an onboard computer rather than just a microcontroller and thus allows for cooler and harder things to happen easily, like image processing, for example.
For some time now, I have wanted to build a flying robot that has the following specifications. Go through it if you are interested and let me know what you think.
First and foremost, the idea is to have the robot developed in terms of modules and independently. This may seem obvious to experienced people but it is something that students don't use for an approach. To see an example of what I mean, and this example is pertinent to the project, consider the control of the robot - The robot can move back and forth and this instruction comes from a remote control. The remote control could be a video game joystick, a Kinect, a custom controller, or something else. The robot should not concern itself with 'who' is sending this instruction. Once the instruction is received, it should simply process it. This allows for complete decoupling of the controller and the robot. People who work with web services are, I am sure, very familiar with this concept. You get a JSON and you how you use it is up to you. The advantage is, the people who are building the robot itself know the 'contract' or what to expect from the controller. It is up to the controller maker to implement it. And they can work independently
Disclaimer:
It's been a long time since I worked on these kinds of things - So most of what I say here will be pulled out from memory and/or simply visualised. Some might be outdated, some could be grossly incorrect. Let me know if there are better alternatives. This is just a brainstorming post. I have done no research, so some things could be impossible or be done elsewhere and I am not aware of it.
Ok, now for the characteristics of the robot itself.
Requirements:
The robot should be able to move on ground and in air- It should move on ground - 2 wheels plus Goli castor (steel ball bearings)? or 4 wheels?
- It should fly - four vertical propellers?
Moving on ground, achievable by using H-Bridge
Moving in air, if all propellers turn at the same speed, I am guessing it will be level. If two slow down, the bot will tilt and move in that direction...
- Controller is a Raspberry Pi - Full fledged Linux distro is more powerful than simpler controllers
- Has a camera on board. Streams video. Helpful in navigation, recording...
- Has sensors on board to prevent collision or falling off stairs or hitting ceilings - should override manual controls... Similar to forward collision avoidance systems in cars. (Sensors are IR or SONAR or something else?)
- Has accelerometer (and/or gyro) to measure tilt - very useful for auto-stabilisation and can be used to override manual errors, like extreme tilts will not result in crashing (can it happen?) Also, how cool would it be to use control systems here? Does it make sense?
- Since it has auto-stabilisation and sensors at the bottom, auto-landing should also be possible.
Controller
As discussed previously, the controller is independent of the device
- Can be controlled using custom controller - wireless radio transmission that has buttons and knobs or whatever
- Would be cooler if XBox controller is used instead
- Even cooler if you can use a Kinect to control it
- Another super idea (inspired by junior, Suraj Srinivas) is to have accelerometer connected to gloves. The user moves his hands around and that is translated into robot movements in the air
- Autonomous and by learning?
Of course, more than one can work simultaneously... Since it has a camera and a full fledged operating system, it can do a variety of image processing functions.
It can be used in a variety of places - Let your imagination run free.
As you can see, all functions that are independent of one another can be developed independently. Flight and ground motion are independent, for instance. Camera and motion are independent too. And so on.
The design, however, should account for things that will be or could be added in the future too - for example, if you have not accounted for additional weight that could be added in the future, your robot may not fly at all! So think of all the features that you may add in the future. Modules like sensors should be little pluggable pieces and not soldered to the main board.
All in all, I think this project is going to be delightful to watch if completed. It has a broad range of topics to learn too, like electronics, image processing, control systems, programming, etc. And since they are independent, it is not as daunting as it seems. As in, things will work even if certain things are not implemented.
So yeah, that's an idea I have been thinking of for quite some time. Let me know your opinions on it.
Comments
The idea looks cool. You know what would make it even more amazing? If those flying rotors were retractable. If it is ground mode, then you wouldn't see it. If u initiate flight mode, the wings come out of their "shell" and flight begins!
As far as the implementation goes, here is my take on it:
1)Raspberry Pi -> Has a lot of interfacing issues in general, better use a Beagleboard.
2)Linux -> Not suitable in handling real-time calculations, as it is a high level OS. Better would be to use a RTOS, if at all an OS is needed.
3)Accelerometer -> Too inaccurate. Flight will surely not be stable, it'll keep wobbling around a LOT. Better to use an IMU (Intertial Measurement Unit), which has an accelerometer as one of the components. (Remember I used an accelero + gyro board and the gyro got fried? It's the same, kinda.)
http://www.scoutuav.com/category/guide/electronics/
This has a good compilation of what I was talking about.
And it's gonna be incredibly difficult in deciding on the size. It cannot be small, that's for sure. The ground motors have to be powerful enough to carry 4 rotors and vice versa.
I would say, still, it's going to be a very interesting project. It would look so uber-cool when it's done! :)