My son (Paul A) spent the better part of the last two weeks helping some friends finish the plumbing and fixtures for a static firing. I went out Sunday to wire up some sensors and record data for the event. beyond that I can't talk about it much. All of the stuff Paul A and I were responsible for worked correctly. All the plumbing worked and I logged good data. Both Murphy and Marvin were present at the test. Marvin who??? Marvin the Martian of course, his favorite line "And right about now there should have been an earth shattering Kaboom!" It was nice to see everyone from FAR and work on a project with them. It was also nice as a father, to see skilled, competent, successful adults, impressed by my sons skills and work ethic. Being a father has been a hard job, but its nice to see that my son is starting to learn a lesson that took me at least 10 years longer to learn. Happiness and satisfaction can not be purchased. All too often we think I'll be happy as soon as I buy a new motorcycle,car, house,wardrobe etc... I'll be happy as soon as I'm promoted to manger, VP etc.... I strongly believe that happiness is earned by creating or doing something that has value. The sense of satisfaction earned by accomplishing something hard can not be oversold. I also think that the creation of tangible things with your own hands is of great personal value. You can not purchase this feeling.
While I was out at FAR waiting for other parts of the project to come together I flew the helicopter, the GPS finally works correctly in flight! Alas the Compass does not because the GPS antenna has magnets in the bottom and sits above the compass sensor. Arghhhh!
Tuesday, December 18, 2007
Saturday, December 08, 2007
Christmas Copter/Fun
One of my issues with working on the helicopter has been getting time to actually test. I can only really work weekends and evenings. If the weather is bad on the weekend, that means no testing for the whole week. I just discovered that people fly RC helicopters at night. (the previous link is not me)
I bought a pair of lit blades and some glow wire to give it a try. I'm not the worlds best RC pilot, I can hover nose in, nose out and fly around a little, but not a whole lot more. So I was worried about flying the big trex with 3K worth of electronics on it and crashing it. So I went to the hobby store today and bought some night blades for my little Trex. $45.00 worth of blades seems like a good price to see if I can fly at night. I wired up the glow wire and went out and tried flying it. I flew off three full battery packs in drive way at night, the test was both a success and a bit of fun. So now I have the confidence to be comfortable flying the big trex in an open field at night!
My wifes comment "oh thats pretty it matches our Christmas lights, a Christmas copter!"
I bought a pair of lit blades and some glow wire to give it a try. I'm not the worlds best RC pilot, I can hover nose in, nose out and fly around a little, but not a whole lot more. So I was worried about flying the big trex with 3K worth of electronics on it and crashing it. So I went to the hobby store today and bought some night blades for my little Trex. $45.00 worth of blades seems like a good price to see if I can fly at night. I wired up the glow wire and went out and tried flying it. I flew off three full battery packs in drive way at night, the test was both a success and a bit of fun. So now I have the confidence to be comfortable flying the big trex in an open field at night!
My wifes comment "oh thats pretty it matches our Christmas lights, a Christmas copter!"
A glimpse at the software details....
I want to try and give a glimpse of the details involved with some thing as simple as a swapping the GPS. Ive been working with a GARMIN GPS-18 5Hz gps, it has a serial interface that spits out NMEA sentences. NMEA is a standard protocol. If all you want out of the GPS is position then the GPS units are almost interchangeable. They almost all support the NMEA sentence...GPGGA.
The simple way to process the NEMA sentence is to load the whole thing into a character buffer and parse it. The Netburner library has a nicely written serial driver that makes talking to the serial port pretty painless. Open the port and read characters from it. The serial driver is intrrupt driven, so if you get busy and don't read characters, nothing is lost. To fit this reading and parsing into the main control loop is as simple as adding code to check to see if GPS chars are available and then jumping to a routine to read and process the chars.
You duplicate this three times, GPS, IMU and Telemetry commands.
I thought I'd try to unclutter the main task loop and be a little more efficient. I'm the original author of the Netburner serial driver, so modifying things at the driver level was not too scary. I modified the serial driver to parse the GPGGA sentance one charactor at a time in a state machine and then post to a semaphore to tell the main task that new GPS data is ready. This is a nice routine because it spreads the GPS parsing out in time and has the minimum possible delay.When the sentence checksum is validated the data is ready, all of the floating point data fields have already been parsed out. So the main task only gets notified when data is actually ready. After the GPGGA I expanded the system to capture the proprietary garmin PGRMV sentence that gives me north, east and vertical velocity. Again its all clean and works well. The state machine now knows how to parse two sentences and ignore the others.
This data is processed by the main data processing task. In addition to using it internally it also sends telemetry frames off on the maxstream radio to be displayed and recorded on the ground.
The display program receives a data structure and logs, plots and displays things based on the received data frame type. (The processing for the IMU data is almost identical)
Now I want to upgrade the GPS to the Crescent Vector. The obvious software differences are:
Humm I really want to know vertical velocity... digging in the crescent vector manual I discover that they have a binary message that has vertical velocity, in fact the single binary message has ALL the GPS data I have been capturing in a single message. The Crescent also has heading capability, alas it only outputs heading in a NMEA sentance, not a binary one. so my parsing state machine needs to process a mixed stream of Binary and NMEA messages.
The Binary message is nice in that it starts with $BIN so the beginning looks like a NMEA message, and the simple approach would be to just branch on this NMEA message ,
Its not that simple. My state machine resets its state to 0 whenever it sees a '$' beginning of message,but with the GPS sending binary data there is no guarentee that the binary data won't contain a '$' this breaks my state machine, so now the state machine knows if it is parsing a NMEA or binary data set and reacts accordingly. Also note that in a serial stream of chactors 1234.5678 there is no ambiguity on how to interpit the data. In a binary stream its a little bit more complicated. The GPS sends binary data as a IEEE754 double. standard format, but the GPS sends data in littel endian or intel format and the Coldfire processor I'm using uses big endian or Motorola format.(See Endian). SO I have to convert formats before I use the data. This is still a big win, because the endian conversion is much more efficient than parsing ASCII. Note that I'm already doing the endian conversion on the PC display software so this was not unexpected.
Once I'm parsing the GPS message the system stops responding reliably to telemetry commands....argghhhh! The problem is that If I keep the telemetry link busy sending data from the helicopter to the ground there is no time for the ground station to send data back. Up to this point the telemetry data stream was not too big for the down link pipe, switching from 5 to 10hz GPS pushes me over the edge. So now I write and debug a telemetry throttling routine that tries to keep the telemetry link idle for 50% of the time by throwing away data based on its age and priority.
All seems to be working except none of my telemetry frames have a spot for the GPS heading information, I'd like to keep both the GPS and IMU heading data, so I add a new GPS heading frame type to both the helicopter and the display software. Both areas are pretty modular so this is an easy fix. I label the new data with the same data type tag as the IMU heading data.... .
without remembering that the IMU heading is not floating point but a 0->65536 binary heading.(I worte the IMU parser and display code framework for my air lander over a year a go and have not really modifed it) Hence the GPS heading display is all messed up on the PC so I spend some time debugging the helicopter code to try and figure out why my parser is not properly parsing the GPS heading, only to eventually discover its a problem on the PC side.
This is now almost complete. At some future date I will add HOP and VDOP and signal to noise reporting. I'm now ready to take the whole helicopter outside and see how it works as an assembly. (I've been testing with two external GPS antennas on the roof. The GPS informs me that the antennas are 49.6 cm apart and that my roof has a heading of 172.3 degrees)
I really enjoy reading technical blog posts that give you a sense of the problems and struggles involved with building hardware. In an Ideal world I'd like to cover all of the project in this much detail. The reality of time and the need to sleep conspire against this. I've never been a skilled word smith so writing this saga took 25% as much time as struggling through the code. I don't have the patience to document everything to this level, but I'm going to try and do more posts at this level of detail.
The simple way to process the NEMA sentence is to load the whole thing into a character buffer and parse it. The Netburner library has a nicely written serial driver that makes talking to the serial port pretty painless. Open the port and read characters from it. The serial driver is intrrupt driven, so if you get busy and don't read characters, nothing is lost. To fit this reading and parsing into the main control loop is as simple as adding code to check to see if GPS chars are available and then jumping to a routine to read and process the chars.
You duplicate this three times, GPS, IMU and Telemetry commands.
I thought I'd try to unclutter the main task loop and be a little more efficient. I'm the original author of the Netburner serial driver, so modifying things at the driver level was not too scary. I modified the serial driver to parse the GPGGA sentance one charactor at a time in a state machine and then post to a semaphore to tell the main task that new GPS data is ready. This is a nice routine because it spreads the GPS parsing out in time and has the minimum possible delay.When the sentence checksum is validated the data is ready, all of the floating point data fields have already been parsed out. So the main task only gets notified when data is actually ready. After the GPGGA I expanded the system to capture the proprietary garmin PGRMV sentence that gives me north, east and vertical velocity. Again its all clean and works well. The state machine now knows how to parse two sentences and ignore the others.
This data is processed by the main data processing task. In addition to using it internally it also sends telemetry frames off on the maxstream radio to be displayed and recorded on the ground.
The display program receives a data structure and logs, plots and displays things based on the received data frame type. (The processing for the IMU data is almost identical)
Now I want to upgrade the GPS to the Crescent Vector. The obvious software differences are:
- It provides Heading information
- It updates at 10Hz
- It does not support the garmin PGRMV sentance.
- None of its NMEA sentances have vertical velocity.
Humm I really want to know vertical velocity... digging in the crescent vector manual I discover that they have a binary message that has vertical velocity, in fact the single binary message has ALL the GPS data I have been capturing in a single message. The Crescent also has heading capability, alas it only outputs heading in a NMEA sentance, not a binary one. so my parsing state machine needs to process a mixed stream of Binary and NMEA messages.
The Binary message is nice in that it starts with $BIN so the beginning looks like a NMEA message, and the simple approach would be to just branch on this NMEA message ,
Its not that simple. My state machine resets its state to 0 whenever it sees a '$' beginning of message,but with the GPS sending binary data there is no guarentee that the binary data won't contain a '$' this breaks my state machine, so now the state machine knows if it is parsing a NMEA or binary data set and reacts accordingly. Also note that in a serial stream of chactors 1234.5678 there is no ambiguity on how to interpit the data. In a binary stream its a little bit more complicated. The GPS sends binary data as a IEEE754 double. standard format, but the GPS sends data in littel endian or intel format and the Coldfire processor I'm using uses big endian or Motorola format.(See Endian). SO I have to convert formats before I use the data. This is still a big win, because the endian conversion is much more efficient than parsing ASCII. Note that I'm already doing the endian conversion on the PC display software so this was not unexpected.
Once I'm parsing the GPS message the system stops responding reliably to telemetry commands....argghhhh! The problem is that If I keep the telemetry link busy sending data from the helicopter to the ground there is no time for the ground station to send data back. Up to this point the telemetry data stream was not too big for the down link pipe, switching from 5 to 10hz GPS pushes me over the edge. So now I write and debug a telemetry throttling routine that tries to keep the telemetry link idle for 50% of the time by throwing away data based on its age and priority.
All seems to be working except none of my telemetry frames have a spot for the GPS heading information, I'd like to keep both the GPS and IMU heading data, so I add a new GPS heading frame type to both the helicopter and the display software. Both areas are pretty modular so this is an easy fix. I label the new data with the same data type tag as the IMU heading data.... .
without remembering that the IMU heading is not floating point but a 0->65536 binary heading.(I worte the IMU parser and display code framework for my air lander over a year a go and have not really modifed it) Hence the GPS heading display is all messed up on the PC so I spend some time debugging the helicopter code to try and figure out why my parser is not properly parsing the GPS heading, only to eventually discover its a problem on the PC side.
This is now almost complete. At some future date I will add HOP and VDOP and signal to noise reporting. I'm now ready to take the whole helicopter outside and see how it works as an assembly. (I've been testing with two external GPS antennas on the roof. The GPS informs me that the antennas are 49.6 cm apart and that my roof has a heading of 172.3 degrees)
I really enjoy reading technical blog posts that give you a sense of the problems and struggles involved with building hardware. In an Ideal world I'd like to cover all of the project in this much detail. The reality of time and the need to sleep conspire against this. I've never been a skilled word smith so writing this saga took 25% as much time as struggling through the code. I don't have the patience to document everything to this level, but I'm going to try and do more posts at this level of detail.
Friday, December 07, 2007
Gingerbread cookies and GPS
I've been experimenting with a Crescent Vector GPS from Hemisphere GPS. It uses two antennas 1/2 meter apart to gove heading as well as GPS position at 10Hz. The only problem is that the helicopter test bed (and the rocket) is an electrically noisy place. So I built an adapter module that has an isolated DC-DC converter, a logic isolator and RS-232 level converters on a small PCB. I then needed to mount the whole thing in some kind of shielded enclosure. I've been reading the "Jack Crossfire blog" about the trials and tribulations of making a autonomous UAV helicopter. He used an altoids tin to shield his GPS, I'm using a gingerbread cookie tin. (Altoids was too small for the vector).
The back side....
With the top on....
And finally a picture of the carbon fiber frame that mounts to the helicopter and holds the two GPS antennas.
I should be ready to fly this contraption tonight, but Southern California are in the midst of a big rain storm and thats not conducive to flying the helicopter.
The back side....
With the top on....
And finally a picture of the carbon fiber frame that mounts to the helicopter and holds the two GPS antennas.
I should be ready to fly this contraption tonight, but Southern California are in the midst of a big rain storm and thats not conducive to flying the helicopter.
Sunday, December 02, 2007
Helicopter testing an a new notional vehicle.
I reviewd the telemetry from the last helicopter flight and I think I have finally resolved all my issues with telemetry and hardware. No glitches in either control or data , my telemetry logger logged correctly to SD media so I will never again loose telemetry data from a failure to save, or a dead laptop battery. I got no GPS data, but it's probably because I did not give ehough time for the GPS to lock prior to flight and it did not acquire in the high vib helicopter environement. I'm planning to swith GPS receivers before the next flight in any case.
A new notional vehicle. And a plan forward.
The big question with insufficient data is:
Are our rocket motors really robust for multiple firings and throttling?
We have fired multiple times for long runs within an hour, we have throttled, but we have also had failures. We need to run the motor through several simulated missions. That is follow the LLC flight throttle profile and restart in less than 1/2 hour. Until we have done that several times we do not know if we have a workable design or not.
If our motors work then we will probably continue with a 4 motor vehicle. If they do not we will probably develop a single larger motor. The notional design for the vehicle branches on that question.
Assuming we have a working motor the the current notional design is as shown above. The key is that the weight is supported by a simple pad under the tank and the landing gear only keeps the vehicle from tipping over.
If the motors don't work then we are probably going to build a single engine vehicle with spherical tanks. There are really only two configurations that seem to make sens, the Quad and the Pixel design. Pixel has balance feed problems, but is structurally more efficient. The one drawback I see to the armadillo module design is the mass of the landing gear and the fact that the motor is very close to the ground. I've ordered some hemispheres from AMS industries and they should be here some time in January.
A new notional vehicle. And a plan forward.
The big question with insufficient data is:
Are our rocket motors really robust for multiple firings and throttling?
We have fired multiple times for long runs within an hour, we have throttled, but we have also had failures. We need to run the motor through several simulated missions. That is follow the LLC flight throttle profile and restart in less than 1/2 hour. Until we have done that several times we do not know if we have a workable design or not.
If our motors work then we will probably continue with a 4 motor vehicle. If they do not we will probably develop a single larger motor. The notional design for the vehicle branches on that question.
Assuming we have a working motor the the current notional design is as shown above. The key is that the weight is supported by a simple pad under the tank and the landing gear only keeps the vehicle from tipping over.
If the motors don't work then we are probably going to build a single engine vehicle with spherical tanks. There are really only two configurations that seem to make sens, the Quad and the Pixel design. Pixel has balance feed problems, but is structurally more efficient. The one drawback I see to the armadillo module design is the mass of the landing gear and the fact that the motor is very close to the ground. I've ordered some hemispheres from AMS industries and they should be here some time in January.
Subscribe to:
Posts (Atom)