Another kind of cool development is that we were asked to see if we could make a unmanned ground vehicle,UGV, with the same brains as we use in the UAVs. That combined with our ripe fruit turret idea gave me a bunch of new ideas about how to separate the hardware from the software stacks. The turret will use some interesting ideas on color detection and correction to detect whether fruit is ripe enough to be picked.
Now there is a UGV in the mix. What better a system to tow the turret around, than a 1/5th scale 4WD buggy. It is also leading us onto a bunch of other applications with the same device. Our new ideas, we hope are very investment worthy. If President O actually does something for small business, then we may be able to attract some investment. I think that there are several interesting campus or property management applications that will make the software easy enough to develop and/or repurpose.
Hopefully, I will get some more pictures of our electric conversion of the buggy and some assembly stuff. So that everyone can get an idea of how to do the electric conversion and the other steps that we took setting things up. We have some math that we have already worked out to hopefully help reduce some of the initial setup mistakes. Many scientific papers all say that small alignment errors in setup can ruin the mathematical assumptions that are made in software. That is why we keep trying to set up our software and then back out the math. Not always a working approach, but it is better than thinking everything is perfect.
Neah, engineers are never perfect... we are within 20%, 80% of the time.
Buzz Labs' unmanned vehicle blog and cool DIY remote controlled stuff blog. For techies by techies, maybe also some interesting tidbits about small business and international business.
Follow us on :
Monday, December 14, 2009
As If You Thought I Have Not Been Working
So I have been trying to get some interesting pictures of the layup of the Big Baby fuselage. However, the pictures that I do have are not as demonstrative as I would like. I guess I will have to get down there and take some myself. All in all, the mold concept worked and the internal, integral structure also seems to be pretty successful.
Our idea, is to mold a certain amount of internal structure into our composite molds. The interest is to reduce production time of aircraft to the limit of curing and finishing time. More advanced resins could be used in the future. Our experiments are with normal 60 and 90min set air-cure epoxies. We also used a male mold to reduce our total investment. Surface finish is less than important to see for these experiments. They are about the viability of integral structure composite lay ups. I have said that last bit a few times, but I have received several comments about this.
The next step is to relief the wings so that they make a pocket, lift system that will effectively create a similar cross-section to the metal equivalent airframe.
Our idea, is to mold a certain amount of internal structure into our composite molds. The interest is to reduce production time of aircraft to the limit of curing and finishing time. More advanced resins could be used in the future. Our experiments are with normal 60 and 90min set air-cure epoxies. We also used a male mold to reduce our total investment. Surface finish is less than important to see for these experiments. They are about the viability of integral structure composite lay ups. I have said that last bit a few times, but I have received several comments about this.
The next step is to relief the wings so that they make a pocket, lift system that will effectively create a similar cross-section to the metal equivalent airframe.
Thursday, December 3, 2009
Adventures in Composites: A Bright Idea
So after many months of gnawing on how to reduce the construction time of uavs and model aircraft, we finally decided to watch a million youtube movies. Sating ourselves on anything that had anything to do with composite lay ups we set off onto our own project. The first version of this idea is a proof of concept experiment rather than a real product. Aircraft Spruce sent us some great almost silken 2.5oz/yd^2 fiberglass.
This is an experiment in how to create multi-cell,internal structure in composite structures. If an airframe just needs a few reinforcements, that would go a long way to reducing the production costs of a unit model. Having built several models now with varying levels of success. It is clear, the longer it takes to produce a model, the more likely it will have issues. It could be as simple as being heavy, due to liberal adhesive use. Or just general issues such as fiber breakage or delaminations due to mis drilling or toughness issues in large unsupported panels.
After watching many others' techniques and lots of research into how successful airframes are created. It is about reducing the handling of each piece. The best paint jobs are ruined by finger prints, finishes scratched, just because they had the most chances to get ruined before delivery. Our concept centered around simple low curvature lay ups, that could be lain individual. Then stiffeners installed before the final layers are put down. Each mold would then be set to cure. Final assembly, would be put in place in the planes perpendicular to the molds to join the sides together and to increase the technical stiffness of the airframe.
Our design required a center web and some easy radii transitioning each of the perpendicular webs. We sectioned our fuselage to have three dorsal access bays. The fuselage was then bisected so that we had two symmetric halves and three continuous doors. Empennages and noses are difficult to build and to shape. There is always an issue with the symmetry or the strain in the materials during the curing process. Careful attention was paid to each of these areas to reduce the known issues that had ruined some of our previous projects.
Our split molds were then mounted to three inch styrofoam wall insulation. Not the ball stuff, this is the small,closed-cell material with wood glue. Everything was painted several times with latex enamel. The enamel did not stick during the first few coats. It probably has to do with the static charge that built up during the work. There was an eventual critical coating area that finally whetted the surface. Once the surface finally whetted, the coats proceeded quickly.
We found several movies about hand-lain composites that kind of tipped us off on how not to complicate our chemistry. They all had a few things in common, latex paint and paste wax as the sealant and release agents. After fourth coat of latex paint, Johnson's paste wax was applied liberally and hand-buffed to a shine. Each mold and the foam several inches (3-4") from the model was covered and buffed.
Then it was all let rest for a day.
This is an experiment in how to create multi-cell,internal structure in composite structures. If an airframe just needs a few reinforcements, that would go a long way to reducing the production costs of a unit model. Having built several models now with varying levels of success. It is clear, the longer it takes to produce a model, the more likely it will have issues. It could be as simple as being heavy, due to liberal adhesive use. Or just general issues such as fiber breakage or delaminations due to mis drilling or toughness issues in large unsupported panels.
After watching many others' techniques and lots of research into how successful airframes are created. It is about reducing the handling of each piece. The best paint jobs are ruined by finger prints, finishes scratched, just because they had the most chances to get ruined before delivery. Our concept centered around simple low curvature lay ups, that could be lain individual. Then stiffeners installed before the final layers are put down. Each mold would then be set to cure. Final assembly, would be put in place in the planes perpendicular to the molds to join the sides together and to increase the technical stiffness of the airframe.
Our design required a center web and some easy radii transitioning each of the perpendicular webs. We sectioned our fuselage to have three dorsal access bays. The fuselage was then bisected so that we had two symmetric halves and three continuous doors. Empennages and noses are difficult to build and to shape. There is always an issue with the symmetry or the strain in the materials during the curing process. Careful attention was paid to each of these areas to reduce the known issues that had ruined some of our previous projects.
Our split molds were then mounted to three inch styrofoam wall insulation. Not the ball stuff, this is the small,closed-cell material with wood glue. Everything was painted several times with latex enamel. The enamel did not stick during the first few coats. It probably has to do with the static charge that built up during the work. There was an eventual critical coating area that finally whetted the surface. Once the surface finally whetted, the coats proceeded quickly.
We found several movies about hand-lain composites that kind of tipped us off on how not to complicate our chemistry. They all had a few things in common, latex paint and paste wax as the sealant and release agents. After fourth coat of latex paint, Johnson's paste wax was applied liberally and hand-buffed to a shine. Each mold and the foam several inches (3-4") from the model was covered and buffed.
Then it was all let rest for a day.
Adventures in Composites: Two Bogans and the Art of the Lay... Up
After a year of sitting, our polyester resin had spoiled. So we contacted some people and they said you could do it with just about any medium cure time epoxy. Out into the proper disposal container for petro-chemical waste. Yeah, I went there. Off to the local hardware shop for some epoxy. We bought several batches of 60 min epoxy. Some of the information that our friends told us suggested that we could use isopropyl alcohol to help keep the viscosity of the epoxy down as it is laid up.
Information like this is when it gets exciting. We found out a few things. You can paint the alcohol onto a layer to help flow the epoxy and to reduce the bubbles and flatten wrinkles. I would suggest that pour some alcohol into a cup and paint it on where you need it. Each layup will be different so it is hard to say where you would have issues.
There were some bubble generators in the seam where the semi-mold met the backing. This is probably pretty obvious, but it was due to training air under the resin laden cloth. Our mold also had several regions with nearly perpendicular sections which were hard to wet. In areas like that, I would suggest liberally pre-painting. Be careful not to pool the resin in the bottom since that is not where you want the part to be strong. Another observation was to make sure that when each layer is put down, both people should work in the same direction. Do not work the resin from the nose and the tail. It makes wrinkles and other defects.
It is very important to make sure that each layer has as much of the resin out, or at least even distributed as possible. This means that all of the bubbles, wrinkles and puddles need to be worked toward the edge of the layup. A roller and brushes are the weapons of choice for this work. The handle edges are great for wringing out excess resin from tight radii.
Information like this is when it gets exciting. We found out a few things. You can paint the alcohol onto a layer to help flow the epoxy and to reduce the bubbles and flatten wrinkles. I would suggest that pour some alcohol into a cup and paint it on where you need it. Each layup will be different so it is hard to say where you would have issues.
There were some bubble generators in the seam where the semi-mold met the backing. This is probably pretty obvious, but it was due to training air under the resin laden cloth. Our mold also had several regions with nearly perpendicular sections which were hard to wet. In areas like that, I would suggest liberally pre-painting. Be careful not to pool the resin in the bottom since that is not where you want the part to be strong. Another observation was to make sure that when each layer is put down, both people should work in the same direction. Do not work the resin from the nose and the tail. It makes wrinkles and other defects.
It is very important to make sure that each layer has as much of the resin out, or at least even distributed as possible. This means that all of the bubbles, wrinkles and puddles need to be worked toward the edge of the layup. A roller and brushes are the weapons of choice for this work. The handle edges are great for wringing out excess resin from tight radii.
Sunday, November 22, 2009
No Chipotle's for me!
I know this is completely off topic. For the 3rd and final time, I do not eat Chipotle's. I have gotten royally sick eating there every time I have eaten there. Guess I am a Moe's man.
WTF you have to pay for soggy chips and no queso? What were they thinking? Moe's rules!
I was sick all day Saturday having been attacked by either Jimmy John's or Chipotle's. So Both are right out. It was a miserable GI problem, I thought my gut was going to explode.
WTF you have to pay for soggy chips and no queso? What were they thinking? Moe's rules!
I was sick all day Saturday having been attacked by either Jimmy John's or Chipotle's. So Both are right out. It was a miserable GI problem, I thought my gut was going to explode.
Sunday, November 15, 2009
So Much For our Idea
We were thinking that we could roll our Schoolgirl UAVs with some great NEU 1915/1.5Y motors to swing our huge props in a dual-motor configuration. I am sure it would work, but I think we will put it into a pusher configuration.
We kind of knew that the motors were big. I got a pair of these 2.7kW beasts from the guys down at Esprit Model in Palm Bay,FL. They are another great supplier of rc stuff. Esprit Model is good about not advertising that they have hard to find stuff and then them being out of stock. Better to know, than to get an email two weeks later saying that they cleared your payment but that you will not get anything for four weeks.
So I got these beer cans. I mean the motors are as big as beer cans. Not an issue, they look great and have built in fans to help with air flow (heli version). I just think that motors are way too big for our school girls. The kevlar skin that we used is way too dense for the skin application. The carbon fiber equivalent material was great and the other airframe came out pounds lighter. I thought I could pay the piper by just putting down more power. It is not going to work that way. We will have to put it in a pusher configuration.
That is one of the cool things about the school girl. We can run with two under-wing motors, as a puller or a pusher. The changes do not effect the airframe much and really are about moving some power wires in the fuselage. It is really convenient. I hope the balsa kits come out well, it should be a great sport flier.
We kind of knew that the motors were big. I got a pair of these 2.7kW beasts from the guys down at Esprit Model in Palm Bay,FL. They are another great supplier of rc stuff. Esprit Model is good about not advertising that they have hard to find stuff and then them being out of stock. Better to know, than to get an email two weeks later saying that they cleared your payment but that you will not get anything for four weeks.
So I got these beer cans. I mean the motors are as big as beer cans. Not an issue, they look great and have built in fans to help with air flow (heli version). I just think that motors are way too big for our school girls. The kevlar skin that we used is way too dense for the skin application. The carbon fiber equivalent material was great and the other airframe came out pounds lighter. I thought I could pay the piper by just putting down more power. It is not going to work that way. We will have to put it in a pusher configuration.
That is one of the cool things about the school girl. We can run with two under-wing motors, as a puller or a pusher. The changes do not effect the airframe much and really are about moving some power wires in the fuselage. It is really convenient. I hope the balsa kits come out well, it should be a great sport flier.
Facebook Advertising 3400 people exposed 5 hits received
This week, I ran a basic advertisement to see how effective it would be. I cross-posted a philanthropic interest for Veteran's Day. If I sold any of the following shirts,
shirt #1 or shirt #2
My idea was to donate any proceeds to the Alachua County Veterans of Foreign Wars post. They do lots of work at the Gainesville VA hospital. I sent it to three veteran's groups for 3400 possible people. I got 5 hits. Woohoo!
Ok, not the glorious turn out that I had hoped. However, it was an interesting thing that it was such a huge failure. I guess it did not cost me anything, but I would happily donate any proceeds from these shirts to help Iraq and Afghanistan veterans.
More adventures in internet marketing as I come up with them. Reddit ok, I thought I would get more traffic by getting into some of the track back systems. Reddit.com put up 120 links, not one had anything to do with my content. Heck, even Google AdSense has trouble with this. From what I can see, it is not so good at uncommon keywords. So short of articles of white panties on eastern European schoolgirls I am not sure how helpful AdSense is even for my topics.
shirt #1 or shirt #2
My idea was to donate any proceeds to the Alachua County Veterans of Foreign Wars post. They do lots of work at the Gainesville VA hospital. I sent it to three veteran's groups for 3400 possible people. I got 5 hits. Woohoo!
Ok, not the glorious turn out that I had hoped. However, it was an interesting thing that it was such a huge failure. I guess it did not cost me anything, but I would happily donate any proceeds from these shirts to help Iraq and Afghanistan veterans.
More adventures in internet marketing as I come up with them. Reddit ok, I thought I would get more traffic by getting into some of the track back systems. Reddit.com put up 120 links, not one had anything to do with my content. Heck, even Google AdSense has trouble with this. From what I can see, it is not so good at uncommon keywords. So short of articles of white panties on eastern European schoolgirls I am not sure how helpful AdSense is even for my topics.
Wednesday, November 11, 2009
Special Thanks to Willy from Nutech-racing.com
A special thanks to Willy from www.Nutech-Racing.com. He is knowledgeable, friendly, freaky fast. I mean he is faster than Jimmy John's sammiches at lunch time. Check out Willy's site for fast, courteous service and great prices on rc stuff and UGV cross-over information.
Thanks again Willy!
Thanks again Willy!
If you were an UGV, what kind of truck would you be?
This week I have been digging into the 2d plane again. Yeah, that sounds kind of odd, but I think it is pretty accurate. I am looking for a platform that will let me test my own avionics and code in a way that will not have $10k at 300' and then in a heartbeat have it smashed into dust . The ground does rush up pretty quickly at the wrong times.
One of my colleagues at my real job has egged me on, so I have been evaluating what it takes to get my software to work in a constant altitude kind of setup. Ok for all non-geeks, it means on a truck. I think that the premise has been tossed around several times.
I found that several things during this evaluation. One, electric 1/5th scale trucks are not common. There are lots of 25cc gasser trucks. The three that I was reviewing were:
HPI Baha 5T
NuTech Mega Monster
Redcat Racing
After reading a bunch of information about all of these chassis, and 10's or 100's of reviews and projects. I even found 1 from Sony on the HPI... The Nutech seems to be ahead in the research. It does not weigh as much as the Redcat. The Nutech is Chinese, try not to just mail money to them these days. The HPI has great reviews but is significantly more expensive. I have not found anything to say that one is better than the others. So it may come down to weight and cost.
I will not be using the 23-26cc engine. It will be replaced with some pretty beefy NEU motors and a lot of LiPo. My Mini9 will probably be its brain for the foreseeable future. I do need to work on a COM to handle the code.
Kind of cool to watch the movies of these guys flipping around. I know mine won't do it, but will get its fair share of curb crashing I am sure.
One of my colleagues at my real job has egged me on, so I have been evaluating what it takes to get my software to work in a constant altitude kind of setup. Ok for all non-geeks, it means on a truck. I think that the premise has been tossed around several times.
I found that several things during this evaluation. One, electric 1/5th scale trucks are not common. There are lots of 25cc gasser trucks. The three that I was reviewing were:
HPI Baha 5T
NuTech Mega Monster
Redcat Racing
After reading a bunch of information about all of these chassis, and 10's or 100's of reviews and projects. I even found 1 from Sony on the HPI... The Nutech seems to be ahead in the research. It does not weigh as much as the Redcat. The Nutech is Chinese, try not to just mail money to them these days. The HPI has great reviews but is significantly more expensive. I have not found anything to say that one is better than the others. So it may come down to weight and cost.
I will not be using the 23-26cc engine. It will be replaced with some pretty beefy NEU motors and a lot of LiPo. My Mini9 will probably be its brain for the foreseeable future. I do need to work on a COM to handle the code.
Kind of cool to watch the movies of these guys flipping around. I know mine won't do it, but will get its fair share of curb crashing I am sure.
Sunday, November 8, 2009
Ok, I guess it should not bother me
I have been researching the Android 2 as a robotics platform. Several people have weighed in to say that the only big advantage of Google's Android 2 is that it is essentially free to distribute. However, it has other overhead that has to be overcome. It has to be recompiled per processor, so there is more to sourcing cpus and instruments for it.
I did find in my rolodex that Toradex has a Limestone PDA kit that claims to boot Android 1.6. I have to keep looking. One of my mad scientist ideas is the multiple chips flying closely together to distribute computing projects into manageable chunks. I will keep looking for more. I am not an EE so it is important these solutions be mostly plug and play.
The only "robot" stuff, that I have found before are canned apps from canned boards. I guess I was thinking robot not rc kit. Yeah, I use a lot of rc stuff, but I am not looking to directly control the devices at every turn. They should have increasing levels of autonomy. However, I do have to say that I like that some companies have the same idea that I do. The kit I have found that has the most coverage is the Surveyor SRV-1. It looks interesting enough, but PIC sucks. ;) An interesting couple of "rc toys" on Android movies can be found at robots.net.
I did find in my rolodex that Toradex has a Limestone PDA kit that claims to boot Android 1.6. I have to keep looking. One of my mad scientist ideas is the multiple chips flying closely together to distribute computing projects into manageable chunks. I will keep looking for more. I am not an EE so it is important these solutions be mostly plug and play.
The only "robot" stuff, that I have found before are canned apps from canned boards. I guess I was thinking robot not rc kit. Yeah, I use a lot of rc stuff, but I am not looking to directly control the devices at every turn. They should have increasing levels of autonomy. However, I do have to say that I like that some companies have the same idea that I do. The kit I have found that has the most coverage is the Surveyor SRV-1. It looks interesting enough, but PIC sucks. ;) An interesting couple of "rc toys" on Android movies can be found at robots.net.
Friday, November 6, 2009
Android 2 or windows 7
I saw this and liked it. If anyone has any real reason to choose one over the other without the opensource vs. proprietary hate. I would be interested in hearing it. The thrust is for robotics and control systems, not multi-media or similar applications.
UGV autopilot
Taking the lessons learned from the UAV stuff, I am trying to trim down the UAV pilot to a UGV pilot. The two have different requirements so I am hoping that it can all be put into the mission planner. I have found playing with the UAV autopilot that the event driven solution works well, but is a bit honery.
So I am working on a bus model. Where the individual managers all call into the bus to pass messages, then the bus manages the message delivery. This should decouple the messaging. I was trying to avoid the inevitable hard coding of observers and subjects in the code. This would make the relationships less fixed and hopefully ini-file-able.
I have some other lessons learned about this.
One other question, does anyone have any opinion of Java on Android 2 rather than c#.NET on Windows 7? They would both target netbooks or computer on modules (COM). Let me know if anyone has any practical/constructive opinions of these platforms. info "at" fatmanflying.com
So I am working on a bus model. Where the individual managers all call into the bus to pass messages, then the bus manages the message delivery. This should decouple the messaging. I was trying to avoid the inevitable hard coding of observers and subjects in the code. This would make the relationships less fixed and hopefully ini-file-able.
I have some other lessons learned about this.
One other question, does anyone have any opinion of Java on Android 2 rather than c#.NET on Windows 7? They would both target netbooks or computer on modules (COM). Let me know if anyone has any practical/constructive opinions of these platforms. info "at" fatmanflying.com
Sunday, November 1, 2009
Stereographic Vision
I have been messing with the AForge library now for a week. It is the best known and rated .net image processing library. Everyone has tried CV and getting the interop wrappers to work is tough. I have given up several times myself trying to just get all of the constants wrapped.
I have been working on a version of their two camera tracking system. My cameras are a bit lager pixel counts than his, and I think that is where some of my timing issues are coming from. I think that the other piece that is beating me at the moment is the revisualization part of it. I think my composited movie needs to be output through the player control or just written to disk. I will have to monkey around with it. It may turn out that the movie meeds to go 360p or something to this effect and increase the frame rate.
I am pretty sure that it is not a processing power thing, more about crappy code on my part. If the frames are smaller, my inefficient algorithms will probably be less impacted. I may also have some other ideas on how to composite the video, frame-wise may also be a bit on the slow side. Let's go for snappy. I have enough to do what the original project was intended for. It can track an object in the scene. Now, I need to get it up so that I can pick which object to track.
Will keep everyone posted.
I have been working on a version of their two camera tracking system. My cameras are a bit lager pixel counts than his, and I think that is where some of my timing issues are coming from. I think that the other piece that is beating me at the moment is the revisualization part of it. I think my composited movie needs to be output through the player control or just written to disk. I will have to monkey around with it. It may turn out that the movie meeds to go 360p or something to this effect and increase the frame rate.
I am pretty sure that it is not a processing power thing, more about crappy code on my part. If the frames are smaller, my inefficient algorithms will probably be less impacted. I may also have some other ideas on how to composite the video, frame-wise may also be a bit on the slow side. Let's go for snappy. I have enough to do what the original project was intended for. It can track an object in the scene. Now, I need to get it up so that I can pick which object to track.
Will keep everyone posted.
Friday, October 23, 2009
Shout Outs to Some Small Businesses run By Great Guys
We are all in this together. I wanted to take a second to drop some names for everyone. If you need composites work done or molds made at reasonable rates. Call Robert at Mohrbacher Composites he really did a great job on some sick projects. If you have more normal fabrication requirements, the guys at Impact Fab, tell Ross, that the Buzz Labs boys sent you. Ross works wonders with his water jet.
Thanks guys for helping us with my bad ideas!
Thanks guys for helping us with my bad ideas!
Phidgets UltraSonic RangeFinder
The rangefinder is not a Phidgets. They are reselling a LV Max Sonar EZ1 from MaxBotix. You get in the bag the sensor (transceiver) and a small wire bundle. The wires need to be soldered into the proper pins. Just for reference from the pin closest to the mounting hole,
black
red
open
green
white
open
open
wire meanings
black - ground
red +5V
green signal to trip the ultrasonic ping, +5V I think, but I do not use it
white 5V signal
This will cable your phidgets three wire signal cable correctly. Remember this is not a normal sensor, it is one of their analog sensors. So you will need one of their a/d boards or interface boards in their terminology. The event that you will want to hook, the SensorChange event. Everything the system reads a new voltage on the port it fires sensor change. See my post on the 888 interface kit to see how to set up the interface kit.
Here is my way of switching the data so you only need one method for any port change.
There are some other details in this code. Since I use a bunch of helper methods to calibrate the data coming out. Remember the values (Args.Value) come out as a double so you can write a simple linear interpolation for you that will get your data back into usable units from Voltage. For simplicity's sake, I have the interpolation points in an xml config file that is read in at start time to handle each of the instruments. That way the values can easily be changed for recalibration.
The code I have presented is good simple code that is quick and should work for almost any purpose and uses solid error trapping techniques.
black
red
open
green
white
open
open
wire meanings
black - ground
red +5V
green signal to trip the ultrasonic ping, +5V I think, but I do not use it
white 5V signal
This will cable your phidgets three wire signal cable correctly. Remember this is not a normal sensor, it is one of their analog sensors. So you will need one of their a/d boards or interface boards in their terminology. The event that you will want to hook, the SensorChange event. Everything the system reads a new voltage on the port it fires sensor change. See my post on the 888 interface kit to see how to set up the interface kit.
Here is my way of switching the data so you only need one method for any port change.
protected void SensorChange(object Sender, SensorChangeEventArgs Args)
{
try
{
InstrumentType _type = InstrumentType.notset;
int _index = 0;
switch (Args.Index)
{
case 7:
_type = InstrumentType.ultrasonicRangeFinder;
_index = 4;
break;
case 6:
_type = InstrumentType.ultrasonicRangeFinder;
_index = 3;
break;
case 5:
_type = InstrumentType.ultrasonicRangeFinder;
_index = 2;
break;
case 4:
_type = InstrumentType.ultrasonicRangeFinder;
_index = 1;
break;
case 3:
_type = InstrumentType.ultrasonicRangeFinder;
_index = 0;
break;
case 2:
_type = InstrumentType.pressureTotal;
totalPressure = convertVoltageToUnit(_type, Args.Value, _index);
speed = getPressureSpeed(totalPressure, staticPressure, staticTemperature);
break;
case 1:
_type = InstrumentType.temperature;
staticTemperature = convertVoltageToUnit(_type, Args.Value, _index);
speed = getPressureSpeed(totalPressure, staticPressure, staticTemperature);
break;
case 0:
_type = InstrumentType.pressureStatic;
staticPressure = convertVoltageToUnit(_type, Args.Value, _index);
speed = getPressureSpeed(totalPressure, staticPressure, staticTemperature);
pressureAltitude = getGeoPotentialAltitude(staticPressure / units.kPaToPsf);
break;
}
if (_type == InstrumentType.ultrasonicRangeFinder)
{
rangeFinders[_index] = convertVoltageToUnit(InstrumentType.ultrasonicRangeFinder, Args.Value, _index);
}
}
catch (Exception _exc)
{
throw new Exception(className + " protected void SensorChange( Sender, Args) :: " + _exc.Message + "\n");
}
}
There are some other details in this code. Since I use a bunch of helper methods to calibrate the data coming out. Remember the values (Args.Value) come out as a double so you can write a simple linear interpolation for you that will get your data back into usable units from Voltage. For simplicity's sake, I have the interpolation points in an xml config file that is read in at start time to handle each of the instruments. That way the values can easily be changed for recalibration.
The code I have presented is good simple code that is quick and should work for almost any purpose and uses solid error trapping techniques.
Do I want to see both sides of your pretty face?
This week I am still waiting for motors. It turns out my motor supplier has been on vacation this week, how dare he? Sorry Dave I just needed to get in the jab. So I had this new idea for how to progress, I was thinking about something someone said to me. They were explaining how someone did not like to fly their great looking soarer because of how much it cost to replace.
Then I sat there looking at the School Girl UAS on the table and thought. ZOMG! It costs like 2-3x as much as the guy's soarer. What the hell am I thinking? I have to make sure that this thing can be showable to other people. It does have to fly, to demonstrate that those Engineering school was not a waste of time. I just want to make sure I do not throw two months of work and a thousand dollars into the ground due to bad luck and clean living. All of my best ideas are inspiration this time, I swear there was no barley soda involved. Ok, maybe some, but it was good stuff. The decision was made to make a new version of the truck so that I could work more on my version of the IMU and control system as well as make a safer platform for developing technologies for the UAS.
Long story short, a new beastie was conceived. Like the sign said, always well conceived, unlike people. Now this new ground guy lets me do lots of experiments with much less of the z-axis problem. The z-axis problem is acceleration due to gravity. Something that drives along the ground can still have great mishaps but it is easier to teach a car to drift a corner than it is to teach a plane to avoid turbulence.
So one of the first things about this idea is how to navigate the buggy. Actually, this is less of an issue than it may seem and allows us to do some much more interesting things. Monitoring the instruments and planning a heading to a goal is mostly done with the code that I have. What does this have to do with my pretty face? Navigation is not as interesting as deciding how to see. Many times navigation is more than careening off in the direction that leads you to the goal the fastest. What if there is a reason to follow a path? How do you find the path?
I sat back and ran through a series of thought experiments on how to execute this. The following questions came to me that needed an answer:
- If there is a reason to follow a path, then how do I find the path?
- If I find a path how often do I have to look for the path?
- Maybe I want the video stream to get back to an operator and still be able to work on the data, how do I do it?
- How much processing is really necessary to find the important elements of a scene?
- An element of a scene is important, how do I decide if it is important for driving or for identifying to an operator?
- This is a lot of processing, how can I reduce it to use lower-powered systems to reduce processing costs?
As a matter of fact, the machine itself cannot make a lot of use of stereoscopic vision. Not that it is not useful, but that is an operator technology not a machine technology. The machine can use the stereoscopic vision to detect objects that may cause negative performance impacts . A really shiny thing in the way could "flash" and make a very small thing seem very big and that would possibly confuse the system, or a shadow may seem like a hole and cause unnecessary course correction. Coordinating objects in the two-camera system will allow false behaviors to be avoided or at least identified. It could also be used to do simple comparisons... is this blob like that one? and then reduce useful processing by discarding one of the copies.
If we can process the scene in such a way that we can slow the effective frame rate down by not checking for the path as often it is one less object in the scene to be processed. Optical flow algorithms will help with this because you can quickly get velocity estimates for a given object relative to your position. As that changes you can say... same element do not reprocess it. If we identify the objects in the scene and discard the ones that are clearly not as important then we can process many fewer regions of the scene and or pass the processing back to an operator.
This is going to be a multi-part post about basic vision systems and how I think it should be brought together and used in many applications without changing the code. How a few observations about what we want to do and what it really means may make a lot of decisions easier in the design. This code will focus on commodity components and instrumentation and control electronics from Phidgets and SparkFun.
Tuesday, October 20, 2009
The Girls Love the Long Ball, But the Boys Love the Spin
Someone once told me that it is not the boom, it is all about the shock wave. I guess that is true, you need to feel the motion of the ocean.
You ask, what does this have to do with gyros? Well, if you cannot figure out how fast it is twisting, there is no way to know how far your ball will go. Yeah, actually a lot, since driving a golf ball is not a momentum problem alone. The dimples hold the boundary layer on and make it go much farther.
Gyroscopes are cool, I have the neat little 300 deg/s board from SparkFun, built on a 3DOF IMU. I soldered on some pins so that it is easier to connect to. Connected the ground to the system ground and connected each of the signal pins to a separate "connector". Really, easy and I am a bit electrically declined.
I then set up an easy pseudo code system to watch the ISensor.DataUpdated method. That lets me see the phidgets.datachanged event in my little API. The delegate that I use for ISensor.DataUpdated feeds my smoothing algorithm. I use the smoothing algorithm to keep out shorts and wonky voltage changes that happen. This would feed the Kalmann filter which I still do not have.
I then feed these data updated events into an ArrayList and do my Runge-Kutta routines on them to integrate the unknown functions. This running integration is how I get an approximation of the position of the gyro. Remember gyros return the rate of change of the gyration, an angular velocity so to speak.
We can do a simple integration to get back to a position.
xi = xdot*dt+xi-1
for constant timestep dt and the previous position, xi-1.
I will put some code together for the next post on this.
You ask, what does this have to do with gyros? Well, if you cannot figure out how fast it is twisting, there is no way to know how far your ball will go. Yeah, actually a lot, since driving a golf ball is not a momentum problem alone. The dimples hold the boundary layer on and make it go much farther.
Gyroscopes are cool, I have the neat little 300 deg/s board from SparkFun, built on a 3DOF IMU. I soldered on some pins so that it is easier to connect to. Connected the ground to the system ground and connected each of the signal pins to a separate "connector". Really, easy and I am a bit electrically declined.
I then set up an easy pseudo code system to watch the ISensor.DataUpdated method. That lets me see the phidgets.datachanged event in my little API. The delegate that I use for ISensor.DataUpdated feeds my smoothing algorithm. I use the smoothing algorithm to keep out shorts and wonky voltage changes that happen. This would feed the Kalmann filter which I still do not have.
I then feed these data updated events into an ArrayList and do my Runge-Kutta routines on them to integrate the unknown functions. This running integration is how I get an approximation of the position of the gyro. Remember gyros return the rate of change of the gyration, an angular velocity so to speak.
We can do a simple integration to get back to a position.
xi = xdot*dt+xi-1
for constant timestep dt and the previous position, xi-1.
I will put some code together for the next post on this.
Friday, October 16, 2009
Phidgets Accelerometers, the Magic of Three-Axes
The three-axis accelerometer is a piezo-electric accelerometer that is about 1" square. It is pretty good and have never seen any issues with drift or orientation issues. It measures each axis in units of g Do not forget to convert to your units, so a reading of 1.2 is actually an acceleration of 38.6 ft/s/s. I just make a little helper function to convert the readings when the phidgets_accelerationchanged method fires.
Hopefully, that will help clean up your code by reducing the risk of double converting units. Even NASA makes this mistake. One of the first things that I set up is a library of unit converstion factors. That way it is less risky if the user wishes to see the measurements in , mks or cgs and my software interanlly uses US Customary slug-ft-lbf. I do not do any conversions in the code. Just read the electrical signals from the transducers and convert them to real units, consistent with the system. Do not try and convert back and forth within the code, it will just be miserable to find.
You convert to any system that is different than your base unit system until you display the data. You can easily set a flag in the display object that shows the data to the user and multiply out the measurements at presentation time via the decoration pattern. To be honest, the Phidgets API is awesome. It makes short work of connecting and managing their instruments, so the code to start an interface kit is not so different from the accelerometer.
Another helper method that is constantly requested is converting from accelerations to roll and pitch. You can do the trigonometry yourself, but if gravitation is assumed to act in the -Z direction you can work out the basic orientation of the accelerating object. This can be fooled by large or quick orientation changes, but for the most part sampling frequency can fix this. So I would make sure that you do as little as possible that may muddy the event handler system. They are really fast and that is a good thing in this case.
The one thing you will notice is that you cannot get the yaw from the accelerations. That makes sense if you think about it, flat rotation perpendicular to gravity would not be measured. I usually run a compass in the systems too. That makes the 3-1-3 rotation easy to move between body reference frames and global reference frames. I would suggest that you multiply out the cells for the rotations in a separate method each so that you can just multiply them by calling each method in turn with an argument of the last rotation.
Hopefully, that will help clean up your code by reducing the risk of double converting units. Even NASA makes this mistake. One of the first things that I set up is a library of unit converstion factors. That way it is less risky if the user wishes to see the measurements in , mks or cgs and my software interanlly uses US Customary slug-ft-lbf. I do not do any conversions in the code. Just read the electrical signals from the transducers and convert them to real units, consistent with the system. Do not try and convert back and forth within the code, it will just be miserable to find.
You convert to any system that is different than your base unit system until you display the data. You can easily set a flag in the display object that shows the data to the user and multiply out the measurements at presentation time via the decoration pattern. To be honest, the Phidgets API is awesome. It makes short work of connecting and managing their instruments, so the code to start an interface kit is not so different from the accelerometer.
do
{
//System.Threading.Thread.Sleep(10);
if (acc0.Attached)
{
Console.WriteLine("_acc0 attached");
//accelerometer events
acc0.Attach += phidgets_Attach;
acc0.Detach += phidgets_Detach;
acc0.Error += phidgets_Error;
acc0.AccelerationChange += _acc0_AccelerationChange;
}
else
{
Console.WriteLine("retry : " + retry + " waiting for acc0 attach");
}
retry++;
} while (retry < 10 && !acc0.Attached); #region helperMethods #region Phidgets event handlers ///
/// handle the phidget device discovery events
///
/// /// protected void phidgets_Attach(object Sender, AttachEventArgs Args)
{
try
{
Console.WriteLine(Args.Device.Type + " attached.");
}
catch (Exception _exc)
{
throw new Exception(className + " protected void phidgets_Attach( Sender, Args) :: " + _exc.Message +
"\n");
}
} //phidgets_Attach
///
/// handle the phidget device discovery events
///
/// /// protected void phidgets_Detach(object Sender, DetachEventArgs Args)
{
try
{
Console.WriteLine(Args.Device.Type + " detached.");
}
catch (Exception _exc)
{
throw new Exception(className + " protected void phidgets_Detach( Sender, Args) :: " + _exc.Message +"\n");
}
} //phidgets_Detach
protected void phidgets_Error(object Sender, ErrorEventArgs Args)
{
try
{
Console.WriteLine("phidgets error : " + Args.Code + " " + Args.Description);
}
catch (Exception _exc)
{
throw new Exception(className + " protected void phidgets_Error( Sender, Args) :: " + _exc.Message +
"\n");
}
} //phidgets_Error
///
/// reads the acceleration from the Phidgets accelerometer
///
/// accelerometer object/// essentially an array of three doubles, one for each direction measuredprotected void _acc0_AccelerationChange(object Sender, AccelerationChangeEventArgs Args)
{
try
{
rawAcc[Args.Index] = Args.Acceleration;
}
catch (Exception _exc)
{
Console.WriteLine(
className + " protected void _acc0_AccelerationChange( Sender, Args) :: " + _exc.Message + "\n"
);
}
} //_acc0_AccelerationChange
#endregion
Another helper method that is constantly requested is converting from accelerations to roll and pitch. You can do the trigonometry yourself, but if gravitation is assumed to act in the -Z direction you can work out the basic orientation of the accelerating object. This can be fooled by large or quick orientation changes, but for the most part sampling frequency can fix this. So I would make sure that you do as little as possible that may muddy the event handler system. They are really fast and that is a good thing in this case.
///
/// calculate the euler angles from the local accelerations
///
/// acceleration toward the right wing, g [gravity multiples]/// acceleration toward the nose, g [gravity multiples]/// acceleration toward the ground, g [gravity multiples]/// headingprivate static void accel2euler(double Ax, double Ay, double Az, double Compass, out double[] EulerAngles)
{
EulerAngles = new double[3];
try
{
double g = Math.Sqrt(Ax * Ax + Ay * Ay + Az * Az);
/* Roll */
if (g != 0)
{
//EulerAngles[0]=Math.Atan2(Ay,Az);
EulerAngles[0] = Math.Atan2(Ay/g, -Az/g);
}else
{
EulerAngles[0] = Math.Atan2(Ay / 1, -Az / 1);
}
/* Pitch */
if (g != 0)
{
//EulerAngles[1] = Math.Asin(Ax/-g);
EulerAngles[1] = Math.Atan2(Ax / g, -Az / g);
}
else
{
EulerAngles[1] = Math.Atan2(Ax / 1, -Az / 1);
}
EulerAngles[2] = Compass; /* Yaw */
}
catch (Exception _exc)
{
throw new Exception(className + " public static void accel2euler( , " + Ax.ToString("0.000") + " , " +
Ay.ToString("0.000") + " , " + Az.ToString("0.000") + " , " +
Compass.ToString("0.000") + " ) :: " + _exc.Message + "\n");
}
}
The one thing you will notice is that you cannot get the yaw from the accelerations. That makes sense if you think about it, flat rotation perpendicular to gravity would not be measured. I usually run a compass in the systems too. That makes the 3-1-3 rotation easy to move between body reference frames and global reference frames. I would suggest that you multiply out the cells for the rotations in a separate method each so that you can just multiply them by calling each method in turn with an argument of the last rotation.
Driving Business to Your Website
This is one of the mor difficult aspects of internet marketing and small businesses. Many others can spend more resrouces to get the word out at any given time. I have tried to approach it from a step-wise perspective. First step was to get the basic website out, without content you have nothing. A buddy of mine said to make sure that you do not make sure that you do not cludder ideas or muddy your message trying to stuff too much on each page. There are plenty of ways to make the search engines pick up your content in systematic ways.
Next, gather up your all of your suppliers or products that you normally use and make a simple page that links out to their official pages, that way your name or website will be linked to theirs. This will not in and of itself make a huge contribution, but if they look up this junk sucks, it will bring up your name. ;) As they say, any advertising where they spell your name correctly, is good advertising.
I am not sure if this next step was the best, but I found some of the low cost tshirt and mouse pad sites and through a bunch of products out there. People in general would not associate technical ideas with a tshirt. However, it gives you a different lane of approach to your content. Make sure that you fill out the description sections of each item and try to make sure your main url shows up in as many places as possible. These link backs help your search engine scores and increase the possibility that someone will click through to your site. Traffic, even bounce traffic is good. You never know whose little brother will see a t-shirt with a logo and pass it onto their brother the director of your next customer's organization.
Another simple and seemingly the most effective plan of attack. Use your open source community. They are mindless minions of habit. Ok, that is a bit harsh. However, Sourceforge, CodePlex and similar sites have huge mostly anonymous traffic, if you can publish any of your source code as a project and link back to your website you will get the word out to a large audience of people
with similar interests. I have found that techies run in circles and that they are inexoribly drawn to cool projects even if they are not in their fields of expertise. Likewise, if you use a product that has a user community, by all means post. Try to be as active as possible and keep posting your url in your signature. That link back thing is the cheapest and simplest advertising you can achieve.
If you can manage it, you may also put up single page advertising sites with kind of universal message information on any of the better trafficked free hosting sites. Google, Microsoft and all of the 500 pound apes have free sites. Free is good, at this point you are trading time for initial expense. So put up your message pages and cross-link them as best as you can without making them look like the original Yahoo. Different url's linking back help increase your score. If they get you 2% more hits every month then you are 2% ahead for copying and pasting an advertisement to a database somewhere. When it gets taken down in six months for lack of updates, oh well, it was free.
Tweets that get sucked into the ether by retweeters are good too. However, it is not as guaranteed a method because they are simple text messages and can carry less information than the free poster sites. By all means, spam the web with your message. With billions if not trillions of pages, make sure that you get your information out there in as many places as possible.
Blogging is my last idea, but it is not as effective. Just from a time perspective you have to keep putting into it and that makes it more expensive than just chucking out some posters. Posters are good because you can have a graphical message. Even back in the day...
Tamany Hall said they did not care what they wrote, their constituents could not read... They could UNDERSTAND pictures.
Next, gather up your all of your suppliers or products that you normally use and make a simple page that links out to their official pages, that way your name or website will be linked to theirs. This will not in and of itself make a huge contribution, but if they look up this junk sucks, it will bring up your name. ;) As they say, any advertising where they spell your name correctly, is good advertising.
I am not sure if this next step was the best, but I found some of the low cost tshirt and mouse pad sites and through a bunch of products out there. People in general would not associate technical ideas with a tshirt. However, it gives you a different lane of approach to your content. Make sure that you fill out the description sections of each item and try to make sure your main url shows up in as many places as possible. These link backs help your search engine scores and increase the possibility that someone will click through to your site. Traffic, even bounce traffic is good. You never know whose little brother will see a t-shirt with a logo and pass it onto their brother the director of your next customer's organization.
Another simple and seemingly the most effective plan of attack. Use your open source community. They are mindless minions of habit. Ok, that is a bit harsh. However, Sourceforge, CodePlex and similar sites have huge mostly anonymous traffic, if you can publish any of your source code as a project and link back to your website you will get the word out to a large audience of people
with similar interests. I have found that techies run in circles and that they are inexoribly drawn to cool projects even if they are not in their fields of expertise. Likewise, if you use a product that has a user community, by all means post. Try to be as active as possible and keep posting your url in your signature. That link back thing is the cheapest and simplest advertising you can achieve.
If you can manage it, you may also put up single page advertising sites with kind of universal message information on any of the better trafficked free hosting sites. Google, Microsoft and all of the 500 pound apes have free sites. Free is good, at this point you are trading time for initial expense. So put up your message pages and cross-link them as best as you can without making them look like the original Yahoo. Different url's linking back help increase your score. If they get you 2% more hits every month then you are 2% ahead for copying and pasting an advertisement to a database somewhere. When it gets taken down in six months for lack of updates, oh well, it was free.
Tweets that get sucked into the ether by retweeters are good too. However, it is not as guaranteed a method because they are simple text messages and can carry less information than the free poster sites. By all means, spam the web with your message. With billions if not trillions of pages, make sure that you get your information out there in as many places as possible.
Blogging is my last idea, but it is not as effective. Just from a time perspective you have to keep putting into it and that makes it more expensive than just chucking out some posters. Posters are good because you can have a graphical message. Even back in the day...
Tamany Hall said they did not care what they wrote, their constituents could not read... They could UNDERSTAND pictures.
Thursday, October 15, 2009
How to Connect and Communicate With a Phidgets Interface Kit in C#
I have a bunch of there 8/8/8 kits. They are great. First, I would suggest getting their newest API package for your favorite platform.
I use visual studio, so I will have biased examples. I could regurgitate their examples, but mine hopefully don't suck.
From a simple command line application. You may get into some static thread issues, but they are generally avoidable.
This is pretty simple, and just opens the IK for management. You have to set up some events. In a constructor method, I dump the following code after you execute the Open() method.
I like these do loops for the initialization setups. Why, because it retries and does not fail just because. It says which instrument is having an issue before it proceeds. I use the phidgets_xxx methods to have a standard system for handling the major Phidgets methods .
It is pretty simple. I then just use events to manage the reading of the ports or inputs. It is really easy at this point. I put the whole session into a System.Timers.Timer loop or a Console.ReadLine system to control the starting and stopping of the application.
I use visual studio, so I will have biased examples. I could regurgitate their examples, but mine hopefully don't suck.
From a simple command line application. You may get into some static thread issues, but they are generally avoidable.
in your main()...
try
{
InterfaceKit ik1 = new InterfaceKit();
ik1.open();
}
catch (Exception _exc)
{
Console.WriteLine("interface kit error : " + _exc.Message + "\n",);
}
This is pretty simple, and just opens the IK for management. You have to set up some events. In a constructor method, I dump the following code after you execute the Open() method.
do
{
if (ik1.Attached)
{
Console.WriteLine("ik1 attached.");
//interface kit events
ik1.Attach += phidgets_Attach;
ik1.Detach += phidgets_Detach;
ik1.Error += phidgets_Error;
ik1.SensorChange += _ik1_SensorChange;
ik1.OutputChange += _ik1_OutputChange;
ik1.InputChange += _ik1_InputChange;
}
else
{
Console.WriteLine(("retry : " + retry + " waiting for ik1 attach");
}
retry++;
} while (retry < 10 && !ik1.Attached);
I like these do loops for the initialization setups. Why, because it retries and does not fail just because. It says which instrument is having an issue before it proceeds. I use the phidgets_xxx methods to have a standard system for handling the major Phidgets methods .
#region Phidgets event handlersThen some simple methods to catch changes per port. I connect different instruments to each port. I have to calibrate the readings for each port so that the readings make sense directly from the Read() methods.
///
/// handle the phidget device discovery events
///
/// /// protected void phidgets_Attach(object Sender, AttachEventArgs Args)
{
try
{
Console.WriteLine(Args.Device.Type + " attached.");
}
catch (Exception _exc)
{
throw new Exception(className +
" protected void phidgets_Attach( Sender, Args) :: " + _exc.Message +"\n");
}
} //phidgets_Attach
///
/// handle the phidget device discovery events
///
/// /// protected void phidgets_Detach(object Sender, DetachEventArgs Args)
{
try
{
Console.WriteLine(Args.Device.Type + " detached.");
}
catch (Exception _exc)
{
throw new Exception(className + " protected void phidgets_Detach( Sender, Args) :: " + _exc.Message +"\n");
}
} //phidgets_Detach
protected void phidgets_Error(object Sender, ErrorEventArgs Args)
{
try
{
Console.WriteLine("phidgets error : " + Args.Code + " " + Args.Description);
}
catch (Exception _exc)
{
throw new Exception(className +
" protected void phidgets_Error( Sender, Args) :: " + _exc.Message +"\n");
}
} //phidgets_Error
protected void _ik1_SensorChange(object Sender, SensorChangeEventArgs Args)
{
try
{
InstrumentType _type = InstrumentType.notset;
int _index = 0;
switch (Args.Index)
{
case 7:
_type = InstrumentType.notset;
_index = 4;
break;
case 6:
_type = InstrumentType.notset;
_index = 3;
break;
case 5:
_type = InstrumentType.notset;
_index = 2;
break;
case 4:
_type = InstrumentType.notset;
_index = 1;
break;
case 3:
_type = InstrumentType.notset;
_index = 0;
break;
case 2:
_type = InstrumentType.notset;
break;
case 1:
_type = InstrumentType.gyro;
gyro.SetRollData(
convertVoltageToUnit(InstrumentType.gyro, Args.Value, 1));
break;
case 0:
_type = InstrumentType.gyro;
gyro.SetPitchData(
convertVoltageToUnit(InstrumentType.gyro, Args.Value, 0));
break;
}
if (_type == InstrumentType.ultrasonicRangeFinder)
{
rangeFinders[_index] = convertVoltageToUnit(
InstrumentType.ultrasonicRangeFinder, Args.Value, _index);
}
Console.WriteLine(className +
" instrument change " + _type + " value: " + Args.Value);
}
catch (Exception _exc)
{
Console.WriteLine(className +
" protected void _ik1_SensorChange( Sender, Args) :: " + _exc.Message + "\n");
}
} //_ik0_SensorChange
protected void _ik1_InputChange(object Sender, InputChangeEventArgs Args)
{
try
{
}
catch (Exception _exc)
{
Console.WriteLine(className +
" protected void _ik1_InputChange( Sender, Args) :: " + _exc.Message + "\n");
}
} //_ik0_InputChange
protected void _ik1_OutputChange(object Sender, OutputChangeEventArgs Args)
{
try
{
}
catch (Exception _exc)
{
Console.WriteLine(className +
" protected void _ik1_OutputChange( Sender, Args) :: " +
_exc.Message + "\n");
}
} //_ik1_OutputChange
///
/// converts the read value, probably in volts to the correct units
/// this will also apply a 6:4 smooth, old value*0.6 + new value*0.4 to help
/// smooth out the readings
///
/// type of instrument read, to get the correct coeefficients/// reading of the instrument/// some instruments are indexed///the calibrated value
protected double convertVoltageToUnit(InstrumentType Type, double Reading, int Index)
{
double _value;
try
{
int _InstrumentTypeIndex = 0;
double _old = 0;
switch (Type)
{
case InstrumentType.accelerometer:
_InstrumentTypeIndex = 2;
_old = rawAcc[Index];
break;
case InstrumentType.gyro:
_InstrumentTypeIndex = 3;
_old = gyration[Index];
break;
case InstrumentType.pressureStatic:
_InstrumentTypeIndex = 0;
break;
case InstrumentType.temperature:
_InstrumentTypeIndex = 1;
break;
case InstrumentType.ultrasonicRangeFinder:
_InstrumentTypeIndex = 4;
_old = rangeFinders[Index];
break;
case InstrumentType.servo:
_InstrumentTypeIndex = 5;
_old = servos[Index];
break;
case InstrumentType.notset:
break;
}
double A = double.Parse(
AppSettings["instrumentCalibration" + _InstrumentTypeIndex + "A"]);
double B = double.Parse(
AppSettings["instrumentCalibration" + _InstrumentTypeIndex + "B"]);
double C = double.Parse(
AppSettings["instrumentCalibration" + _InstrumentTypeIndex + "C"]);
//apply basic filter to smooth the data
// value = Ax^2+Bx+C
if (_old != 0)
{
_value = 0.6*_old + 0.4*(A*Reading*Reading + B*Reading + C);
}
else
{
_value = A*Reading*Reading + B*Reading + C;
}
}
catch (Exception _exc)
{
throw new Exception(className +
" protected double convertVoltageToUnit( " + Type.ToString("0.000") +
" , " + Reading.ToString("0.000") + " ) :: " + _exc.Message + "\n");
}
return _value;
} //convertVoltageToUnit
It is pretty simple. I then just use events to manage the reading of the ports or inputs. It is really easy at this point. I put the whole session into a System.Timers.Timer loop or a Console.ReadLine system to control the starting and stopping of the application.
A Stability Manager is Good to Have, But You Could Wing It
More about the loathe and planning of your own autopilot. I used a hopefully simple system to handle the stability manager. I set up a system that uses a simple interface for strategies to get to keep the plane in the air. From this strategy interface, I developed several strategies that specialized in different aspects of managing the airplane's performance.
The strategies then calculate a solution and then pass it to the task manager. The servo manager pops the solution off the task manager's stack and gives. From the solution the servo manager converts the new inputs to a servo position map. It converts the map to servo motion and executes the changes. The Phidgets controllers that we use allow for several settings to be set as it moves the servos into position.
It may seem a bit "math nerd", but the cool thing about the Phidgets controller is that you can set the final position, the speed and the magnitude of the acceleration used to make the changes. In general, I leave it to figure out the acceleration. However, in coordinated systems it may be important to set the jerk of the servo arms so that you do not lock up linkages or other mechanical interfaces to the servos.
My strategies are simple. I tried to decorate a base object with virtualized methods, that way if I missed or the method's implementation did not just come to me the methods would have something by way of implementation. This seems to be a good way to handle this kind of "how the heck do I do this" programming. I am sure there are more professional ways of doing this, but here is how I did it.
public interface IStrategyResult
{
object ShowResult();
}
Now these are interfaces that I used to make a series of strategies to balance the different flight aspects and how to keep the system on course. These are run through at about 20Hz and the results are compared at 10Hz. That way decisions can be made at 5Hz and you can keep the whole thing from bumping into the data collection and servo motion phases. It happens, but if the frequency is high enough, we can miss a solution or two and still make it in time to decide which solution was best.
A simple markup model then decides which result is most successful and passes it down the chain. My biggest troubles are always how to correctly smooth the position and orientation data. They are effected by several different coupling and acceleration balances. I have heard about these Kalman filters that everyone loves so much, but have yet to be successful implementing one myself from scratch. I usually keep a simple integrator system to keep the changes small(er) and tend to stay in constant speed-level flight if at all possible. That is better for overall system performance anyway. You have to pay the piper for every energy change.
The strategies then calculate a solution and then pass it to the task manager. The servo manager pops the solution off the task manager's stack and gives. From the solution the servo manager converts the new inputs to a servo position map. It converts the map to servo motion and executes the changes. The Phidgets controllers that we use allow for several settings to be set as it moves the servos into position.
It may seem a bit "math nerd", but the cool thing about the Phidgets controller is that you can set the final position, the speed and the magnitude of the acceleration used to make the changes. In general, I leave it to figure out the acceleration. However, in coordinated systems it may be important to set the jerk of the servo arms so that you do not lock up linkages or other mechanical interfaces to the servos.
My strategies are simple. I tried to decorate a base object with virtualized methods, that way if I missed or the method's implementation did not just come to me the methods would have something by way of implementation. This seems to be a good way to handle this kind of "how the heck do I do this" programming. I am sure there are more professional ways of doing this, but here is how I did it.
///
/// used in the strategy design pattern, so that you can use different strategies and change
/// them by delegate
///
public interface IStrategy
{
///
/// execute the strategy but do not return any results
///
void Execute();
///
/// exectute the strategy, return the result
///
///result of the strategy
object Execute(bool bResults);
///
/// exectute the strategy, return the result and a object
///
/// return a second resultant object ///result of the strategy
object Execute(out object Result);
}
public interface IStrategyResult
{
object ShowResult();
}
Now these are interfaces that I used to make a series of strategies to balance the different flight aspects and how to keep the system on course. These are run through at about 20Hz and the results are compared at 10Hz. That way decisions can be made at 5Hz and you can keep the whole thing from bumping into the data collection and servo motion phases. It happens, but if the frequency is high enough, we can miss a solution or two and still make it in time to decide which solution was best.
A simple markup model then decides which result is most successful and passes it down the chain. My biggest troubles are always how to correctly smooth the position and orientation data. They are effected by several different coupling and acceleration balances. I have heard about these Kalman filters that everyone loves so much, but have yet to be successful implementing one myself from scratch. I usually keep a simple integrator system to keep the changes small(er) and tend to stay in constant speed-level flight if at all possible. That is better for overall system performance anyway. You have to pay the piper for every energy change.
Tuesday, October 13, 2009
Business Opportunities in Central Europe or Brazil
Buzz Labs is looking for business contacts in Central Europe or Brazil. We are seeking interesting applications of UAS and UGV in most places or partners to help develop certain aspects of technologies for related projects. Our business is about developing technologies to support unmanned systems in general or how to achieve certain commercial or scientific requirements.
Maximizing our understanding of networking and aviation knowledge is allowing for fascinating new insights into what is possible even with the current states of technologies. We are most interested in multi-spectral image analysis, distributed pico-computing, alternatives to radio control, streaming technologies,power systems and system configuration.
Central Europe and Brazil are great stable markets that we would like to become a bigger player in. Please feel free to contact us with questions or ideas.
info@fatmanflying.com
Maximizing our understanding of networking and aviation knowledge is allowing for fascinating new insights into what is possible even with the current states of technologies. We are most interested in multi-spectral image analysis, distributed pico-computing, alternatives to radio control, streaming technologies,power systems and system configuration.
Central Europe and Brazil are great stable markets that we would like to become a bigger player in. Please feel free to contact us with questions or ideas.
info@fatmanflying.com
Saturday, October 10, 2009
Wing Loading, Bah! Land It Like A Man! Full-Throttle and Nose Up!
Recently, we have heard lots of talk about our normally well loaded wings. The balsa versions of our planes work great, and have normal stall speeds around 15-20mph. That is great for normal flying. They are hybrid flying wings and should fly like a Dutch Roll resistant frisbee.
I have been building the carbon fiber and Aluminum versions. They are a bit heavier than we expected, but that is due to real materials. We certainly will take out some of the fat in future revisions, but I think that the issue here is approach speed. You bunch of sissy girls. These planes are UAS, unmanned means the computer should be doing the work to bring the plane in on glide path. I hope our spars are strong enough for the cut the power approach.
What the heck am I talking about? Nope, never been asked that in polite company either. Wing loading is a relative measure that comes out of the basic low-speed aerodynamics of any fixed-aircraft. In some ways, it is a measure of the relative performance of a device with respect to constant thrust. It is most easily expressed as the mass of the aircraft divided by the wing area.
This essentially describes how strong the pressure difference must be between the surfaces to keep the plane in the air. Considering that the higher the wing loading, the larger the drag due to lift turn will be. This will change the trim characteristics of the plane in cruise and require more thrust to keep the plane above stall. Any F-4 or F-15 driver will tell you that more thrust is the answer to everything.
The wing loading also changes the stall speed. If you have to use forward speed to generate enough lift for a given flight regime, you have to go faster to balance the weight of the aircraft with the lift generated. In a flying wing, you cannot just pick the nose up, roll control has to be gentle. The old adage "Little planes add flap, big planes add power" is our friend. If you were interested the effect of wing loading on stall speed is expressed as the following.
Aircraft Wing Loading (kg/sq m)
swan 10
Buzz Labs Schoolgirl UAV 23
Nieuport 17 38
Cessna 152 51
B-17 190
F-104 514
A380 who cares, it is an airbus
B747 740
We already know you can do your approach at a reasonable speed, but why? Sensible approaches are for people who do not think that 10 ft/s sink rates are for roller coasters. Land It Like a Man, Full Throttle and Both Hands on the Stick. Or, just let the autopilot do it, it can tell how far it is from the ground and cut the power at stall two inches off the ground.
If the women don't find you handsome, they ought to find you handy!
I have been building the carbon fiber and Aluminum versions. They are a bit heavier than we expected, but that is due to real materials. We certainly will take out some of the fat in future revisions, but I think that the issue here is approach speed. You bunch of sissy girls. These planes are UAS, unmanned means the computer should be doing the work to bring the plane in on glide path. I hope our spars are strong enough for the cut the power approach.
What the heck am I talking about? Nope, never been asked that in polite company either. Wing loading is a relative measure that comes out of the basic low-speed aerodynamics of any fixed-aircraft. In some ways, it is a measure of the relative performance of a device with respect to constant thrust. It is most easily expressed as the mass of the aircraft divided by the wing area.
This essentially describes how strong the pressure difference must be between the surfaces to keep the plane in the air. Considering that the higher the wing loading, the larger the drag due to lift turn will be. This will change the trim characteristics of the plane in cruise and require more thrust to keep the plane above stall. Any F-4 or F-15 driver will tell you that more thrust is the answer to everything.
"The critical limit for bird flight is about 5 lb/ft² (25 kg/m²)[3]. An analysis of bird flight which looked at 138 species ranging in mass from 1x10-2 to 10 kg, from small passerines to swans and cranes found wing loadings from about 1 to 20 kg/m2[4]. The wing loadings of some of the lightest aircraft fall comfortably within this range. One typical hang-glider (see table) has a maximum wing loading of 6.3 kg/m2, and an ultralight rigid glider[5] 8.3 kg/m2." - wikipedia
The wing loading also changes the stall speed. If you have to use forward speed to generate enough lift for a given flight regime, you have to go faster to balance the weight of the aircraft with the lift generated. In a flying wing, you cannot just pick the nose up, roll control has to be gentle. The old adage "Little planes add flap, big planes add power" is our friend. If you were interested the effect of wing loading on stall speed is expressed as the following.
v^2 is the stall speed
g is the acceleration due to gravity
Ws is the wing loading, mass/wing area
rho is the density of air
CL is the coefficient of lift of the net wing
Another interesting equation, is the rate of climb. This is just a force balance between the net acceleration, lift generated and the weight of the device.
ac is the climbing acceleration
Ws is still the mass wing loading
vc is the new airspeed
rho is the density of the free stream air
CL is the coefficient of lift of the net wing
g is the acceleration due to gravity
The wing loading term is in the denominator, so if you want to climb faster you need to lower the wing loading, or increase speed. Increasing the speed is way more fun than having gossamer wings. More Power!
We are not so bad, we are in the 23-35 kg/m^2 range for our wing loading depending on the equipment load out. Less than a some gliders. We however, cannot skimp on pimping the power plant. As if we would do that.
Aircraft Wing Loading (kg/sq m)
swan 10
Buzz Labs Schoolgirl UAV 23
Nieuport 17 38
Cessna 152 51
B-17 190
F-104 514
A380 who cares, it is an airbus
B747 740
We already know you can do your approach at a reasonable speed, but why? Sensible approaches are for people who do not think that 10 ft/s sink rates are for roller coasters. Land It Like a Man, Full Throttle and Both Hands on the Stick. Or, just let the autopilot do it, it can tell how far it is from the ground and cut the power at stall two inches off the ground.
If the women don't find you handsome, they ought to find you handy!
Motors, motors, motors
Did anyone else ever notice that anything truly important must be said thrice for men to notice? Girls, girls girls, XXX, I have a million examples. Just an aside, but interesting to note. That may be why no one ever reads DANGER, and stays away, Or don't click.
This week I have been fighting the forces of evil all week. I know the buzzlabs.us site is not a work of art. It is a work in progress. Yeah, yeah need more pictures. Let's get one step at a time. I found several distributors of NEU motors whose website said, yeah they are in stock. Seems that they need to update their site? WTF still are not online with inventory status... or are not advertising things correctly. If you don't have it, just say so.
Anyway, there I was thinking I had the NEU motors in hand 1912/3Y jobs. however, it seems that there is no such thing as in stock with these guys. They are supposed to be the best. I have been reading that the heli guys dig the X-Era motors from NC too.
I called Dave at X-Era. He was friendly and very helpful. I will keep up with his 4035 3y 400kv motors. He is actually sizing a motor for us to swing these huge props. I am actually pretty curious what he will come up with. The NEU calculator came up with the 1912 line of motors because of the three bladed props. I will post what he says when I get back his response.
If anyone knows of any 5-6 bladed props that would be good to know too. I heard on the boards that Dario makes them. It is my opinion that I can slow the prop down enough by adding blades to lower our planes and reduce the current draw by adding voltage. I would love to get our current draw to 20A at 9s (33.3V) our batteries would last for a lot longer. I think maybe Bolly Props down in Oz may have them, but three bladed jobs though.
This week I have been fighting the forces of evil all week. I know the buzzlabs.us site is not a work of art. It is a work in progress. Yeah, yeah need more pictures. Let's get one step at a time. I found several distributors of NEU motors whose website said, yeah they are in stock. Seems that they need to update their site? WTF still are not online with inventory status... or are not advertising things correctly. If you don't have it, just say so.
Anyway, there I was thinking I had the NEU motors in hand 1912/3Y jobs. however, it seems that there is no such thing as in stock with these guys. They are supposed to be the best. I have been reading that the heli guys dig the X-Era motors from NC too.
I called Dave at X-Era. He was friendly and very helpful. I will keep up with his 4035 3y 400kv motors. He is actually sizing a motor for us to swing these huge props. I am actually pretty curious what he will come up with. The NEU calculator came up with the 1912 line of motors because of the three bladed props. I will post what he says when I get back his response.
If anyone knows of any 5-6 bladed props that would be good to know too. I heard on the boards that Dario makes them. It is my opinion that I can slow the prop down enough by adding blades to lower our planes and reduce the current draw by adding voltage. I would love to get our current draw to 20A at 9s (33.3V) our batteries would last for a lot longer. I think maybe Bolly Props down in Oz may have them, but three bladed jobs though.
Saturday, October 3, 2009
Of Directors and Other School Marms
At start up, the director sets all of its properties from the configuration files and starts the managers. The managers in my model are:
- instrumentation manager, im
- task manager, tm
- ai manager, aim
- stability manager, stab man
- communication manager, comm
- display manager, display
This can be relatively complicated since the observation system must be handled by the director. The data flows from the instrumentation manager to the stability manager (stab man observes im). Task managers observe the communication manager to queue jobs, they also watch the stability manager. The Instrumentation Manager also watches the task manager, but only because it also contains the servo manager. Tasks go from the stability manager to the task stack and are then sent to the servo manager.
I thought this was the best way because whether or not the communications manager has a command, the task queue will be populated. The servo manager will then grab tasks and handle them in a first come first served pattern. If a command expires by sitting in the queue too long it is dumped by the task manager when the servo manager pops it off of the queue. As the system becomes more complicated, there could be more queues to do more things. However, tasks that require moving a servo always go to the servo queue.
I have read the great MAV blog by Tom Pycke. He has lots of things to say on the topic of real time operations. However, my idea is that they are not really so important. I do agree with him that his way of dealing with garbled or miscommunicated commands to the MAV is pretty interesting. My way seems to be not so bad either. The system must be able to fly itself, you tell it a basic plan to fly along. Any command inputs from the ground station are "exceptions".
Exceptions are easier to manage because you do them as soon as possible. When they expire you stop doing them, the system still tries to make the best of the situation and go back to the plan. This guidance could make a complete mess that breaks everything, in the case of coordinates that are for a different city. Your system may start flying off in a crazy direction trying to get home. However, that is why there are a few directives that the director knows and is the only one that can execute.
I keep a few tasks in the clip for a special occasion. My "director-only" tasks are:
- shutdown
- go to safe altitude
- land immediately
- idle
The ai (artificial intelligence) manager is the basis for the flight state. It reads the preset," at least we have somewhere to go" map and determines which mission phase the system should be in. Mission state is important information because it will time the use of instrumentation or cameras, as well as when to hit the "panic" button. The stability manager uses this to set system configurations and movement regimes for the system.
A director class is a operator, directing the data from one manager to the other. The AI manager is where the state manager exists. More on the AIM later, check in tomorrow if I am feeling feisty and have not cut myself up or glued something good to the table.
Friday, October 2, 2009
Get Your Buzz Gear
Hey everyone,
I just got the Buzz Gear store set up. Please help the cause, get some great Buzz stuff. I make pennies on it, but advertising is awesome.
Let me know if you would like to see something else, I tried to have a selection of stuff.
Thanks,
Adam
I just got the Buzz Gear store set up. Please help the cause, get some great Buzz stuff. I make pennies on it, but advertising is awesome.
Let me know if you would like to see something else, I tried to have a selection of stuff.
Thanks,
Adam
Sunday, September 27, 2009
I almost forgot
Prototype two's wing is now almost complete. It will be mated to the fuselage hopefully tonight. I must have really bollocksed up using the pattern that I made on the first plane. It is a different diameter than the first. The second prototype has a more tear drop shaped fuselage that the first aircraft. I think it will make it easier to shore up the system with stringers than the purely round shape.
Before we get to actual code...
One thing that I did, was to develop an object that was a sensor, ISensor. This will be the part that actually interact with any device. ISensorReading will also act as a fundamental contract for data. I would make sure that this object follows in general an observable pattern. That way it is easy to allow other objects to read its data, or to be notified when new data is available. This will make it easy for filtering algorithms to execute and work on the newest data as soon as it arrives. It will also make it easier to make the data collection to be asynchronously collected and processed.
Then I made an instrumentation manager, IM. The IM will have factories for each kind of sensor and observe instances of each of the instruments. This way if something happens the IM can close an instrument and try to reconnect with a new object. In turn, the IM presents data to other parts of the code as needed. No other parts of the code need to see the sensors or interact with them directly.
On top of the instrumentation system, should be a director layer. This will actually be the layer that does all of the work. It makes a nice break line between the device and the presentation, or intelligence. Separating the systems is an important object-oriented technique that is necessary for keeping the code healthy.
More about the director later... I will see if I can get some pictures in to make it easier to see.
Saturday, September 26, 2009
What I am Thinking At the Moment
At the moment, I am trying to decide what is the most interesting way to proceed with this blog. It is important to discuss some of the howto aspects of UAVs and autopilots. I think that it is also important to speak about some of the interesting applications and business difficulties of it as well.
At the moment, there are many stories in the news about blowing up bad guys with thunder bolts from the sky. However, I think that this is not the most interesting thing to be done with the technologies. We are investigating a number of small-scale recycled materials and techniques to apply energy reclamation systems so that the uavs harvest as much of their energy from the environment and recycle as much as they can.
For the record, the soybean epoxies available are just not as good as their petro-chemical equivalents. We are still trying to use them in our skin layups. If we can make use of them, they do come from a renewable resource stream. These adhesives are not recyclable though.
Another big idea, that Buzz Labs is working on is the heat pipe system to pull heat away from the motors and batteries and either use that to generate trickle charges or to be able to cool the batteries to a point that we can keep their chemistries from over heating down to the limit of their endurance. Lithium-polymer (LiPo) batteries do have some physical limitations that make exciting failures possible. Read about the exploding notebook batteries. Buzz's engineers are seeing some success with maintaining battery temperatures even above their rated currents. Battery performance increases are especially good news for the racers and autonomous vehicle systems
We will keep you posted here as we make significant breakthroughs or cool flaming rc parts.
At the moment, there are many stories in the news about blowing up bad guys with thunder bolts from the sky. However, I think that this is not the most interesting thing to be done with the technologies. We are investigating a number of small-scale recycled materials and techniques to apply energy reclamation systems so that the uavs harvest as much of their energy from the environment and recycle as much as they can.
For the record, the soybean epoxies available are just not as good as their petro-chemical equivalents. We are still trying to use them in our skin layups. If we can make use of them, they do come from a renewable resource stream. These adhesives are not recyclable though.
Another big idea, that Buzz Labs is working on is the heat pipe system to pull heat away from the motors and batteries and either use that to generate trickle charges or to be able to cool the batteries to a point that we can keep their chemistries from over heating down to the limit of their endurance. Lithium-polymer (LiPo) batteries do have some physical limitations that make exciting failures possible. Read about the exploding notebook batteries. Buzz's engineers are seeing some success with maintaining battery temperatures even above their rated currents. Battery performance increases are especially good news for the racers and autonomous vehicle systems
We will keep you posted here as we make significant breakthroughs or cool flaming rc parts.
Gyroscopes Are Fun!
Piezo-electric gyroscopes are fun. However, I certainly had to learn a lot of things to get a usable signal from them. Remember that gyros report a rate of change not just an absolute value. This rate presents an interesting issue, that we have to integrate the signal at each step. You may want to use a more advanced curve fitting integration scheme than the one that I will present here.
Integration for those not in the know is just finding the area under a curve. The catch is that, you will never be given a curve by the gyroscope. Not having a curve means that we must discretize the signal, from these step-wise readings we can write a formula that will help us back out what the absolute angle is in that direction. However, since we are integrating these formulae will not take into account small changes that happen to the signal between samples.
The simplest form of integration is, just calculating a rectangle. Your software will have to remember the last reading from the gyroscope and the last calculated position.
Integration for those not in the know is just finding the area under a curve. The catch is that, you will never be given a curve by the gyroscope. Not having a curve means that we must discretize the signal, from these step-wise readings we can write a formula that will help us back out what the absolute angle is in that direction. However, since we are integrating these formulae will not take into account small changes that happen to the signal between samples.
The simplest form of integration is, just calculating a rectangle. Your software will have to remember the last reading from the gyroscope and the last calculated position.
angle change =dAngle* step length
so the basic formula would be,
Angle i = Angle i-1+ angle change
A better technique would be simply approximating the changes in the curve as linear segments and then calculating the differences as triangles or trapezoids.
This is a relatively bad way to do this, but is easy to understand. I would suggest using a multi-order approach to try and take into account some of the variations in these signals. The nuts and bolts of it is, is that the equation only works if the change in angle is relatively small compared to the current angle. If you are executing maneuvers and sampling relatively slowly this formula will lead your software astray. I would use a gyroscope sampling rate that is at half of the gyroscope's sample acquisition rate. Halving the sampling rate should keep the software getting into too much trouble from landing between readings and getting garbage.
Remember to read your manufacturer's guidance on this. It will tell you how quickly it can measure changes. We use several of these:
They are 500 deg/s sampling rate at 2mV/deg. That is usually too small for our analog to digital coverter boards (A/D boards), so we lower that to 150 deg/s and get a better signal rate of 9mV/deg. This means that we can get a nice clean signal that is several bits wide from our A/D board. Remember that your I/O system will determine a lot of things about your code.
If you sample to fast, you can have lock issues, too slow and you do not get a representative sample. I would suggest that you shoot around 200Hz for samples, and then apply your filtering to bring it down to a rate to allow your other software to make decision on the filtered values as if they were the just read values.
There are better boards available, but the ones from Phidgets.com have a great API for almost any platform. Their 8/8/8 boards are great all-around boards, but do not have the highest sampling precision. For most things, it is plenty.
I really like the .NET support and the usb interface. Even I could figure it out from their examples in only a few minutes. Next time, I will show you how easy it is to connect to the A/D board and begin acquiring signals. The code samples from Phidgets are effective and describe most of the general functions that you will need to implement a system with their instruments.
Sunday, September 20, 2009
Basic Quantities and Some Trigonometry
So You Want to Build a DIY Autopilot
Accelerations
One of the most important quantities for you to measure are accelerations. If your two or more-axis accelerometer is mounted along the traditional axes of the aircraft it will be the easiest to code for. The three traditional axes are:
So, now for some basic Trigonometry, everyone remembers SOH CAH TOA.
In general, the following picture is true for a vehicle moving through space.
Accelerations
One of the most important quantities for you to measure are accelerations. If your two or more-axis accelerometer is mounted along the traditional axes of the aircraft it will be the easiest to code for. The three traditional axes are:
- From the nose through the center of gravity on the line of symmetry, the Y-axis, roll
- From the center of gravity out of the fuselage toward the tip of the right wing, the X-axis, pitch
- From the center of gravity away from the earth, the Z-axis, yaw
Figure of Rigid Aircraft Axes
So, now for some basic Trigonometry, everyone remembers SOH CAH TOA.
In general, the following picture is true for a vehicle moving through space.
Figure of the Direction of the Force of Gravitation on a Body
As you can see from the image, the angle of pitch relative to the surface of the earth is the same angle offset of the weight vector relative to the z-axis in the body frame of reference. If we put our accelerometer so that one of its axes is parallel to the body's z-axis at its center of gravity we are measuring this offset vector. Which is really neat, because it means that we can express the angle of the body in level, non-accelerating motion as ratios of the accelerations
Pitch:
The angle theta between the actual gravity vector and the measured gravity is related to the pitch of the aircraft (pitch = theta + 90°). If we know theta, we know our pitch! Since we know the magnitude of the earth’s gravity, simple calculus gives us our pitch angle:
Woot, we calculated the pitch orientation of our airplane using an accelerometer. Pretty easy, huh?
The real formula that we need to use for the software looks like this:
accelerometer = cos (theta) * gravity
theta = acos (accelerometer / gravity)
And since pitch = theta + 90°pitch = asin (accelerometer / gravity)
The real formula that we need to use for the software looks like this:
pitch = atan2(accelerometer / gravity, z / gravity)
Common piezo-electric accelerometers return in units of, g, 32.17 ft/s^2 or 9.81 m/s^2. We also know some more things about the flight that let us calculate the angles relative to the ground. More on this later, it is a bit more than basic trigonometry to describe. These equations assume non-accelerating flight. You can use a magnetometer to get the relative plane in space with less math, but magnetometers generally take more interface programming in my experience.
Roll:
Roll needs a second accelerometer with an axis perpendicular to the first so that we can figure out the resultant vector between them and then the angle. Essentially the vector between the accelerometers becomes the "gravitational" acceleration and the relative readings lets us calculate the angle with an atan2 function. The second accelerometer will have some other things to manage such as the effects of the distance between them on the accelerations measured. Physics fun and none of the boring class.
Yaw:
Yaw is the hardest of the angles to measure. The only answer is to use a magnetometer or a compass. In many ways, yaw can be solved by dead reckoning. Dead reckoning is all that is important for most of the projects in the DIY garage. They will be covered later.
Next we will discuss gyroscopes and the beauty of rates and integral calculus
Friday, September 18, 2009
How I started writing a DIY Autopilot
My intention still is to write my own c# based autopilot. It is not trivial as I found out. Lots and lots of details are needed. The first thing that needs to be done is to determine the instruments that you will need to measure the quantities that you need to know to control flight. Even this seems to be a matter of opinion. For a reference, I found every group that I could that was writing their own version.
From my perspective the quantities that we need to know to control flight are:
These are intrinsic quantities that are really easy to do yourself. Air speed is the model's forward velocity. Altitude is the vehicle's position relative to the surface of the earth. Pitch and roll are the angles of the vehicle relative to the ground. Let me rephrase that, roll is the angle between the right wing and a plane parallel to the ground. Pitch is also known as angle of attack. Pitch is the angle between the plane at the center of the vehicle located on vectors from the center of gravity to the right wing tip and the center of gravity to the tip of the nose and the relative wind.
At the beginning you will need to measure the following quantities:
Pressure taps are the easiest ways to measure air pressure in a flying vehicle. Piezo-electric accelerometers are cheap these days and are really accurate. In the next post we will talk about issues with these instruments and the physical quantities that you are actually measuring and how to use those as a basis for a control system.
For all of those inch haters, a quick note about units. You can do this in any unit system. It is unimportant. I will write a quick post on the conversions between the US Customary System and the metric (mks) system. Remember metric is actually several unit systems in one and you have to keep them consistent. Oh, and for those trying to buy nuts and bolts, Japanese manufacturers use odd metric sizes, European use even metric sizes, and the US Customary System/SAE is in units of 1/64th of an inch. So SAE/SAME will have three bolt sizes for every bolt size in the two metric systems. Remember that the thread counts are different though.
In my opinion, if the units are managed consistently then the issue is one of presentation to the user. Part of the display system of my code will show you how to do this with a simple object oriented approach.
From my perspective the quantities that we need to know to control flight are:
- air speed, ft/s or m/s
- altitude, ft or m
- orientation, roll, but pitch is good
These are intrinsic quantities that are really easy to do yourself. Air speed is the model's forward velocity. Altitude is the vehicle's position relative to the surface of the earth. Pitch and roll are the angles of the vehicle relative to the ground. Let me rephrase that, roll is the angle between the right wing and a plane parallel to the ground. Pitch is also known as angle of attack. Pitch is the angle between the plane at the center of the vehicle located on vectors from the center of gravity to the right wing tip and the center of gravity to the tip of the nose and the relative wind.
At the beginning you will need to measure the following quantities:
- air pressure
- acceleration in at least two directions
Pressure taps are the easiest ways to measure air pressure in a flying vehicle. Piezo-electric accelerometers are cheap these days and are really accurate. In the next post we will talk about issues with these instruments and the physical quantities that you are actually measuring and how to use those as a basis for a control system.
For all of those inch haters, a quick note about units. You can do this in any unit system. It is unimportant. I will write a quick post on the conversions between the US Customary System and the metric (mks) system. Remember metric is actually several unit systems in one and you have to keep them consistent. Oh, and for those trying to buy nuts and bolts, Japanese manufacturers use odd metric sizes, European use even metric sizes, and the US Customary System/SAE is in units of 1/64th of an inch. So SAE/SAME will have three bolt sizes for every bolt size in the two metric systems. Remember that the thread counts are different though.
In my opinion, if the units are managed consistently then the issue is one of presentation to the user. Part of the display system of my code will show you how to do this with a simple object oriented approach.
Wednesday, September 16, 2009
What do you think of this one?
Ok, I have been looking around, since pretty much no one is voting, I made another one. I have to get back to working on the landing gear for the two prototypes. However, let me know what you think. I have a hopefully interesting article coming up about installing some of the components and an idea of how to do repeatable assembly that on small scales.
woohoo we got the first search engine bounces on the blog.
woohoo we got the first search engine bounces on the blog.
Another updated historical badge, I like it. The turtle badge came out badly, so I will keep it to myself.
Monday, September 14, 2009
Second Prototype is Almost Ready
That is a bit of a lie. Maybe it is just marketing, can't sell something that does not exist. Well you can, but I am not as big as a fruit-shaped software company. So I am trying to upload some of the better pics to the blog. The wing frame came out really well, maybe even symmetric, but we all know that will never happen.
The first one is not doing poorly, we are waiting on some plexiglass hoops from the sign cutters to shore up the doors and part of the fuselage. As soon as I get those, we should be pretty close to getting the engines installed. I have to finish doing the soldering, but my little iron from radio shack takes a while to heat up the fat connections for the motors. Should try to do it again.
At the moment, it is all looking good. Just need to get the last bits finished so that I can get some more pics together for the main site. Please don't forget to visit the main website, http://www.buzzlabs.us. A lot more information about everything there.
The first one is not doing poorly, we are waiting on some plexiglass hoops from the sign cutters to shore up the doors and part of the fuselage. As soon as I get those, we should be pretty close to getting the engines installed. I have to finish doing the soldering, but my little iron from radio shack takes a while to heat up the fat connections for the motors. Should try to do it again.
At the moment, it is all looking good. Just need to get the last bits finished so that I can get some more pics together for the main site. Please don't forget to visit the main website, http://www.buzzlabs.us. A lot more information about everything there.
Saturday, September 12, 2009
Squadron Badge Ideas
Every squadron needs a symbol. Some research into the oldest American squadrons lead me through some interesting history. More filler for my head, I must admit. From two of these, I drew up some low color variants. Let me know which looks best out of each group.
US UAV Squadron
Let me know which you guys like best. email
US UAV Squadron
.jpg) Jolly Roger | .jpg) Jolly Roger with Triangles | +(2).jpg) Jolly Roger Round |
EU UAV Squadron | ||
.jpg) Felix Beer |
.png) Felix Camera | .jpg) Felix Bomb |
Let me know which you guys like best. email
Tiny 2.11
I need another u.fl connector-based antenna for the ground station XBee Pro modem. I found some at Sparkfun. Per advice, the best plan is to go for the cable and duck route. All of the electronics will be boxed to make them easier to shield from the high current wiring from the batteries to the ESC to the motors.
My current plan is to use:
SMA duck antenna
u.fl to SMA cable
My current plan is to use:
SMA duck antenna
u.fl to SMA cable
Subscribe to:
Posts (Atom)