Building the Brains!
Jonathan McLean
9 May, 2007
  • parts
  • Soldering

Design

So we have a lot of wires that go to a lot of different parts othe robot, and boy is it all intimidating. Thus, what we needed was a solid design for our PCB to keep things organized. Many a whiteboard was scribbled on and erased simply trying to make sense of all the connections we were making, but thankfully they all boiled down to a few clustered connections that made life much easier. First off, all of the speed controls are boiled down into 5 connection points: two for the motors, two for the battery and one for the control line combo wire (control line, power and ground). The ESC's were made even easier to work with when all of the motor lines were connected to the kit-provided motor power coupling. I felt like Han Solo or someone when I hooked that up. Also, all of the 11.1V Battery lines were clumped into one power and one ground, then fed through a toggle switch and capped with a plastic connection that can connect directly into 11.1V Li-Pol battery.

The control line clusters are also very useful. We opted out of implementing a single control line on top of individual controls for time's sake. We are dealing with millisecond intervals and at this stage in the game we feel that we can distribute power quickly enough to keep it even. The accelerometer was wired with resistors and given direct connections to the pins on the BS2. Finally, we need to develop some way to mount it onto the actual frame, but hopefully that should be easy. Pics of the PCB are hopefully soon to follow.

Soldering...the work of the devil

So soldering is almost stress relief, until it goes wrong and then it's a major stressor. I have yet to find the proper technique for soldering that makes it work all the time. And soldering on the PCB's is both a help and a nightmare. The contact points are design to dip and pool the melted solder, which is great for single connections, but when one is trying to form a bus, either for power or ground, the pooling causes one to put a bit too much solder in and then if you are not careful, it crosses over onto another connection, and boy is reclaiming solder annoying.

Finally hitting the code
Jonathan McLean
26 April, 2007
  • parts
  • Code

A note on control

The speed controls are annoying. They are designed for model airplane hobbyists and are meant to be plugged into a RC controller. Thus everything is nicely color-coded and has human readable values and whatnot. The problem is that we are not model ariplane hobbyists, we do not have a nice RC controller and do not understand these human readable terms such as High and Low and Throttle control and whatnot. So we had to reverse engineer a series of modulated pulses to control the Electronic Speed Controls (ESC's), and boy was that fun. We didn't have any numbers to begin with, nor did we truly understand what modulated pulses were except at an elementary level. Some brief searching on the internet revealed some magical numbers such as 2200 ms pulses for high throttle and 920 ms pulses for brake. These two speeds were critical because they allowed us to disarm the safety that our ESC's have every time you turn them on.

These magical numbers were not the whole solution however. First we had to tell PBASIC to generate these modulations appropriately, which required a lot of guesswork and pulling out random numbers like 200. Then we had to figure out the timing for each of the loops to generate the signal the ESC was waiting for. And then we had to construct a series of loops to simulate a brake, throttle, brake loop that would trigger the ESC to start accepting control pulses. It took a lot of grunt work and a lot of magical numbers but we now have a foundation upon which we can begin to reverse engineer not only the control style of the ESC but the capapbilities of the motors as well. Fun stuff.

Acceleramating now

Hot on the heels of our success with the ESC's we began to play with the accelerometer. This is the heart and soul of our autonomy. The chip itself is a two dimensional tilt sensor really. It works by heating a gass inside it's little chamber and detecting the motion of that gas. It seems very sensitive and will allow us to feed numbers to our robot that will make it balance itself...hopefully.

Like the ESC's, we did not know where to start. Thankfully we did not have to rely so much on magical numbers because the chip is sold my Parallax inc, and thus has a nice online instruction manual as well as tutorials. We whipped up a tutorial, with some improperly sized resistors, and started to get feedback immediately. And it even loooked like it will be useful. w00t! So that is where we stand now. Oh yeah, we almost fried our battery, and we aren't quite sure why, but it's all ok now. We have controllable speed and readable tilt numbers. Now we just need to throw it all together.

Speed Control
Jonathan McLean
12 April, 2007
  • parts

Spped Control

Hey folks, sorry about the lack of an update, but to be honest, not much has gone on. After my last update, Robotics Class has been focused on discussion and not building. And even if it were focused on building, we do not have much to build. Becuase our robot's frame is based on a kit, most everything is done for us. But we did run into one major problem: how to control the speed of the motors.

See, the Basic Stamp does not have a magical control line for motor speed, nor do the motors themselves have any speed control or control lines either. Thus we need to develop a way to control the speed of the motor. After talking to Prof. Ozgur Izmirli, who knows more about electrical engineering than Prof. Parker, we arrived at two options. We could either develop our own control, using pulsed output to a capacitor which would then regulate a transistor, or we could buy something.

Not being electrical engineers, we opted to purchase some speed controls. After a frantic 3 hour search around the Southeastern Connecticut Region, we finally ended up across the river at Lee's Toys and Hobbies in Groton. This place was great! Next thing we know, we have ordered 4 Electrifly C-7 Nano speed controls, commonly used for model airplanes and helicopters.

Well, our speed controls arrived just a couple days ago, and now we are in the lab trying to figure it all out. Basically, we know we need to send it pulsed modulations to immitate an RC transmitter, but we don't quite know the frequency widths that send what commands. So this is where we stand. Our frame and motors and power are fine, we just need to get the brain controlling the speed. Should be fun.

The First of Many...hopefully
Jonathan McLean
26 February, 2007
  • parts
  • images

Some Images

Hey folks, I have some images for you all. Click on them to get a larger view. Captions are beneath. They aren't anything spectacular looking, but that's for when the thing is actually flying. For now we just have parts and still need to order more before the frame is even complete. Enjoy!

the brain of the device Here is the brain of our device. It is a Parallax BASIC Stamp II currently hooked into a development breadboard with a speed relay. We were testing the relay as a power regulator for the motors but we think our Lithium Polymer battery might produce too much volatage that overpowers the weak electromagnetic forces used in the relay.
the four propellers These are the four propellers attached to the main gears. These guys will sit atop four extremely powerful motors and will hopefully lift the ROFL Copter into the air. Two will spin clockwise and the other two will spin counter-clockwise.
the four motors These are the powerhouses themsevles. Taking in the 12 Volts from out LiPoly battery like it's nothing, these buggers are capapble of speeds of up to 50,000 rpm I believe. We will be running them at about 3/4 of that though.
the frame of the machine And here is the frame of the beast. Those connecting rods, the spokes, are all carbon fiber and extremely strong while being lightweight. Could we have asked for a better combination? I think not.
ROFL Copter
Jonathan McLean
14 February, 2007
  • parts
  • history

A Quick Update

A couple updates for our avid fans:

  • Our official Robot name is ROFL Copter. We are nerds like that, and we are going to keep it. Laugh all you want, we intend to.
  • Our parts have been ordered, according to Gary at least. Earliest expected shipment is tomorrow.
  • We have found an accelerometer/two-axis tilt sensor. Nothing really else from that except that we found one.

A Flying Robot
Jonathan McLean
6 February, 2007
  • parts
  • goals
  • design
  • history

An Introduction

Welcome one and all to the home of the flying robot. This site is a robotics project page with an aim to provide whomever visits it with an up to date report on the progress of the Flying Robot. Right now the project does not have a name, so we will stick with the Flying Robot. This project is being completed by myself (Jonathan McLean) and my partner in crime Owen Raccuglia. We are both Computer Science Majors and Juniors at Connecticut College. Connecticut College is a small liberal arts college located in New London, CT and is home to about 2,000 undergraduate students majoring in any of 52 available majors (Computer Science being one of course). The robotics project itself is being completed as a requirement for a Computer Science Class: Robotics. The course description from the Connecticut College Course Catalog describes COM 310 Robotics as:

An introduction to the design and control of autonomous robots. Design issues such as wheels verses legs, actuator placement, the use of sensors for perception, controller selection, and wiring will be covered. Students will develop control schemes and use programming skills and machine learning to generate programs for controllers.

This catalog entry mentions nothing of actually building a robot, but do not worry, we do that as well. Many of the robotic designs are based upon hexapod walkers, which are added to the "robot colony," run by Dr. Gary Parker. Owen and I are taking a different spin on it: we are going to build a robot that flies!

A Flying Robot?

The notion of a flying robot is not a new one. Unmanned Aerial Vehicles (UAV's) have been used by the military for several years in combat situations while "autopilots," have allowed computers to mantain air speed for commercial flights. Thus there was already a notion that autonomous vehicles could take flight and even stay aloft on their own accord. Enter two crazy computer science majors and one crazy idea: to build their own autonomous flying vehicle.

As already stated, the notion of an autonomous flying vehicle was not new, and thus there was a precendent set that the task could in fact be accomplished. The question was, could two comp sci majors with extrememly minimal engineering skills and absolutely no notion of aeronautical physics get something in the air? A little bit of googling on my part led to an answer: maybe. The result of this internet scavenger hunt was this website: http://www.seattlerobotics.org/encoder/200311/weimer/bxflyer.html. Not only could this task be accomplished, it has already been tried and has even been relatively successful.

After convincing ourselves that the job could be done, and possibly even in a semester, we needed to convince our professor. I believe it went something like this: Us - "Gary, can we build a flying robot?", Dr. Parker - "No, but you can try." Well, the challenge was most certainly on now, if it hadn't been already (though I am pretty sure it had been, I'll need to check with Owen).

Doubt...followed by hope

So we were a week into class and we had permission to build a flying robot. So how do we do it? Well, we needed a design (similar to the one found on the website listed above). The four propellers made sense to our simple aeronautical minds, but we had no idea how to calculate lift, weight ratios, all that good jazz. This is when Owen made his owen breakthrough after some googling. We thought our first site was a find, well, Owen found better. Check it out here (we have digitally copied it to our own servers): http://oak.conncoll.edu/~ojrac/draganfly-mod.pdf. It turns out a certain P. McKerrow of the University of Wollongong has not only looked at the same problems we faced, but he wrote a paper describing them and some of their solutions. The internet is great! Now armed with even more tools to get on our way.

Where we stand

You are now all caught up with out thought and action processes. So where do we stand? We are currently deciding on the parts to purchase and on some general design philosophies, which I will describe in later posts as I begin to fully understand the project in front of us. For now, here are our project goals:

  • Build a four-rotor helicopter vehicle
  • Automate this device with BASIC Stamp II microcontrollers
    • fine motor control
    • auto balancing sensing
    • ultrasound range finding sensors
  • Eventually integrate this flying robot into a network of other flying robots. For more on that, check out my other page: COM 496 - Robotic Networking.