Thursday, January 24, 2008
Some simple Trig
Last night after I finished reassembling the helicopter I did some software work on the helicopter simulator . The sim is a full 3D 6DOF helicopter simulator with display. I downloaded it about 9 months ago and it works well. It was part of the source forge helicopter autopilot project. I've been using it to develop control laws for the real helicopter. Last night I changed my simulator control laws from having yaw always north facing to putting in a full transform from North, East to Forward Right for the position and velocity feedback loops. My helicopter sim now flies the full NG-LLC flight profile while doing slow 2 deg/sec rotations the whole time. It all works so the next stop for this code is the "real world " helicopter.
Wednesday, January 23, 2008
Crash Gordon and the Helicopter(s).
My Son came down from the bay area to visit this weekend so I did not get much unreasonable work done.
Crash #1 On Sunday we were going to a play in balboa park and I had 30 minutes to kill. so I was flying the little fully manual trex 450 in the driveway. While I was doing this my wife came out and started moving the garbage cans toward the curb. I was in the way so I landed the trex next to the truck, shut down and preceded to take off the neck strap on the transmitter so I could help with the trash, in the process of doing this I hooked the throttle hold switch with the neck strap and the helicopter spattered itself all over the side of the truck. Its a good thing the trash cans were not yet at the curb, I had additional material!
Background for Crash #2.
On the last reported test flight altitude hold worked very well, but I had not yet tested clmb and descent. So I made two minor software changes, I added limits to the vertical velocity. (Vertical velocity had just been the differential term in the alt hold PID, but I spluit that in half so I could explictly limit vertical velocity. )I reprogrammed the mode switch to facilitate testing this. The Mode switch has three settings mode 0, 1,2 Mode 0 has always been manual.
Mode 1 was rudder heading hold, mode 2 was Altitude and Rudder hold. I changed this so both Mode 0 and Mode 1 were manual and Mode 2 was automatic Rudder and altitude.
I also recorded the target Altitude , Heading and initial collective value when going from mode 0 to mode 1. The idea being that I could set my target altitude by toggling from 0 to 1 then manually deviate from this position and go to it when switching to mode 2.
I went and test flew this combination on Tuesday Morning. In the process of adding the velocity limits I'd changed a feed back sign and altitude hold went the wrong way... I started above my target and when engaged the helicopter accelerated up at ever increasing rates. I tried this twice and figured out what was wrong and called it a day after 45 seconds of flying.
I changed the software sign last night and went out this morning to test the change.
Crash #2
I did my usual preflight routine I made sure that all the controls on the helicopter moved in the correct direction. (In past S/W version this was also a test to insure I was in mode 0, because in mode 1 rudder would not respond) So I brought the helicopter to a stable hover about 30 feet in front of me at about 15 to 20 feet of altitude. I then proceeded to flip the mode fro0m mode 0 to mode 1, alas it was already in mode 1 and I went to mode 2. Realize that while manually flying a helicopter you can't look down at the transmitter to check switch positions. It must have gotten bumped into mode 1 while I was hooking up the main propulsion battery or starting the video camera. So when it went from Mode 0 to Mode 1 it was at altitude 0 and full down collective. So when I went to mode 2 its target altitude was 0 and its initial guess for the collective position was full down. This is a fully acrobatic helicopter so full down collective is at least 3 negative gees. Before I could react the helicopter was on the ground, hard.
Broken parts: Both skids,flybar, flybar paddles, both blades, GPS antenna mount, one blade grip ball end, battery tray and the Jesus bolt. (the bolt that holds the main rotor to the airframe is called the Jesus bolt) total damage about $120.00 with the majority of that being the blades.
I had spares of most of the parts. Tonights task was to reassemble the helicopter. Its done, but not tested yet, I'm letting the glue on the GPS antenna mount dry while I type this.
(After glue dried tested all electronics and systems all check out ok, ready for blade tracking in the AM weather permitting.)
Crash #1 On Sunday we were going to a play in balboa park and I had 30 minutes to kill. so I was flying the little fully manual trex 450 in the driveway. While I was doing this my wife came out and started moving the garbage cans toward the curb. I was in the way so I landed the trex next to the truck, shut down and preceded to take off the neck strap on the transmitter so I could help with the trash, in the process of doing this I hooked the throttle hold switch with the neck strap and the helicopter spattered itself all over the side of the truck. Its a good thing the trash cans were not yet at the curb, I had additional material!
Background for Crash #2.
On the last reported test flight altitude hold worked very well, but I had not yet tested clmb and descent. So I made two minor software changes, I added limits to the vertical velocity. (Vertical velocity had just been the differential term in the alt hold PID, but I spluit that in half so I could explictly limit vertical velocity. )I reprogrammed the mode switch to facilitate testing this. The Mode switch has three settings mode 0, 1,2 Mode 0 has always been manual.
Mode 1 was rudder heading hold, mode 2 was Altitude and Rudder hold. I changed this so both Mode 0 and Mode 1 were manual and Mode 2 was automatic Rudder and altitude.
I also recorded the target Altitude , Heading and initial collective value when going from mode 0 to mode 1. The idea being that I could set my target altitude by toggling from 0 to 1 then manually deviate from this position and go to it when switching to mode 2.
I went and test flew this combination on Tuesday Morning. In the process of adding the velocity limits I'd changed a feed back sign and altitude hold went the wrong way... I started above my target and when engaged the helicopter accelerated up at ever increasing rates. I tried this twice and figured out what was wrong and called it a day after 45 seconds of flying.
I changed the software sign last night and went out this morning to test the change.
Crash #2
I did my usual preflight routine I made sure that all the controls on the helicopter moved in the correct direction. (In past S/W version this was also a test to insure I was in mode 0, because in mode 1 rudder would not respond) So I brought the helicopter to a stable hover about 30 feet in front of me at about 15 to 20 feet of altitude. I then proceeded to flip the mode fro0m mode 0 to mode 1, alas it was already in mode 1 and I went to mode 2. Realize that while manually flying a helicopter you can't look down at the transmitter to check switch positions. It must have gotten bumped into mode 1 while I was hooking up the main propulsion battery or starting the video camera. So when it went from Mode 0 to Mode 1 it was at altitude 0 and full down collective. So when I went to mode 2 its target altitude was 0 and its initial guess for the collective position was full down. This is a fully acrobatic helicopter so full down collective is at least 3 negative gees. Before I could react the helicopter was on the ground, hard.
Broken parts: Both skids,flybar, flybar paddles, both blades, GPS antenna mount, one blade grip ball end, battery tray and the Jesus bolt. (the bolt that holds the main rotor to the airframe is called the Jesus bolt) total damage about $120.00 with the majority of that being the blades.
I had spares of most of the parts. Tonights task was to reassemble the helicopter. Its done, but not tested yet, I'm letting the glue on the GPS antenna mount dry while I type this.
(After glue dried tested all electronics and systems all check out ok, ready for blade tracking in the AM weather permitting.)
Saturday, January 19, 2008
Two controls down, two (hard ones )to go
I flew the helicopter this morning.
First time with altitude hold. The Autopilot does a MUCH better job of altitude hold than I do. Next Up (Sunday?) Pitch and Roll. this was also the first flight with airborne video, I'm not going to post the video because the camera was oscillating up and down and watching it makes one sea sick.
(I also pointed it too far down so 8 minutes of the dirt in a dirt parking lot would not be worth much.) I'll try to improve the angle and the mount before the next flight. The Ultimate Camera Helicopter would be: (http://www.bergenrc.com/ObserverTurbine.php, or maybe http://www.bergenrc.com/Observer.php)
The next steps will be
1)Pitch and Roll to Elevator and Alieron PIDs, where the RC system provides commanded pitch and roll angles.
2)Vforward and Vright velocities provide Desired Pitch and Roll where the RC system
provides desired Vforward and Vright.
3)GPS position hold -> Gives desired Vnorth and Veast ->yielding desired Vforward and Vright.
First time with altitude hold. The Autopilot does a MUCH better job of altitude hold than I do. Next Up (Sunday?) Pitch and Roll. this was also the first flight with airborne video, I'm not going to post the video because the camera was oscillating up and down and watching it makes one sea sick.
(I also pointed it too far down so 8 minutes of the dirt in a dirt parking lot would not be worth much.) I'll try to improve the angle and the mount before the next flight. The Ultimate Camera Helicopter would be: (http://www.bergenrc.com/ObserverTurbine.php, or maybe http://www.bergenrc.com/Observer.php)
The next steps will be
1)Pitch and Roll to Elevator and Alieron PIDs, where the RC system provides commanded pitch and roll angles.
2)Vforward and Vright velocities provide Desired Pitch and Roll where the RC system
provides desired Vforward and Vright.
3)GPS position hold -> Gives desired Vnorth and Veast ->yielding desired Vforward and Vright.
Friday, January 18, 2008
Smart helicopters...
A good read on automating a helicopter.
http://sun-valley.stanford.edu/papers/Conway:95.pdf
http://sun-valley.stanford.edu/papers/Conway:95.pdf
Control Stratagey
The four things I can control are: Rudder, Collective, Elevator, Aileron.
My scheme for control is to use a set of PID loops.
Most likely some of these will only have P gain, but the concept is to use the following:(Copied from code) The PIDs marked with * in the comments will be different in the rocket.
OnePidElement Yaw_to_Rudder; //Takes IMU yaw and drives rudder *
OnePidElement Alt_to_VSpeed; // target altitude drives desired vspeed.
OnePidElement VSpeed_To_Collective;// desired vspeed drives collective.*
OnePidElement Pitch_To_Elevator;//desired pitch drives Elevator.*
OnePidElement Roll_To_Alieron;// desired roll drives Alieron.*
OnePidElement V_Forward_To_Pitch;//desired Vforward drives pitch.
OnePidElement V_Right_To_Roll; //desired Vright and drives roll
OnePidElement Long_to_V_East; //desired Longitude and drives VEast.
OnePidElement Lat_to_V_North; //desired Lattitude and drives VNorth;
And one more conversion function:
void ConvertDirection(double V_North, //Desired V_North input
double V_East,//Desired V_East input
double Yaw,//Current True YAW corrected for magnetic deviation input,
double &V_Forward,// Converted V_Forward target out
double & V_Right, //Converted V_Right target out
);
OnePidElement is an object that holds the a PIDGainConstants object and the current integration state.
The Yaw to rudder , Pitch to Elevator and Roll to Alieron PIDs will be run for each IMU sample.
All other PID's will be run for each GPS data set.
I'm not planning to integrate the accelerometers. (Yet)
An example would be:
Elevator=Pitch_To_Elevator.DoServoPidAdjust(target_pitch, imu.pitch , imu.x_rate);
Each OnePidElement contins a PID gainObject that has the following gain limit elements:
double p_gain;//Proportional Gain
double i_gain;//Integrator Gain;
double d_delta_gain; //Sample to Sample delta gain
double d_meas_gain; //Rate as measured by IMU or GPS
double max_i_windup;// Maximum integrator value limit.
double min_i_windup;//Minimum integrator value limit.
double max_out_limit;//Maximum allowable value or adjustment
double min_out_limit;//Minimum allowable value or adjustment
In fact I have two D terms in my PID. One is change in the sampled values (IE the delta term from sample n-1 to n) and the directly measured rate. The directly measured differential/change rates are from the IMU and GPS.
I'm currently working on the interface to selectively change these PID constants in flight. This might be easier if I switch to a two person operation, one to fly the helicopter and one to twiddle the gains. For Now I'm just going to work one axis/ PID at a time.
Above all of this is the rather simple executive that generates the sequence of target lat,lon and altitude. At this point that excutive just tried to freeze the vehicle in space when activated. (IE use the current Yaw, Alt ,Lat,Lon as the target)
(Sorry for the crummy code formatting blogger does not seem to like formatting code in a reasonable way)
My scheme for control is to use a set of PID loops.
Most likely some of these will only have P gain, but the concept is to use the following:(Copied from code) The PIDs marked with * in the comments will be different in the rocket.
OnePidElement Yaw_to_Rudder; //Takes IMU yaw and drives rudder *
OnePidElement Alt_to_VSpeed; // target altitude drives desired vspeed.
OnePidElement VSpeed_To_Collective;// desired vspeed drives collective.*
OnePidElement Pitch_To_Elevator;//desired pitch drives Elevator.*
OnePidElement Roll_To_Alieron;// desired roll drives Alieron.*
OnePidElement V_Forward_To_Pitch;//desired Vforward drives pitch.
OnePidElement V_Right_To_Roll; //desired Vright and drives roll
OnePidElement Long_to_V_East; //desired Longitude and drives VEast.
OnePidElement Lat_to_V_North; //desired Lattitude and drives VNorth;
And one more conversion function:
void ConvertDirection(double V_North, //Desired V_North input
double V_East,//Desired V_East input
double Yaw,//Current True YAW corrected for magnetic deviation input,
double &V_Forward,// Converted V_Forward target out
double & V_Right, //Converted V_Right target out
);
OnePidElement is an object that holds the a PIDGainConstants object and the current integration state.
The Yaw to rudder , Pitch to Elevator and Roll to Alieron PIDs will be run for each IMU sample.
All other PID's will be run for each GPS data set.
I'm not planning to integrate the accelerometers. (Yet)
An example would be:
Elevator=Pitch_To_Elevator.DoServoPidAdjust(target_pitch, imu.pitch , imu.x_rate);
Each OnePidElement contins a PID gainObject that has the following gain limit elements:
double p_gain;//Proportional Gain
double i_gain;//Integrator Gain;
double d_delta_gain; //Sample to Sample delta gain
double d_meas_gain; //Rate as measured by IMU or GPS
double max_i_windup;// Maximum integrator value limit.
double min_i_windup;//Minimum integrator value limit.
double max_out_limit;//Maximum allowable value or adjustment
double min_out_limit;//Minimum allowable value or adjustment
In fact I have two D terms in my PID. One is change in the sampled values (IE the delta term from sample n-1 to n) and the directly measured rate. The directly measured differential/change rates are from the IMU and GPS.
I'm currently working on the interface to selectively change these PID constants in flight. This might be easier if I switch to a two person operation, one to fly the helicopter and one to twiddle the gains. For Now I'm just going to work one axis/ PID at a time.
Above all of this is the rather simple executive that generates the sequence of target lat,lon and altitude. At this point that excutive just tried to freeze the vehicle in space when activated. (IE use the current Yaw, Alt ,Lat,Lon as the target)
(Sorry for the crummy code formatting blogger does not seem to like formatting code in a reasonable way)
Wednesday, January 16, 2008
The urge to have a science project.
One has to be careful that time and money are allocated correctly. For several years I've been contemplating developing a lower cost GPS Differential/RTK system using commercial receivers.
While an open source solution would be a nice to have, it really makes no sense. I can purchase off the shelf differential GPS solutions that are inexpensive given any realistic valuation of my time. Rather than spend months developing a GPS solution I've decided to just purchase one off the shelf. I'm going to use the hemisphere GPS crescent oem board with their RTK and 20 Hz options. I'll integrate the RTK base into my Telemetry suitcase and the rover goes on the Rocket/Helicopter. This is just so much easier than developing a either a GPS solution or a fancy interial/GPS Kalman filter. The data sheet accuracy for the RTK solution is 2cm. If it can keep that in a dynamic environment that will be amazing, even the specified L-diff solution at 28cm is plenty good enough.
While an open source solution would be a nice to have, it really makes no sense. I can purchase off the shelf differential GPS solutions that are inexpensive given any realistic valuation of my time. Rather than spend months developing a GPS solution I've decided to just purchase one off the shelf. I'm going to use the hemisphere GPS crescent oem board with their RTK and 20 Hz options. I'll integrate the RTK base into my Telemetry suitcase and the rover goes on the Rocket/Helicopter. This is just so much easier than developing a either a GPS solution or a fancy interial/GPS Kalman filter. The data sheet accuracy for the RTK solution is 2cm. If it can keep that in a dynamic environment that will be amazing, even the specified L-diff solution at 28cm is plenty good enough.
Tuesday, January 15, 2008
A Quick test flight.
I fully checked out the power system and added a completely 100% separate regulator for the receiver. I re did the bearings in the blade grips and I then flew the helicopter this morning before work. The flight was uneventful. I left the telemetry receiver sitting in the front seat of the truck and this caused telemetry dropouts. Up to now the telemetry reception has been 100% perfect. The display software was ignoring the checksums and size checks, after todays flight I need to fix that as partial data frames make for really strange data. This will be tonights task. The next test flight will test altitude hold.
P.S. any GPS internals experts out there reading the blog? I would like to put together a low cost open source L1 code differential solution and or carrier phase RTK solution. I think this would be a very valuable tool for a lot of interesting robot, uav, helicopter, rocket etc... projects.
I even willing to subsidize the effort with some $.
P.S. any GPS internals experts out there reading the blog? I would like to put together a low cost open source L1 code differential solution and or carrier phase RTK solution. I think this would be a very valuable tool for a lot of interesting robot, uav, helicopter, rocket etc... projects.
I even willing to subsidize the effort with some $.
Sunday, January 13, 2008
(Update) A Day of testing.
(Update I found the receiver problem, read to end)
I drove out to Mojave Friday night and spent all day Saturday at FAR. There was a TV program shooting pictures of large high power rockets and that was kind of cool to watch. It took them all day to do some background video and two flights. The flights went perfectly. I had often contemplated inviting some TV to our tests, but after watching them all day I don't think I could handle the time impact, its much more intrusive than I would have expected.
In any case I set up shop in the propellant mixing shed and did some flight testing. My previous helicopter testing I'd writte some code, drive somewhere to test it, go home to review the data and do it again. Saturday I had the laptop in a reasonably comfortable dim space 10 steps from where I could fly the helicopter. (Dim is necessary because you can't really read a laptop in bright sun). I made a lot more progress than I would have the traditional way. It was really nice to be able to change code do a 30 second flight review data and then change code again all inside 10 minutes. It was not perfect, the smallest screen I usually do development on is a nice 24" LCD. Doing development on the laptop fees cramped, but the quick cycle time is a big win.
Flight #1I verified that the CCPM code on the helicopter worked correctly in flight. I also verified that the heading hold code developed on the lazy susan works properly in flight.
Flight #2 I fixed the heading hold gain and removed it from the adjustable gain lever in preparation for doing altitude hold. I also did some hard vertical climbs and descents to gather some altitude data. On review the GPS altitude data was really choppy. I added an integration of the GPS velocity to the variables calculated and modified the data review code to allow me to zero this and display it. (The display code is a lot more complicated than the flight code and hence harder top work with on the Laptop)
Flight #3 Integrated GPS velocity was much better, still not perfect, the data had a downward bias. Sat down and looked carefully at the GPS data, GPS altitude was jumping in 4 m steps, very strange. I had not yet looked at the GPS position data, it looks reasonable, but Id not carefully examined it. So I paced off a 20M square oriented to true norht in the dirt and marked the corners.
Hand carry #1 I then carefully hand carried the helicopter over the 20 M square. First at waist height, then with the helicopter held as high as I could over my head. On review I got zero data. So I swap out the sd card in the data logger and do a 30 second run .I got data this time. A note on the data collection process. The Laptop can display all the data in real time, but the useful mode is to command the telmetry suitcase to shut down. Take the SD card out of the telemetry suitcase, put it into the reader, copy it into the laptop data directory, rename it to something meaningful, and write a summary in the lab notebook of what the flight test was while you still remember, then review the data on the laptop. I need to streamline this process.
Hand Carry #2
I carrnyone watching would think I'd gone crazy and was out waltzing with my helicopter. On review thy the helicopter around the 20 m square spinning 360 degrees at each corner (so I can see the heading change on the data to know where the corners were.) Ae GPS position data just isn't right. The altitude data is also doing 4M jumps. Only the GPS data is suspect, everything else is fine. The GPS data goes from the GPS to the onboard computer in binary form then its converted to be computer endian and packaged into another structure and set out telemetry. So I add another telemetry frame type to ship the raw unconverted GPS binary data to down the telemetry stream without touching it at all. I then modify the data display program to have duplicate fields for all the GPS data. (The PC is the same endian as the GPS no conversion necessary).
Hand Carry #3 Same path around the 20M square spinning at each corner.The two data sets do not AGREE!!!!! ARGHHHH. In looking at the endian conversion on the PC telemetry side I'd used HTONL host to network long it works as expected because the PC does not store data in the expected network byte order. On the Netburner side the natural storage is network byte order so HTONL is a no op on the platform. SO I'd written my own byte swap. It had typo/ error, where the 3rd byte of the float got the 4th byte duplicated. On the 8 byte doubles the 3rd got the 4th and the 7th got the 8th. So I fix this.
Hand Carry #4 The Data sets match, and the altitude is sensitive enough and not jumpy. It even detects me setting the helicopter on the ground , on the work table and holding it over my head! Cool.
Flight #4 Lift off and the helicopter is shaking/ vibrating really badly. Land immediately. One tail rotor blade had split, probably hit the sand on the flight #3 landing. Change tail rotor blades.
Flight 6.7.8.9.10.11 etc... Helicopter is still vibrating, main blade tracking is really off. I do a short flight and try to adjust the tracking. I have some people trying to help me spot which blade is high the red or blue tip. The tracking just seems random, either I'm making to big adjustment or something else is wrong. Still vibrating badly. On the 6th or 7th hop helicopter goes from low hover down to land abruptly, not damaging hard, but more abrupt, and uncommanded by me.
Helicopter is sitting on the ground upright and running and I have no control. Thats easy I've set up so the motor controller is not run by my computer system it's run directly by the RC receiver so in the worst case I can shut it down without relying on software. no dice, the system does not shutdown???? I continue to fiddle with the transmitter, I shut it off. (RC receiver failsafe should shut it down... it does not) Flip the transmitter on and off. Walk around the helicopter trying fiddeling with the transmitter. It shuts down. Quickly go over and disconnect the main power battery. Back on the work bench table I test the receiver battery pack and it seems very low. All the parts of the rotor head seem ok, so I suspect that the rotor blades are failing in some way. I remove the rotor baldes and run the helicopter on the bench. Very smooth and no vibration. I take my spare blades and using a sharpie paint a black stripe on one tip. I install a fresh receiver battery and the new blades. All the controls work, I check all the cable bundels for a loose connector or other problem. All looks good.
Flight N+1 I set the helicopter down on the ground and command the motor to start. I immediately loose control. The Motor is running the helicopter has negative collective commanded so its firmly on the ground but I have no control. I start fiddeling with the transmitter on-off nothing the helicopter will not shut down. After about 5 minutes of this I crawl up to the front of the helicopter reach in and disconnect the power battery.
Is it the transmitter or the receiver?
I take out the small Trex 450 and fly it, it's perfect. The problem is not the transmitter.
Start packing up. I put everything away tables back in my container. Clean up pack etc.
I pack up everything but the little Trex. So I fly that some just for fun. I did my first helicopter rolls in real life!. I've done them on the simulator a lot, but this was the first time in real life. I pack up. Its 4:45 pm I arrive back home at 9:30 PM (Traffic in LA was bad) I unpack the car. All in all a great day.
I suspect that my receiver problem is related to this.
I apologize to all that this has become the unreasonable helicopter blog. But we should be back to rockets in the next 4 to 6 weeks.
I did some more testing today outside the garage. The on/off stick on problem persists even
when I changed the receiver. It goes away if I power the receiver separately.It seems that there is a loose or flaky power problem with the system. I'm going to put the receiver on a separate power source. I also rebuilt the bearings in the blade grips and replaced the plastic blade grips with metal and now the rotor tracks perfectly. In any case I now have a spare receiver and I've done the rework recommended in the link to my earlier suspected problem.
I drove out to Mojave Friday night and spent all day Saturday at FAR. There was a TV program shooting pictures of large high power rockets and that was kind of cool to watch. It took them all day to do some background video and two flights. The flights went perfectly. I had often contemplated inviting some TV to our tests, but after watching them all day I don't think I could handle the time impact, its much more intrusive than I would have expected.
In any case I set up shop in the propellant mixing shed and did some flight testing. My previous helicopter testing I'd writte some code, drive somewhere to test it, go home to review the data and do it again. Saturday I had the laptop in a reasonably comfortable dim space 10 steps from where I could fly the helicopter. (Dim is necessary because you can't really read a laptop in bright sun). I made a lot more progress than I would have the traditional way. It was really nice to be able to change code do a 30 second flight review data and then change code again all inside 10 minutes. It was not perfect, the smallest screen I usually do development on is a nice 24" LCD. Doing development on the laptop fees cramped, but the quick cycle time is a big win.
Flight #1I verified that the CCPM code on the helicopter worked correctly in flight. I also verified that the heading hold code developed on the lazy susan works properly in flight.
Flight #2 I fixed the heading hold gain and removed it from the adjustable gain lever in preparation for doing altitude hold. I also did some hard vertical climbs and descents to gather some altitude data. On review the GPS altitude data was really choppy. I added an integration of the GPS velocity to the variables calculated and modified the data review code to allow me to zero this and display it. (The display code is a lot more complicated than the flight code and hence harder top work with on the Laptop)
Flight #3 Integrated GPS velocity was much better, still not perfect, the data had a downward bias. Sat down and looked carefully at the GPS data, GPS altitude was jumping in 4 m steps, very strange. I had not yet looked at the GPS position data, it looks reasonable, but Id not carefully examined it. So I paced off a 20M square oriented to true norht in the dirt and marked the corners.
Hand carry #1 I then carefully hand carried the helicopter over the 20 M square. First at waist height, then with the helicopter held as high as I could over my head. On review I got zero data. So I swap out the sd card in the data logger and do a 30 second run .I got data this time. A note on the data collection process. The Laptop can display all the data in real time, but the useful mode is to command the telmetry suitcase to shut down. Take the SD card out of the telemetry suitcase, put it into the reader, copy it into the laptop data directory, rename it to something meaningful, and write a summary in the lab notebook of what the flight test was while you still remember, then review the data on the laptop. I need to streamline this process.
Hand Carry #2
I carrnyone watching would think I'd gone crazy and was out waltzing with my helicopter. On review thy the helicopter around the 20 m square spinning 360 degrees at each corner (so I can see the heading change on the data to know where the corners were.) Ae GPS position data just isn't right. The altitude data is also doing 4M jumps. Only the GPS data is suspect, everything else is fine. The GPS data goes from the GPS to the onboard computer in binary form then its converted to be computer endian and packaged into another structure and set out telemetry. So I add another telemetry frame type to ship the raw unconverted GPS binary data to down the telemetry stream without touching it at all. I then modify the data display program to have duplicate fields for all the GPS data. (The PC is the same endian as the GPS no conversion necessary).
Hand Carry #3 Same path around the 20M square spinning at each corner.The two data sets do not AGREE!!!!! ARGHHHH. In looking at the endian conversion on the PC telemetry side I'd used HTONL host to network long it works as expected because the PC does not store data in the expected network byte order. On the Netburner side the natural storage is network byte order so HTONL is a no op on the platform. SO I'd written my own byte swap. It had typo/ error, where the 3rd byte of the float got the 4th byte duplicated. On the 8 byte doubles the 3rd got the 4th and the 7th got the 8th. So I fix this.
Hand Carry #4 The Data sets match, and the altitude is sensitive enough and not jumpy. It even detects me setting the helicopter on the ground , on the work table and holding it over my head! Cool.
Flight #4 Lift off and the helicopter is shaking/ vibrating really badly. Land immediately. One tail rotor blade had split, probably hit the sand on the flight #3 landing. Change tail rotor blades.
Flight 6.7.8.9.10.11 etc... Helicopter is still vibrating, main blade tracking is really off. I do a short flight and try to adjust the tracking. I have some people trying to help me spot which blade is high the red or blue tip. The tracking just seems random, either I'm making to big adjustment or something else is wrong. Still vibrating badly. On the 6th or 7th hop helicopter goes from low hover down to land abruptly, not damaging hard, but more abrupt, and uncommanded by me.
Helicopter is sitting on the ground upright and running and I have no control. Thats easy I've set up so the motor controller is not run by my computer system it's run directly by the RC receiver so in the worst case I can shut it down without relying on software. no dice, the system does not shutdown???? I continue to fiddle with the transmitter, I shut it off. (RC receiver failsafe should shut it down... it does not) Flip the transmitter on and off. Walk around the helicopter trying fiddeling with the transmitter. It shuts down. Quickly go over and disconnect the main power battery. Back on the work bench table I test the receiver battery pack and it seems very low. All the parts of the rotor head seem ok, so I suspect that the rotor blades are failing in some way. I remove the rotor baldes and run the helicopter on the bench. Very smooth and no vibration. I take my spare blades and using a sharpie paint a black stripe on one tip. I install a fresh receiver battery and the new blades. All the controls work, I check all the cable bundels for a loose connector or other problem. All looks good.
Flight N+1 I set the helicopter down on the ground and command the motor to start. I immediately loose control. The Motor is running the helicopter has negative collective commanded so its firmly on the ground but I have no control. I start fiddeling with the transmitter on-off nothing the helicopter will not shut down. After about 5 minutes of this I crawl up to the front of the helicopter reach in and disconnect the power battery.
Is it the transmitter or the receiver?
I take out the small Trex 450 and fly it, it's perfect. The problem is not the transmitter.
Start packing up. I put everything away tables back in my container. Clean up pack etc.
I pack up everything but the little Trex. So I fly that some just for fun. I did my first helicopter rolls in real life!. I've done them on the simulator a lot, but this was the first time in real life. I pack up. Its 4:45 pm I arrive back home at 9:30 PM (Traffic in LA was bad) I unpack the car. All in all a great day.
I suspect that my receiver problem is related to this.
I apologize to all that this has become the unreasonable helicopter blog. But we should be back to rockets in the next 4 to 6 weeks.
I did some more testing today outside the garage. The on/off stick on problem persists even
when I changed the receiver. It goes away if I power the receiver separately.It seems that there is a loose or flaky power problem with the system. I'm going to put the receiver on a separate power source. I also rebuilt the bearings in the blade grips and replaced the plastic blade grips with metal and now the rotor tracks perfectly. In any case I now have a spare receiver and I've done the rework recommended in the link to my earlier suspected problem.
Thursday, January 10, 2008
Data Review.
I modified the data display software tonight to back out the Collective, Pitch and Roll commands from the CCPM servo data. I then reviewed the free flights I did on the 3rd. Toward the end of the flight I did deliberate abrupt pitch, roll and climb maneuvers so I could look at the data and see how much servo movement corresponded with how much vehicle movement. The picture below is a screen capture of the data display. Sevro Roll is the Roll command (red) Roll (Blue) is the actual vehicle roll and the ragged (magenta) line is the raw measured gyro rate.
They all look reasonable. As did pitch , servo pitch and X rate. The Vertical velocity tracked collective reasonable well, but the altitude seemed to wander a lot more. Click on the picture for a bigger view.
Its 11:00 pm and this was another 4 1/2 hour evening.
They all look reasonable. As did pitch , servo pitch and X rate. The Vertical velocity tracked collective reasonable well, but the altitude seemed to wander a lot more. Click on the picture for a bigger view.
Its 11:00 pm and this was another 4 1/2 hour evening.
Fly as you train, train as you fly.
I've been flying RC airplanes for a very long time, but I did not ever fly a helicopter until about two years ago. I bought the real flight simulator and made a serious, 15 minutes an evening , effort to learn to fly the helicopter. I did this every evening for months. I did not buy a helicopter until I could fly the simulator with full realism and gusty wind 10 times out of ten for A full tank of gas without crashing. Once I could do 10 of 10 I bought a helicopter jkit and started trying to fly in the real world. This illustrates a subtle point the picture below shows me sitting in my computer chair flying the sim.
The only problem is that if you then take a picture of me holding the real transmitter
like I fly the real helicopter there are differences.
With the transmitter on my lap I hold the sticks with my fingers, standing with the tranmitter dangling I naturally fly with my thumbs. On the simulator I can easily do 720 degree piroettes
without out gaining or loosing altitude ot position stability. I real life this is not so easy.
So I've started practicing with the simulator standing in front of the computer with the simulator controller hanging from a strap. Even subtle differences between things make a difference. Especially if it is in trained muscle memory.
The next helicopter Step.
Basic control laws are going to be:
1)Desired course/way points ->generates desired position.
2)Current position(gps) and desired position ->Generate desired velocity.
3)Desired velocity +Actual velocity(gps) ->Generate desired pitch/roll attitude.
4)Desired Pitch Roll Attitude +Actual pitch roll attitude(imu) -> Generate (virtual) Elevator and Aileron signals.
Separately we control heading (alwayas points true north) and altitude. (Heading control is done and works)
Note that all of thsi software will be identical on the rocket, except the very last part
>>>Desired Pitch Roll Attitude +Actual pitch roll attitude -> Generate Elevator and Aileron signals.
I've had all this working with the helicopter simulator for 6 or more months. I'm just a bit cautious and chicken when it comes to flying it in the real helicopter. I'm going to work my way up the list backwards. This brings me to todays waffling decision. As presently set up the helicopter is about 4K of hardware and 100 hours of work. I'm a bit cautious with it.
I worked out the yaw control with a lazy Susan. Today I gathered all the parts necessary to
build a mount for the helicopter that would allow it to move about 15 degrees
in pitch and roll and 360 degrees in yaw freely. It would take me about 4 hours to assemble all of this. This only helps with Step 4 all the other steps have to be done in free flight anyway, so is it worth building the pivot mount??? My strategy is as follows Beyond the basic flight controls I have the software set up to respond to two of the RC transmitter controls (outlined in red below)
Aux 2 is a three position switch that selects three software modes. 0,1,2
Mode 0 is full manual control.
Mode 1 enables the autopilot parts that presently work. (currently only the yaw)
Mode 2 enables the new component we want to test.
"Lever" is a slide lever on the side of the helicopter that I have setup to control a software
variable that goes from 0 to 100. The intent is to have this lever control the gain of the control loop I'm currently working on. The problem is that both of these are on the wrong side of the transmitter for the next step as the cyclic control is what I'm trying to automate and also the right hand stick. My real problem is that I actually need to start flying the helicopter regularly.
I also do most of my work in the evening so I need to fly it at night and its not safe to fly by myself. (The big Trex600 could cause serious injury if it went out of control and went for the pilot) I've flown the vehicle a couple of times in the dirt parking lot near the DelMar fairgrounds
(The security guard thought the helicopter was cool, but told me that if anyone asks I'm not supposed to be there.) I could start flying at one of the regular RC model flying clubs, but the fact that the system has a GPS and could, with the proper software, fly beyond the pilots direct line of sight makes in in violation of the RC club safety rules. I think it would be rude to jeopardize a long standing RC club and its flying field by violating the rules.
The only problem is that if you then take a picture of me holding the real transmitter
like I fly the real helicopter there are differences.
With the transmitter on my lap I hold the sticks with my fingers, standing with the tranmitter dangling I naturally fly with my thumbs. On the simulator I can easily do 720 degree piroettes
without out gaining or loosing altitude ot position stability. I real life this is not so easy.
So I've started practicing with the simulator standing in front of the computer with the simulator controller hanging from a strap. Even subtle differences between things make a difference. Especially if it is in trained muscle memory.
The next helicopter Step.
Basic control laws are going to be:
1)Desired course/way points ->generates desired position.
2)Current position(gps) and desired position ->Generate desired velocity.
3)Desired velocity +Actual velocity(gps) ->Generate desired pitch/roll attitude.
4)Desired Pitch Roll Attitude +Actual pitch roll attitude(imu) -> Generate (virtual) Elevator and Aileron signals.
Separately we control heading (alwayas points true north) and altitude. (Heading control is done and works)
Note that all of thsi software will be identical on the rocket, except the very last part
>>>Desired Pitch Roll Attitude +Actual pitch roll attitude -> Generate Elevator and Aileron signals.
I've had all this working with the helicopter simulator for 6 or more months. I'm just a bit cautious and chicken when it comes to flying it in the real helicopter. I'm going to work my way up the list backwards. This brings me to todays waffling decision. As presently set up the helicopter is about 4K of hardware and 100 hours of work. I'm a bit cautious with it.
I worked out the yaw control with a lazy Susan. Today I gathered all the parts necessary to
build a mount for the helicopter that would allow it to move about 15 degrees
in pitch and roll and 360 degrees in yaw freely. It would take me about 4 hours to assemble all of this. This only helps with Step 4 all the other steps have to be done in free flight anyway, so is it worth building the pivot mount??? My strategy is as follows Beyond the basic flight controls I have the software set up to respond to two of the RC transmitter controls (outlined in red below)
Aux 2 is a three position switch that selects three software modes. 0,1,2
Mode 0 is full manual control.
Mode 1 enables the autopilot parts that presently work. (currently only the yaw)
Mode 2 enables the new component we want to test.
"Lever" is a slide lever on the side of the helicopter that I have setup to control a software
variable that goes from 0 to 100. The intent is to have this lever control the gain of the control loop I'm currently working on. The problem is that both of these are on the wrong side of the transmitter for the next step as the cyclic control is what I'm trying to automate and also the right hand stick. My real problem is that I actually need to start flying the helicopter regularly.
I also do most of my work in the evening so I need to fly it at night and its not safe to fly by myself. (The big Trex600 could cause serious injury if it went out of control and went for the pilot) I've flown the vehicle a couple of times in the dirt parking lot near the DelMar fairgrounds
(The security guard thought the helicopter was cool, but told me that if anyone asks I'm not supposed to be there.) I could start flying at one of the regular RC model flying clubs, but the fact that the system has a GPS and could, with the proper software, fly beyond the pilots direct line of sight makes in in violation of the RC club safety rules. I think it would be rude to jeopardize a long standing RC club and its flying field by violating the rules.
Wednesday, January 09, 2008
Another evenings Details.
I picked up burger king on the way home, I got home at about 6:30. Mariellen (my wife) is still fighting the cold/flu. when she is feeling bad she naps all day. She had already eaten so I finished dinner and watched news at about 7:00.
I really liked the way the lazy susan worked for the rudder so after thinking about it I thought the concept might be useful for pitch and roll. I'm thinking I'll mount the helicopter on top of some kind of post with a ball joint so it can pitch roll and spin. So I start the evening with the McMastercarr website looking for a good ball joint. I find several, they are either 2 weeks lead or in stock in Chicago. (anything in stock in Los Angles is next day even when paying UPS ground charges)
I want to do this this week end so I either pay next day air charges or find a different solution.
I have until Thursday Morning to decide so I go out in the garage open up my Mechanical junk box and start digging. I find the jewel like hand made ball bearing universal joint mounted to an estes D motor with some digital servos. A long ago experiment that I machined up only to discover that the inertia moments for a small rocket mean you need really fast response. Faster than the servos can give. I disassemble this assembly (It was about 20 hours of jewel like machining on the taig CNC mill three years ago.) It looks strong enough, but the range of motion is limited and no rotation. So I keep digging and find a large Rod end with a ball bearing that will be perfect. I just need to get the right kind of spacers and through bolt from Marshals Industrial Hardware Thursday at Lunch. I clean up my mechanical parts mess and go back in the house. Time 8:30. I check up on Mariellen, she is still feeling yucky, but she needs some things at the store. Trip to store return at about 9:00.
Next Stop helicopter software.
The helicopter uses CCPM Cyclic Collective Pitch mixing. What does this mean?
A normal single rotor helicopter has three main controls. The Tail rotor pitch for Yaw or turning left right. Collective pitch for changing the amount of lift. Collective pitch controls the main rotor blade pitch collectively, meaning all the blades increase or decrease pitch together.
The cyclic pitch control for tipping in pitch forward/back, or and roll left/right. Cyclic pitch cyclically changes the blade pitch as it goes around. All of this is transmitted to the rotor blade via the swashplate. The swash moves up and down for collective and tips forward/ back left/right for cyclic control.
The traditional method for controlling the swash is to have separate controls, or actuators for pitch, roll and collective and to mix them together with a mechanical mixing system. Every added linkage ads slop to the controls. The mechanical mixing systems add lots of slop. The acrobatic RC helicopter guys figured out that if you connect the servos directly to the swash plate, with no other linkages, things would be more precise. So they invented CCPM what it really means is that there are three servos spaced evenly around the swash plate at 120 degree intervals. If you want the swash to go straight up for a pure collective move then all three servos have to move straight up. If you want the swash to roll to the left, the rear servo stays still, the left goes down and the right goes up. It you want it to pitch nose up, the rear servo goes down and the left- right servos go up, but by half the amount. cos( 120 degrees/2). All of this is normally handled by some software in the RC transmitter. the way I'm currently flying is to just read the commanded positions and have the computer pass them through without modification. (Other than the rudder where I have compass heading hold working when commanded)
I really want to start working on the pitch, roll and collective controls. So rather than debug my mixing software at the same time as my controls software I split the beast in half. I'll tell the RC transmitter to treat the helicopter like it has mechanical mixing and have the software do the CCPM mixing on the helicopter.
Step 1) Backup ALL the software everywhere into a was_working_1_09_08 directory.
Step 2) remove the helicopter from the Lazy Susan and bring it inside to test.
Step 3) Modify the Telemetry display software so it shows servo pulse positions in counts rather than +/-100%
Step 4 )Run the existing system and record all the servo (right, left, rear) positions for:
Full down and Full up and neutral collective with neutral cyclic.
Full forward, Aft and neutral cyclic with neutral collective.
Step 5)Reprogram the transmitter to not do CCPM. *(requires downloading manual from JR website and reading a few pages)
Step 6)Record the servo count limits for Elevator, Aileron and Collective servos.
Step 7 )put all the numbers from step 4 and 6 into excel and see if the make sense. They do make sense. The scalings all look reasonable and linear.
Step 8) Reconfigure software to store received RC commands from the appropriate channels in Collective, Aileron and Elevator variables.
Step 9 )write code to translate these Collective, Aileron and Elevator variables into servo commands for left, right and rear. (remembering to limit check everything)
Step 10) Test the software.
I finished this at about 10:30, but by this time the helicopter had been running controls and telemetry non stop for 1.5 hours and the status indicators were giving me the controls battery too low indications. I still need to repeat step 4 with the new software to make sure my mapping is correct, but it looks good visually. I'll do that in the morning before I go to work.
It's currently 11:01 another evening gonI e. I have to stay up until the battery is done as I don't leave LiPos on a charger unattended. ( I wrote this entry while the battery was on the charger.)
I also need to go to bed. Its going to be a long day at work Thursday as my business partner and one of by best support engineers are going to CES to gawk at the 150 inch LCD screens.
This means I'll have to do a bit more than normal in both sales support and technical support.
I really liked the way the lazy susan worked for the rudder so after thinking about it I thought the concept might be useful for pitch and roll. I'm thinking I'll mount the helicopter on top of some kind of post with a ball joint so it can pitch roll and spin. So I start the evening with the McMastercarr website looking for a good ball joint. I find several, they are either 2 weeks lead or in stock in Chicago. (anything in stock in Los Angles is next day even when paying UPS ground charges)
I want to do this this week end so I either pay next day air charges or find a different solution.
I have until Thursday Morning to decide so I go out in the garage open up my Mechanical junk box and start digging. I find the jewel like hand made ball bearing universal joint mounted to an estes D motor with some digital servos. A long ago experiment that I machined up only to discover that the inertia moments for a small rocket mean you need really fast response. Faster than the servos can give. I disassemble this assembly (It was about 20 hours of jewel like machining on the taig CNC mill three years ago.) It looks strong enough, but the range of motion is limited and no rotation. So I keep digging and find a large Rod end with a ball bearing that will be perfect. I just need to get the right kind of spacers and through bolt from Marshals Industrial Hardware Thursday at Lunch. I clean up my mechanical parts mess and go back in the house. Time 8:30. I check up on Mariellen, she is still feeling yucky, but she needs some things at the store. Trip to store return at about 9:00.
Next Stop helicopter software.
The helicopter uses CCPM Cyclic Collective Pitch mixing. What does this mean?
A normal single rotor helicopter has three main controls. The Tail rotor pitch for Yaw or turning left right. Collective pitch for changing the amount of lift. Collective pitch controls the main rotor blade pitch collectively, meaning all the blades increase or decrease pitch together.
The cyclic pitch control for tipping in pitch forward/back, or and roll left/right. Cyclic pitch cyclically changes the blade pitch as it goes around. All of this is transmitted to the rotor blade via the swashplate. The swash moves up and down for collective and tips forward/ back left/right for cyclic control.
The traditional method for controlling the swash is to have separate controls, or actuators for pitch, roll and collective and to mix them together with a mechanical mixing system. Every added linkage ads slop to the controls. The mechanical mixing systems add lots of slop. The acrobatic RC helicopter guys figured out that if you connect the servos directly to the swash plate, with no other linkages, things would be more precise. So they invented CCPM what it really means is that there are three servos spaced evenly around the swash plate at 120 degree intervals. If you want the swash to go straight up for a pure collective move then all three servos have to move straight up. If you want the swash to roll to the left, the rear servo stays still, the left goes down and the right goes up. It you want it to pitch nose up, the rear servo goes down and the left- right servos go up, but by half the amount. cos( 120 degrees/2). All of this is normally handled by some software in the RC transmitter. the way I'm currently flying is to just read the commanded positions and have the computer pass them through without modification. (Other than the rudder where I have compass heading hold working when commanded)
I really want to start working on the pitch, roll and collective controls. So rather than debug my mixing software at the same time as my controls software I split the beast in half. I'll tell the RC transmitter to treat the helicopter like it has mechanical mixing and have the software do the CCPM mixing on the helicopter.
Step 1) Backup ALL the software everywhere into a was_working_1_09_08 directory.
Step 2) remove the helicopter from the Lazy Susan and bring it inside to test.
Step 3) Modify the Telemetry display software so it shows servo pulse positions in counts rather than +/-100%
Step 4 )Run the existing system and record all the servo (right, left, rear) positions for:
Full down and Full up and neutral collective with neutral cyclic.
Full forward, Aft and neutral cyclic with neutral collective.
Step 5)Reprogram the transmitter to not do CCPM. *(requires downloading manual from JR website and reading a few pages)
Step 6)Record the servo count limits for Elevator, Aileron and Collective servos.
Step 7 )put all the numbers from step 4 and 6 into excel and see if the make sense. They do make sense. The scalings all look reasonable and linear.
Step 8) Reconfigure software to store received RC commands from the appropriate channels in Collective, Aileron and Elevator variables.
Step 9 )write code to translate these Collective, Aileron and Elevator variables into servo commands for left, right and rear. (remembering to limit check everything)
Step 10) Test the software.
I finished this at about 10:30, but by this time the helicopter had been running controls and telemetry non stop for 1.5 hours and the status indicators were giving me the controls battery too low indications. I still need to repeat step 4 with the new software to make sure my mapping is correct, but it looks good visually. I'll do that in the morning before I go to work.
It's currently 11:01 another evening gonI e. I have to stay up until the battery is done as I don't leave LiPos on a charger unattended. ( I wrote this entry while the battery was on the charger.)
I also need to go to bed. Its going to be a long day at work Thursday as my business partner and one of by best support engineers are going to CES to gawk at the 150 inch LCD screens.
This means I'll have to do a bit more than normal in both sales support and technical support.
Tuesday, January 08, 2008
What does it take...
My Son is currently working on an interesting business idea with some friends up in the bay area. So I'm currently working on the project solo. What does this mean?
I'll give you a brief rundown of just this evening. (A fairly typical evening.)
I got home from work about 5:45.
I usually sit down and have dinner with my wife and who ever is here.
My Wife is battling a cold (the one I had last week) so she was asleep so I heated up some soup in the microwave and watched the NH election returns while I ate dinner.
6:15 out to the garage.
I'm trying to get a handle on valves so I pull out all the sample valves and actuators I've collected to look at them. I think I want to concentrate on the brush less actuator and the Dynamixl actuators.
One of the possible valves is a cyro rated globe valve, but it takes multiple turns.
The torque of the brush less actuator is insane with the 256:1 gear box, but I need faster if I'm going to use a multi turn valve. So I remove the brushless motor from the 2656:1 and put it on the 36:1 gear box. This involves removing one very stubborn screw and machining two parts on the lathe. Elapsed time 2 hrs its now 8:15. On the 36:1 gearbox the brushless actuator is still stronger than I need. however the actuator speed is not symmetrical, the brush less controller still thinks its driving a car, not a servo. So go dig through the manuals files looking for the programming instructions for the Novak "goat" brush less controller. After decoding their programming scheme with 4 multicolor blinking lights and a single button I have the controller operating in servo mode. Still insanely strong and veryfast. It looks like a good possibility.
Next I move on to the next actuator, the Dynamixel RX-64.
I go to the computer and download and print the manual. I review the specs and discover that the claimed max torque is the same as the much bigger, beefier and heavier tonegowa, cool,
I knew it was good, but my mental model had it half that strong, My head stores data in a variety of units and I messed up the mental Kgcm to inoz conversion in making that assumption.
Now to make it work. Step one build a wiring harness, first problem the manual talks about 5 pins, the connectors and cables only have 4????
After some head scratching I see that the case and semi-hidden PCB have 5 pins, but the connector soldered in is only 4 pins. mystery solved. Get up from the computer go out to the garage and set up the soldering iron and heat shrink gun and make a nice cable.
Now what to connect the actuator to for testing? It needs RS-485 half duplex, so I dig through my NetBurner junk box and find a carrier board that supports RS-485 half duplex.
Next I dig up the schematic for the obsolete carrier board (The obsolete stuff comes home, the new stuff gets sold.) and wire up the RS-485. I haven't done any RS-485 programming in awhile, so I haul out the scope to make sure the enable disable timing is correct. It is,so
now I have to figure out what the default baud rate is. The dynamixel manual tries very hard to hide this important bit of information but I hunt it down. In a few more minutes I have the actuator exchanging packets with me and giving me its internal temperature and status.
I just can't seem to get it to move....
Alas I have to enable "torque" and realize that the internal position commands are of a different endian state than what I was passing. The actuator moves and I can command it back and forth. Its reasonably fast and seems very strong. Cool! that only took 2 additional hours.
So I spent in excess of 5 hours this evening and I accomplished:
Changed gearbox on a possible actuator.
Verified that the dynamixels do what they say they do.
Wrote up this blog entry.
I usually take one evening a week and go do something with my wife like go to a movie or play. I usually take one evening to just vegetate. Other than that I'm usually woring on the rocket project. Only 10 months til LLC 2008, not nearly enough time.
I'll give you a brief rundown of just this evening. (A fairly typical evening.)
I got home from work about 5:45.
I usually sit down and have dinner with my wife and who ever is here.
My Wife is battling a cold (the one I had last week) so she was asleep so I heated up some soup in the microwave and watched the NH election returns while I ate dinner.
6:15 out to the garage.
I'm trying to get a handle on valves so I pull out all the sample valves and actuators I've collected to look at them. I think I want to concentrate on the brush less actuator and the Dynamixl actuators.
One of the possible valves is a cyro rated globe valve, but it takes multiple turns.
The torque of the brush less actuator is insane with the 256:1 gear box, but I need faster if I'm going to use a multi turn valve. So I remove the brushless motor from the 2656:1 and put it on the 36:1 gear box. This involves removing one very stubborn screw and machining two parts on the lathe. Elapsed time 2 hrs its now 8:15. On the 36:1 gearbox the brushless actuator is still stronger than I need. however the actuator speed is not symmetrical, the brush less controller still thinks its driving a car, not a servo. So go dig through the manuals files looking for the programming instructions for the Novak "goat" brush less controller. After decoding their programming scheme with 4 multicolor blinking lights and a single button I have the controller operating in servo mode. Still insanely strong and veryfast. It looks like a good possibility.
Next I move on to the next actuator, the Dynamixel RX-64.
I go to the computer and download and print the manual. I review the specs and discover that the claimed max torque is the same as the much bigger, beefier and heavier tonegowa, cool,
I knew it was good, but my mental model had it half that strong, My head stores data in a variety of units and I messed up the mental Kgcm to inoz conversion in making that assumption.
Now to make it work. Step one build a wiring harness, first problem the manual talks about 5 pins, the connectors and cables only have 4????
After some head scratching I see that the case and semi-hidden PCB have 5 pins, but the connector soldered in is only 4 pins. mystery solved. Get up from the computer go out to the garage and set up the soldering iron and heat shrink gun and make a nice cable.
Now what to connect the actuator to for testing? It needs RS-485 half duplex, so I dig through my NetBurner junk box and find a carrier board that supports RS-485 half duplex.
Next I dig up the schematic for the obsolete carrier board (The obsolete stuff comes home, the new stuff gets sold.) and wire up the RS-485. I haven't done any RS-485 programming in awhile, so I haul out the scope to make sure the enable disable timing is correct. It is,so
now I have to figure out what the default baud rate is. The dynamixel manual tries very hard to hide this important bit of information but I hunt it down. In a few more minutes I have the actuator exchanging packets with me and giving me its internal temperature and status.
I just can't seem to get it to move....
Alas I have to enable "torque" and realize that the internal position commands are of a different endian state than what I was passing. The actuator moves and I can command it back and forth. Its reasonably fast and seems very strong. Cool! that only took 2 additional hours.
So I spent in excess of 5 hours this evening and I accomplished:
Changed gearbox on a possible actuator.
Verified that the dynamixels do what they say they do.
Wrote up this blog entry.
I usually take one evening a week and go do something with my wife like go to a movie or play. I usually take one evening to just vegetate. Other than that I'm usually woring on the rocket project. Only 10 months til LLC 2008, not nearly enough time.
Monday, January 07, 2008
Valves....
If I stay with the four engine system the Swagelock plug valves are almost perfect for pressurization and fuel. (Won't work for Lox they freeze) One is shown below next to two dynamixel actuators.
These dynamixel actuators are robot servos with a an RS-485 interface will full feedback. The normal model servo interface does not offer any feedback about the torque, actual position temperature etc... One of the test stand reliability issues was that we were never 100% sure that the valve went where commanded, these actuators fix that problem. I've ordered some zero backlash couplers and when they come in I will mount the dynamixel opposite the plug valve and test the combination.
When we get to the point of flying to significant altitudes the brushed motors in these actuators and all standard model/robot servos are not acceptable. brushed motors have arcing problems at high altitude. So we have been testing a sensored brush less motor with a planetary gearbox and a ball valve. This may become the Lox valve for our system. I'm also looking at a small brush less motor as a replacement for the Tonegowa main motors. Below is a "teamnovak" brush less crawler motor attached to a bane bot gearbox and a 3 pc ball valve. This combination has an insane amount of torque and very precise control.
Controls/Helicopter.
I finally have the necessary sensors on the helicopter working 100% reliably in flight. The last item was to do a 3D hard iron calibration of the microstrain IMU so it would sense magnetic heading correctly. I've evaluate three sources of magnetic heading on the helicopter: (All three are still mounted)
1)The Crescent Vector two antenna GPS. With the 2nd antenna near the helicopter blades its very unreliable with the blades turning. The primary GPS info is fine, the 2nd RTK solution for heading is not very reliable, its almost useless.
2)The Ocean systems magnetic compass module out on the tail boom. Works fine when things are static, but seems very sensitive to vibration and acceleration.
3)The Microstrain IMU. After recalibrating the unit with all the electronics turned on and the blades spinning it works great. I just need to recalibrate after any configuration changes.
This will be the heading solution long term, its the best and seems to be the most reliable.
After getting the sensors working we started working on controlling things automatically. The first control to go under automatic control is heading. To test just heading I built rotary table I can run the helicopter on. Its is a lazy susan bearing between two pieces of plywood with the helicopter tie wrapped to some screwed down brackets (shown bellow)
This allowed me to quickly test my heading control code and get the system gains right in less than an hour. The weather in San Diego was such that I could not really fly this weekend, so I have yet to try the heading code in flight, but it works really well on the lazy susan. It yaws to true north when commanded at a fast but steady rate and holds that position when perturbed.
The data collection shows a tiny bit of overshoot when comming from more than 45 degrees away, but all in all I'm happy with it. the next control step will be to close the loop around commanded attitude using the RC system to command attitude and the IMU to measure attitude. That is my goal for this coming weekend.
If I stay with the four engine system the Swagelock plug valves are almost perfect for pressurization and fuel. (Won't work for Lox they freeze) One is shown below next to two dynamixel actuators.
These dynamixel actuators are robot servos with a an RS-485 interface will full feedback. The normal model servo interface does not offer any feedback about the torque, actual position temperature etc... One of the test stand reliability issues was that we were never 100% sure that the valve went where commanded, these actuators fix that problem. I've ordered some zero backlash couplers and when they come in I will mount the dynamixel opposite the plug valve and test the combination.
When we get to the point of flying to significant altitudes the brushed motors in these actuators and all standard model/robot servos are not acceptable. brushed motors have arcing problems at high altitude. So we have been testing a sensored brush less motor with a planetary gearbox and a ball valve. This may become the Lox valve for our system. I'm also looking at a small brush less motor as a replacement for the Tonegowa main motors. Below is a "teamnovak" brush less crawler motor attached to a bane bot gearbox and a 3 pc ball valve. This combination has an insane amount of torque and very precise control.
Controls/Helicopter.
I finally have the necessary sensors on the helicopter working 100% reliably in flight. The last item was to do a 3D hard iron calibration of the microstrain IMU so it would sense magnetic heading correctly. I've evaluate three sources of magnetic heading on the helicopter: (All three are still mounted)
1)The Crescent Vector two antenna GPS. With the 2nd antenna near the helicopter blades its very unreliable with the blades turning. The primary GPS info is fine, the 2nd RTK solution for heading is not very reliable, its almost useless.
2)The Ocean systems magnetic compass module out on the tail boom. Works fine when things are static, but seems very sensitive to vibration and acceleration.
3)The Microstrain IMU. After recalibrating the unit with all the electronics turned on and the blades spinning it works great. I just need to recalibrate after any configuration changes.
This will be the heading solution long term, its the best and seems to be the most reliable.
After getting the sensors working we started working on controlling things automatically. The first control to go under automatic control is heading. To test just heading I built rotary table I can run the helicopter on. Its is a lazy susan bearing between two pieces of plywood with the helicopter tie wrapped to some screwed down brackets (shown bellow)
This allowed me to quickly test my heading control code and get the system gains right in less than an hour. The weather in San Diego was such that I could not really fly this weekend, so I have yet to try the heading code in flight, but it works really well on the lazy susan. It yaws to true north when commanded at a fast but steady rate and holds that position when perturbed.
The data collection shows a tiny bit of overshoot when comming from more than 45 degrees away, but all in all I'm happy with it. the next control step will be to close the loop around commanded attitude using the RC system to command attitude and the IMU to measure attitude. That is my goal for this coming weekend.
Tuesday, December 18, 2007
Other Projects life and the Helicopter.
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!
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!
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.
Tuesday, November 27, 2007
Tank and Helicopter Testing.
Today at lunch I flew the helicopter again and I seem to have solved all the electronics glitches. I changed from a 72Mhz RC Rx to one of the new 2.4Ghz units and it was much smoother. I'll analyze the recorded telemetry in the next day or so and post the results.
This afternoon my son started hydro testing all of the vehicle tanks. We had planed to test the entire vehicle with plumbing and everything, but with recent tank failures on the test stand and our sample heat treated tank we decided to individually test the vehicle tanks. The tanks were designed to be hydroed to 500PSI. However for the 90 second vehicle we did not ned to go so high. We backed off to 450PSI and still did not fair well. We tested all 8 tanks and got the following results: Failures at 350, 385,415 and 435. Four tanks passed all the way to 455. Since thanks are welded together in pairs we have one good pair, that will go on the test stand. The rest of the vehicle tanks are probably scrap. All four tanks failed in exactly the same way, at the interface between the endcap and the tubular tank. The weld stayed attached to the end cap and the weld pulled away from or failed at the tubular part of the tank. The tubular part is 6063 and the end cap 6061 so this failure mode sort of makes sense.
This result really complicates the decision process. What do we have from last years effort? We have 1/4 of a vehicle tank. We have some structure. We don't have valves, plumbing electronics we can use. We think (confidence 80%) that we have motors that will work. Do we scrap the design for a simpler solution or do we fix what we know is broken? There is a strong desire to start over from scratch. If I were to start again I think I'd build a 3/4 scale pixel. However this would mean scrapping the one part we think we have working the motor. Arghhhh decisions and only 11 months to be ready.
This afternoon my son started hydro testing all of the vehicle tanks. We had planed to test the entire vehicle with plumbing and everything, but with recent tank failures on the test stand and our sample heat treated tank we decided to individually test the vehicle tanks. The tanks were designed to be hydroed to 500PSI. However for the 90 second vehicle we did not ned to go so high. We backed off to 450PSI and still did not fair well. We tested all 8 tanks and got the following results: Failures at 350, 385,415 and 435. Four tanks passed all the way to 455. Since thanks are welded together in pairs we have one good pair, that will go on the test stand. The rest of the vehicle tanks are probably scrap. All four tanks failed in exactly the same way, at the interface between the endcap and the tubular tank. The weld stayed attached to the end cap and the weld pulled away from or failed at the tubular part of the tank. The tubular part is 6063 and the end cap 6061 so this failure mode sort of makes sense.
This result really complicates the decision process. What do we have from last years effort? We have 1/4 of a vehicle tank. We have some structure. We don't have valves, plumbing electronics we can use. We think (confidence 80%) that we have motors that will work. Do we scrap the design for a simpler solution or do we fix what we know is broken? There is a strong desire to start over from scratch. If I were to start again I think I'd build a 3/4 scale pixel. However this would mean scrapping the one part we think we have working the motor. Arghhhh decisions and only 11 months to be ready.
Sunday, November 18, 2007
Back in the swing
Starting to get back into it. I made some sugar rocket parts for Kevin of FAR on the Lathe. This generated a bunch of aluminum chips that swiftly made their way into the house. Since I'm trying to reduce the amount of $$ spent on the
"Calm angry wife with aluminum chip in her foot by purchasing flowers"
budget line item.
I've decided that the lathe needs to move away from the exit door. I can do this by swapping the lathe and a work bench. So next week I need to move some power wiring and add another layer of waterproof sheet rock and or stainless steel sheeting behind the lathes new home. I'm also going to install a troll at the exit door whose job is to throw you to the ground and remove all the metal chips. If you know anyone marketing such a creature please let me know.
On a slightly less serious note I flew the helicopter a number of times on Saturday and all the electronics seem to be working.I've got GPS, IMU, Ultrasonic altitude sensor, compass, RC receiver,telemetry transceiver and netburner cpu all running on an electric Trex 600. I finally solved the GPS problem by moving it to the end of the tail boom. It is all functional, with the current setup the RC receiver is hooked to the CPU and the servos are all driven by the CPU. Right now the CPU just echoes the RC receiver commands and the vehicle is flown manually, but it proves out all the hardware. These tests included the ground telemetry box and RF to Ethernet translator I was showing at the xprize cup. There were a bunch of guys at FAR for a solid motor class and one of them captured me flying the helicopter.
"Calm angry wife with aluminum chip in her foot by purchasing flowers"
budget line item.
I've decided that the lathe needs to move away from the exit door. I can do this by swapping the lathe and a work bench. So next week I need to move some power wiring and add another layer of waterproof sheet rock and or stainless steel sheeting behind the lathes new home. I'm also going to install a troll at the exit door whose job is to throw you to the ground and remove all the metal chips. If you know anyone marketing such a creature please let me know.
On a slightly less serious note I flew the helicopter a number of times on Saturday and all the electronics seem to be working.I've got GPS, IMU, Ultrasonic altitude sensor, compass, RC receiver,telemetry transceiver and netburner cpu all running on an electric Trex 600. I finally solved the GPS problem by moving it to the end of the tail boom. It is all functional, with the current setup the RC receiver is hooked to the CPU and the servos are all driven by the CPU. Right now the CPU just echoes the RC receiver commands and the vehicle is flown manually, but it proves out all the hardware. These tests included the ground telemetry box and RF to Ethernet translator I was showing at the xprize cup. There were a bunch of guys at FAR for a solid motor class and one of them captured me flying the helicopter.
Monday, November 12, 2007
Tanks, good news bad news...
We originally hydroed one tank to failure. It failed at 495 PSI.
We made the end cap that failed thicker, and assumed we fixed the problem.
Today I asked my son to hydro the test stand to 500 PSI since we had not done so. The first tank in the test stand failed at 475. He then hydro tested the tank we had heat treated. It failed at 425. So to complete the set we tested the other tank on the test stand to failure it failed at 560PSI. All three failed in exactly the same spot in the weld between the end cap and tank end. Its clear that our quality control needs some work. On Tuesday we will hydro all 8 tanks on the actual vehicle and see how that goes. Its really hard to tell if the failure is in the heat effected zone on the margin next to the weld, or if the welds them selves are too thin.
We made the end cap that failed thicker, and assumed we fixed the problem.
Today I asked my son to hydro the test stand to 500 PSI since we had not done so. The first tank in the test stand failed at 475. He then hydro tested the tank we had heat treated. It failed at 425. So to complete the set we tested the other tank on the test stand to failure it failed at 560PSI. All three failed in exactly the same spot in the weld between the end cap and tank end. Its clear that our quality control needs some work. On Tuesday we will hydro all 8 tanks on the actual vehicle and see how that goes. Its really hard to tell if the failure is in the heat effected zone on the margin next to the weld, or if the welds them selves are too thin.
Support the troups.
Every year for the last 6 years I've supported http://www.lbeh.org/
Its an effort to buy plane tickets for enlisted men and women to allow them to fly home for the holidays. Its an all volunteer's effort last year they spent 96% of what was donated on the troops.
(2.5 % of the take went to PayPal fees.)
This is the one and only time of the year I'll post a request on the blog.
Its an effort to buy plane tickets for enlisted men and women to allow them to fly home for the holidays. Its an all volunteer's effort last year they spent 96% of what was donated on the troops.
(2.5 % of the take went to PayPal fees.)
This is the one and only time of the year I'll post a request on the blog.
Sunday, November 11, 2007
Valves, Valves,Valves and Valves...
We started this project last year looking for light weight actuators. We assumed that we could just use off the shelf ball valves.
When we sit down and evaluate the response time needed and the hysterisis of ball valves then we realize that in the small sizes we need ball valves are problematic. There is slop between the ball and the stem and rotationally the ball valve is not very linear. We have also had leak and wear problems with our ball valves. So given the actuator we like we are now trying to find a better valve to go under it. Today we manually tested the following valves with 200 PSI liquid nitrogen:
Large O2 rated solenoid. (Cryogenic solenoids are larger and heaver)
Failed stuck open.
Buttery fly valve we were using as a throttling vale as the only valve.
Failed Leaking, very very non-linear.
SwageLoc Plug valve with 4 different kinds of alternate o-rings including
$70.00 of Kalrez o-rings.
All rotating seals failed at Ln2 Temperatures.
Small Brass Ball Valve.
Froze Solid and Jammed.
Small SS Ball valve.
Worked, sealed and had signiifcantly more hysteresis at LN2 temps than at room temperature.
For my next bout of insanity Paul builds a valve....
This is my "Simple" custom valve idea. I build a small linear valve in a copper plumbing tee. Making cryogenic seals work is hard, so I cheat. I add some heat to the end of the thin wall stainless to keep the seal end warm. The force necessary to operate this valve is within the range of the small fast robot servos I've been using. the valve is operated by pulling the stainless rod in and out. The Cage pins are there to make the ball stay in place. I'm concerned that the flow will make the ball chatter. If the seals give me trouble I can go to an electroformed bellows.
From Servometer
This makes me wonder if I should try a stock off the shelf.... bellows valve
When we sit down and evaluate the response time needed and the hysterisis of ball valves then we realize that in the small sizes we need ball valves are problematic. There is slop between the ball and the stem and rotationally the ball valve is not very linear. We have also had leak and wear problems with our ball valves. So given the actuator we like we are now trying to find a better valve to go under it. Today we manually tested the following valves with 200 PSI liquid nitrogen:
Large O2 rated solenoid. (Cryogenic solenoids are larger and heaver)
Failed stuck open.
Buttery fly valve we were using as a throttling vale as the only valve.
Failed Leaking, very very non-linear.
SwageLoc Plug valve with 4 different kinds of alternate o-rings including
$70.00 of Kalrez o-rings.
All rotating seals failed at Ln2 Temperatures.
Small Brass Ball Valve.
Froze Solid and Jammed.
Small SS Ball valve.
Worked, sealed and had signiifcantly more hysteresis at LN2 temps than at room temperature.
For my next bout of insanity Paul builds a valve....
This is my "Simple" custom valve idea. I build a small linear valve in a copper plumbing tee. Making cryogenic seals work is hard, so I cheat. I add some heat to the end of the thin wall stainless to keep the seal end warm. The force necessary to operate this valve is within the range of the small fast robot servos I've been using. the valve is operated by pulling the stainless rod in and out. The Cage pins are there to make the ball stay in place. I'm concerned that the flow will make the ball chatter. If the seals give me trouble I can go to an electroformed bellows.
From Servometer
This makes me wonder if I should try a stock off the shelf.... bellows valve
Thursday, November 08, 2007
Wednesday, November 07, 2007
The most common misconception.
I've had at least 50 people tell me the following:
(Including more than one scientist with a hard science PHD)
Why not put your rocket engine on top so the vehicle will be naturally stable.
This is wrong. It jives with our natural experience of the world, but it is wrong.
A rocket has no natural preference for thrusting UP. The rocket will thrust in whatever direction you point it. This is unusual in out natural experience. It you hang something on a rope the rope has the natural tendency to dangle straight down and only apply force in the up direction. If you attach something to a balloon the balloon only pulls straight up.
So given that the rocket will thrust in whatever direction its pointed and has no natural tendency to point up the rocket can't add any stability.
So if the motor can't add stability is there anything you can do for gravity to add stability? If the gravity field was uniform it would operate on the center of mass appling no torque to the vehicle and thus no stability. On the surface of the earth this is basically the case. The gravity field varies with the square of the radius. In orbit this slight difference can be used to stabilize a spacecraft, but on the surface the effect is so slight as to be undetectable. (On a 2meter high object gravity is 0.999999969 as strong on the top as it is on the bottom)
Our intuition is not completely wrong with respect to where the rocket motor goes, if it's center of thrust is not pointing through the center of mass then the rocket engine will apply a torque and the vehicle will spin. The current unreasonable rocket design has four engines that must be balanced to keep the vehicle from spinning, so in this sense a single rocket motor pointing toward the center of mass would keep the rocket pointed in a constant direction, but that direction would not be preferentially up without some kind of external control.
(Including more than one scientist with a hard science PHD)
Why not put your rocket engine on top so the vehicle will be naturally stable.
This is wrong. It jives with our natural experience of the world, but it is wrong.
A rocket has no natural preference for thrusting UP. The rocket will thrust in whatever direction you point it. This is unusual in out natural experience. It you hang something on a rope the rope has the natural tendency to dangle straight down and only apply force in the up direction. If you attach something to a balloon the balloon only pulls straight up.
So given that the rocket will thrust in whatever direction its pointed and has no natural tendency to point up the rocket can't add any stability.
So if the motor can't add stability is there anything you can do for gravity to add stability? If the gravity field was uniform it would operate on the center of mass appling no torque to the vehicle and thus no stability. On the surface of the earth this is basically the case. The gravity field varies with the square of the radius. In orbit this slight difference can be used to stabilize a spacecraft, but on the surface the effect is so slight as to be undetectable. (On a 2meter high object gravity is 0.999999969 as strong on the top as it is on the bottom)
Our intuition is not completely wrong with respect to where the rocket motor goes, if it's center of thrust is not pointing through the center of mass then the rocket engine will apply a torque and the vehicle will spin. The current unreasonable rocket design has four engines that must be balanced to keep the vehicle from spinning, so in this sense a single rocket motor pointing toward the center of mass would keep the rocket pointed in a constant direction, but that direction would not be preferentially up without some kind of external control.
Monday, November 05, 2007
The Agony of the valves.
After spending a few days at XPC it's very clear that our system is too complex.
KISS Keep It Simple Stupid.
The temptation is very great to start over from scratch and redesign everything. If I were to start again I would design something that looks a lot like pixel or the Armadillo Quad, a Single engine. The counter to this is that the only thing we really need to finish our vehicle is fast robust reliable valves. Its always tempting to trade the devil you know for the invisible devil lying in the green grass on the other side of the fence. Everyone I've talked to in Alt space has had valve problems of one kind or another.
My core problem is that I need very fast (50 to 100msec) control of the engine thrust to maintain reliable attitude control. Our vehicle is relatively small so that it's overall rotational inertia is low, and the motors are on the very outside of the vehicle this combines to require fast/precise control of the motor thrust.
How fast?
We can do some freshman physics and figure that out.
Lets assume that the vehicle is 2m diameter sphere.
(This is a slightly pessimistic view of our inertia the vehicle will be more stable than this)
I=2 mr^2/5 =2m/5
We are hovering with 4 motors. The total required lift is mg
So the force for each motor is mg/4
The motors are thrusting on a 1 meter lever arm from the Cg.
Now assume we can very the thrust in 1% steps around nominal.
Assume we increase the thrust in one motor by 1% and decrease the opposite motor by 1%
torque=1 * 2%mg/4
angular acceleration alpha=torque /I =(1*0.02mg/4)/(2m/5)
alpha = 0.0125g (notice m drops out)
or assuming g=9.8m/sec
alpha = .1225 radians/sec ^2
If we want 1 degree control of the vehicle 1 degree = 0.01745 radians.
The rotation is just like linear acceleration angle = (alpha*t^2)/2
So for 1% motor change a 1 degree error occurs in t=.53 seconds.
We would like our control to be about 5x to 10x the speed hence we need a 50msec valve.
How do we get such fast control:
Monster actuators and normal ball valves.
Pros:
95% Off the shelf.
Cons:
Lots of hysteresis (3 to 5%), Seals wear out quickly.
Hysteresis really complicates the control system.
Voice coil driven piloted spool valves.
Pros:
Such things exist for Hydraulic systems.
Control response as fast as 15msec 0 to 100%
Hysteresis 0.1% Basically a perfect valve.
Cons:
No off the shelf valves will work for LOX
Heavy
Expensive.
Serious engineering effort to build such a valve in a Lox compatible way.
More complicated Odd combinations.
One can start doing things that add significant complexity:
Adding modulated water injection.
Modulating just the fuel supply while leaving the LOX on a slow actuator.
Using a pile of fast solenoid valves
One fast Solenoid valve as trim with Slow ball valve following.
Pros:
Potentially the lowest cost option.
Cons:
Violates KISS
Requires a lot of development testing.
I'm sure I'll post more on this in the coming days and weeks.
KISS Keep It Simple Stupid.
The temptation is very great to start over from scratch and redesign everything. If I were to start again I would design something that looks a lot like pixel or the Armadillo Quad, a Single engine. The counter to this is that the only thing we really need to finish our vehicle is fast robust reliable valves. Its always tempting to trade the devil you know for the invisible devil lying in the green grass on the other side of the fence. Everyone I've talked to in Alt space has had valve problems of one kind or another.
My core problem is that I need very fast (50 to 100msec) control of the engine thrust to maintain reliable attitude control. Our vehicle is relatively small so that it's overall rotational inertia is low, and the motors are on the very outside of the vehicle this combines to require fast/precise control of the motor thrust.
How fast?
We can do some freshman physics and figure that out.
Lets assume that the vehicle is 2m diameter sphere.
(This is a slightly pessimistic view of our inertia the vehicle will be more stable than this)
I=2 mr^2/5 =2m/5
We are hovering with 4 motors. The total required lift is mg
So the force for each motor is mg/4
The motors are thrusting on a 1 meter lever arm from the Cg.
Now assume we can very the thrust in 1% steps around nominal.
Assume we increase the thrust in one motor by 1% and decrease the opposite motor by 1%
torque=1 * 2%mg/4
angular acceleration alpha=torque /I =(1*0.02mg/4)/(2m/5)
alpha = 0.0125g (notice m drops out)
or assuming g=9.8m/sec
alpha = .1225 radians/sec ^2
If we want 1 degree control of the vehicle 1 degree = 0.01745 radians.
The rotation is just like linear acceleration angle = (alpha*t^2)/2
So for 1% motor change a 1 degree error occurs in t=.53 seconds.
We would like our control to be about 5x to 10x the speed hence we need a 50msec valve.
How do we get such fast control:
Monster actuators and normal ball valves.
Pros:
95% Off the shelf.
Cons:
Lots of hysteresis (3 to 5%), Seals wear out quickly.
Hysteresis really complicates the control system.
Voice coil driven piloted spool valves.
Pros:
Such things exist for Hydraulic systems.
Control response as fast as 15msec 0 to 100%
Hysteresis 0.1% Basically a perfect valve.
Cons:
No off the shelf valves will work for LOX
Heavy
Expensive.
Serious engineering effort to build such a valve in a Lox compatible way.
More complicated Odd combinations.
One can start doing things that add significant complexity:
Adding modulated water injection.
Modulating just the fuel supply while leaving the LOX on a slow actuator.
Using a pile of fast solenoid valves
One fast Solenoid valve as trim with Slow ball valve following.
Pros:
Potentially the lowest cost option.
Cons:
Violates KISS
Requires a lot of development testing.
I'm sure I'll post more on this in the coming days and weeks.
Wednesday, October 31, 2007
Unreasonable Plans
I enjoyed visiting with all the people that stopped by to visit at the Xprize cup.
It was really heartbreaking that Armadillo did not win anything. Watching this unfold shows how hard this problem really is and makes me realize how very far from being ready we really are. I've been trying to work up a plan of action for the next year and the rough outline looks something like this:
1)Start working on the command and control code on the Helicopter to get the telemetry and mission planning stuff out of the way. This can be done close to home without the major expedition aspects of going out to FAR. Id like to have this 100% resolved by Christmas.
2)Work on resolving my valve issues, this will probably be one of the following:
3)Resurrect the test stand even if it means making new tanks and resolving our engine igntion issues once and for all. Before we do any vehicle work I want to run a motor on the test stand with throttling and simulate a full LLC mission including the 30 minute turnaround. I want to do this over and over until we get it right. This may get as involved as developing a new injector and igniter design. I'd like to start this testing in January.
4)Once 1,2,3 are done rebuild the vehicle and start tethered testing. If all goes well I could see tethered testing as soon as Febuary 1 ~ 4 months from now. After watching Armadillo I know I want to make some architectural changes. The primary one will be for the vehicle to automatically test all its valve actuators and sensors with minimal human intervention.
When I get to the point of testing a full vehicle I need to find a different transportation method. I'd be inclinded to buy a used flatbed or Box truck, but I can't park that near me, so I'd need to find someplace in San Diego to park it without spending a fortune. Anyone with an empty lot in San Diego where I can park a 20' box truck off and on for a year?
It was really heartbreaking that Armadillo did not win anything. Watching this unfold shows how hard this problem really is and makes me realize how very far from being ready we really are. I've been trying to work up a plan of action for the next year and the rough outline looks something like this:
1)Start working on the command and control code on the Helicopter to get the telemetry and mission planning stuff out of the way. This can be done close to home without the major expedition aspects of going out to FAR. Id like to have this 100% resolved by Christmas.
2)Work on resolving my valve issues, this will probably be one of the following:
- Rework the tonegowa driven valves for less backlash and better electronics. (Open servo based?) This is my preference.
- Use higher pressure Butterfly valves as the sole valve. This is my sons preference.
- Design a custom valve using either rotary or poppet style valves. This is no-ones preference. (I'm thinking a bearing supported plug valve sort of like this)
3)Resurrect the test stand even if it means making new tanks and resolving our engine igntion issues once and for all. Before we do any vehicle work I want to run a motor on the test stand with throttling and simulate a full LLC mission including the 30 minute turnaround. I want to do this over and over until we get it right. This may get as involved as developing a new injector and igniter design. I'd like to start this testing in January.
4)Once 1,2,3 are done rebuild the vehicle and start tethered testing. If all goes well I could see tethered testing as soon as Febuary 1 ~ 4 months from now. After watching Armadillo I know I want to make some architectural changes. The primary one will be for the vehicle to automatically test all its valve actuators and sensors with minimal human intervention.
When I get to the point of testing a full vehicle I need to find a different transportation method. I'd be inclinded to buy a used flatbed or Box truck, but I can't park that near me, so I'd need to find someplace in San Diego to park it without spending a fortune. Anyone with an empty lot in San Diego where I can park a 20' box truck off and on for a year?
Tuesday, October 23, 2007
Good Luck to Armadillo
I will be leaving for Holloman some time Wednesday afternoon.
Before I go I want to wish armadillo the best of luck in their NG-LLC efforts.
I will be rooting for them!
They have worked very hard and have been a real class act.
Good luck to John and the rest of the Armadillo team!
Before I go I want to wish armadillo the best of luck in their NG-LLC efforts.
I will be rooting for them!
They have worked very hard and have been a real class act.
Good luck to John and the rest of the Armadillo team!
Long night we are ok...
The wind switched directions and it looks like the witch fire will not reach the coast. Our thoughts are with the 500,000 people that have been evacuated and don't know the status of their homes. It looks like 1200+ homes have been destroyed in the last 36 hours. There are still areas in San Deigo county where people are still losing homes. If the wind switches we could still be at risk, but
it looks 200% better than is did 24 hours ago.
it looks 200% better than is did 24 hours ago.
Monday, October 22, 2007
San Diego fires
We live in Solana Beach, the city has just said
"Everyone is being asked to plan, pack and evacuate ahead of
being required to do so. "
It looks like the witch creek fire is likely going to burn all the way to the coast. Where it crosses I5 and hits the coast is pretty much up in the air. It looks like its going to cross somewhere near our house +/- 5 miles. We live in a fairly dense residential neighborhood, if it gets to us this fire is going to be a truely note worthy disaster. I'm going home from work to join the rest of the family and get prepared to leave. It probably won't be to the coast for another 12-18 hours , but it looks like nothing is going to stop it. Wish us luck, we hope to see all of you this coming weekend at Holloman. I'll let everyone know how it turns out Tuesday.
Paul
"Everyone is being asked to plan, pack and evacuate ahead of
being required to do so. "
It looks like the witch creek fire is likely going to burn all the way to the coast. Where it crosses I5 and hits the coast is pretty much up in the air. It looks like its going to cross somewhere near our house +/- 5 miles. We live in a fairly dense residential neighborhood, if it gets to us this fire is going to be a truely note worthy disaster. I'm going home from work to join the rest of the family and get prepared to leave. It probably won't be to the coast for another 12-18 hours , but it looks like nothing is going to stop it. Wish us luck, we hope to see all of you this coming weekend at Holloman. I'll let everyone know how it turns out Tuesday.
Paul
Friday, October 19, 2007
Unreasonable Ideas
For awhile I've been contemplating making some personal or political posts on this blog. I don't really want to mix the messages that way. Today I started a new blog unreasonableideas with a sad personal note. I'll continue posting rocket stuff here, and I'll post personal stuff there.
Wednesday, October 10, 2007
We will be displaying at XPC.
I've been having an internal debate about coming to the Xprize cup as an exhibitor or strictly as an observer. Unlike the other teams that are are looking to raise capital and awareness, we are not yet trying to do that. So I was hesitant to spend the money necessary to transport stuff to the show. I've decided that it would serve my larger goals of showing that small teams and individuals can do significant things in "space development" so we will be there.
We will be bringing the complete vehicle minus some valves and plumbing.
We may also bring the test stand carcass, the test helicopter, and and a video display. If you are coming to the show stop by and say hi.
On a personal note I went to the Plaster Blaster event last Saturday and spent the day watching a huge array of people launch rockets of all shapes and sizes. It was my first trip to a high power rocket event. The Xwing (http://rocketdungeon.blogspot.com/2007/10/empire-struck-back-may-x-wing-rip.html)was very cool, but all in all I found the event somewhat depressing. There were several cool projects, but none of the projects seemed to be advancing the state of the art. In some ways it seemed like a conspicuous consumption event. To be fair I saw a lot of families there and that was a very cool aspect to the event. My wife chastised me for this attitude, and said who am I to be judging other peoples efforts. She is probably right.
Lastly I've not done ANY thing on the rocket in the last month, I needed the break. I've been trying to catch up at work, organize my office and play some video games... (online chess and replaying all the original starcraft scenarios.)
We will be bringing the complete vehicle minus some valves and plumbing.
We may also bring the test stand carcass, the test helicopter, and and a video display. If you are coming to the show stop by and say hi.
On a personal note I went to the Plaster Blaster event last Saturday and spent the day watching a huge array of people launch rockets of all shapes and sizes. It was my first trip to a high power rocket event. The Xwing (http://rocketdungeon.blogspot.com/2007/10/empire-struck-back-may-x-wing-rip.html)was very cool, but all in all I found the event somewhat depressing. There were several cool projects, but none of the projects seemed to be advancing the state of the art. In some ways it seemed like a conspicuous consumption event. To be fair I saw a lot of families there and that was a very cool aspect to the event. My wife chastised me for this attitude, and said who am I to be judging other peoples efforts. She is probably right.
Lastly I've not done ANY thing on the rocket in the last month, I needed the break. I've been trying to catch up at work, organize my office and play some video games... (online chess and replaying all the original starcraft scenarios.)
Wednesday, September 19, 2007
400 Days till XPC 2008
I will boldly predict that there will be NG-LLC prize money for 2008. We only have ~400 days until the 2008 XPC, 280 days till the FAA permit app must be accepted. What are our plans? In no particular order...
1)Simplify.
Make one valve work, not two,
Go to blow down pressurization (for at least the 90 sec vehicle.)
2)Add more diagnostic automation.
Add some more feedback to the open loop vales so we can automagically determine their health.We need both position and current feedback from each valve. I may convert the valves to www.openservo.org derived control electronics.
3)Build a more robust vehicle.
Most plumbing, stainless not aluminum.
sturdier landing gear.
4)Find a more benign transport system.
5)Try other fuels and gasses
IPA (cleaner) and E85 cheaper.
Do at least one burn with 100% Nitrogen pressurization.
With our long thin tanks it might not be as bad as it is for Carmacks Spherical tanks. I've been told that a shot of He followed by N2 pressurization is not bad. the Russians use Nitrogen to pressurize their Lox tanks, and Nitrogen is a Lot Lot Lot cheaper than Hydrogen.
(Self presurized Lox might be similar....)
7)Put better data logging software in place.
( I write embedded S/W for a living and the shoemakers kids have no shoes.)
8)Convert the simulator to a hardware in loop tester.
9)Make the control system fly the helicopter, and publish ALL the results.
10)Try a impinging injector rather than a pintile.
11)Try Charles Pooleys Lox pre-burner idea.
12)Build and leave set up a good valve and injector flow test setup.
1)Simplify.
Make one valve work, not two,
Go to blow down pressurization (for at least the 90 sec vehicle.)
2)Add more diagnostic automation.
Add some more feedback to the open loop vales so we can automagically determine their health.We need both position and current feedback from each valve. I may convert the valves to www.openservo.org derived control electronics.
3)Build a more robust vehicle.
Most plumbing, stainless not aluminum.
sturdier landing gear.
4)Find a more benign transport system.
5)Try other fuels and gasses
IPA (cleaner) and E85 cheaper.
Do at least one burn with 100% Nitrogen pressurization.
With our long thin tanks it might not be as bad as it is for Carmacks Spherical tanks. I've been told that a shot of He followed by N2 pressurization is not bad. the Russians use Nitrogen to pressurize their Lox tanks, and Nitrogen is a Lot Lot Lot cheaper than Hydrogen.
(Self presurized Lox might be similar....)
7)Put better data logging software in place.
( I write embedded S/W for a living and the shoemakers kids have no shoes.)
8)Convert the simulator to a hardware in loop tester.
9)Make the control system fly the helicopter, and publish ALL the results.
10)Try a impinging injector rather than a pintile.
11)Try Charles Pooleys Lox pre-burner idea.
12)Build and leave set up a good valve and injector flow test setup.
Monday, September 17, 2007
Quick Update on LLC 2007
Since I posted my Out of Time post, a couple of teams have
announced to the world what they had told me in private.
Acuity:
Very Secret I know almost nothign about their progress. They had an unflown vehicle at the 2006 XPC, they could be the dark horse. They have an interesting control scheme that always made me wonder.
Armadillo:
As ready as anyone could be, the "Gold Standard"
Bon Nova:
They have posted a couple of very quick Rocket Motor videos, the longest being several seconds. We posted our 106 Second firing in April and we did not make it. They have posted no vehicle hardware pictures.
Masten:
They just announced on their blog they are out for 2007.
Micro space:
Failed to attend the required team meeting in Aug.
Paragon Labs:
They have a very credible vehicle, well constructed and professional Another team that is somewhat secretive and an unknown. They posted finished airframe and rocket firing pictures in Aug. They were planning to have throttling via movable pintile in the all aluminum motor, while technically very cool, not easy to do and Armadillo was never able to make an all aluminum motor last without melting.
Speed Up:
Announced that they will not make 2007.
Unreasonable Rocket:
Announced we will not make it in 2007.
Team X :
Pulled out before the Last team summit.
announced to the world what they had told me in private.
Acuity:
Very Secret I know almost nothign about their progress. They had an unflown vehicle at the 2006 XPC, they could be the dark horse. They have an interesting control scheme that always made me wonder.
Armadillo:
As ready as anyone could be, the "Gold Standard"
Bon Nova:
They have posted a couple of very quick Rocket Motor videos, the longest being several seconds. We posted our 106 Second firing in April and we did not make it. They have posted no vehicle hardware pictures.
Masten:
They just announced on their blog they are out for 2007.
Micro space:
Failed to attend the required team meeting in Aug.
Paragon Labs:
They have a very credible vehicle, well constructed and professional Another team that is somewhat secretive and an unknown. They posted finished airframe and rocket firing pictures in Aug. They were planning to have throttling via movable pintile in the all aluminum motor, while technically very cool, not easy to do and Armadillo was never able to make an all aluminum motor last without melting.
Speed Up:
Announced that they will not make 2007.
Unreasonable Rocket:
Announced we will not make it in 2007.
Team X :
Pulled out before the Last team summit.
Sunday, September 16, 2007
Out of Time
The end of 2007
We took the complete vehicle out to FAR to do a four engine static test this weekend. We had a number of transport issues. We finally settled on a U haul trailer.
With the motors mounted the vehicle did not fit. So we unmounted the four motors. This left a fair bit dangling plumbing. Realize that this is a trailer with leaf springs and no shocks. The trailer is rated for 4500LBs we put 230 lbs in it. WE then drove for three hours to Mojave. We stopped early in the trip to check the tie downs and again at Mojave. By the time we reached the Arco station in Mojave we had either damaged the plumbing or shaken the hardware off of the valves for 19 of the 21 valves. The trip killed the vehicle. This ends the 2007 effort.
This is a lesson in construction. WE need to pay more attention to transport with a "Real" suspension and we need a lot more plumbing support brackets etc...
Also what are we doing with 21 Valves?
On Each Quadrant: (4 each for 16)
Main Lox
Main Fuel
Lox Throttle
Fuel Throttle
On the Top (5)
Lox Safety pop off
Fuel Safety Pop off
Master Pressurization
Master Fuel Purge.
Igniter Dual Valve.
This is part of our problem. We could not get the ball valves to throttle/operate fast enough for our throttle and we could not get the fast butterflies to seal so we doubled the quadrant valves. If we had more time we would had fixed the big ball valves with shims and shaped orifices, removing one whole set of valves. We applied a quick fix and it failed.
Going forward/Don Quixote
We have 34 days till the practice session at the NG-LLC site. We have 41 days till the contest. I made a spread sheet with a list of the tasks necessary to compete. I made an optimistic and pessimistic time estimate. If I stopped going to work (I've been working 4 days a week) and worked full time for the next 41 days, the optimistic schedule says I have 7 Extra days before the practice session. The Pessimistic schedule says I'd be 4 days late for the contest.
My Day Job is CTO of Netburner, I'm one of the founders and the success of that company is the source of funding that makes Unreasonable Rocket possible. In the last year I've been putting most of my creative efforts toward this project and my business has suffered as a result. How much more do I commit? These are agonizing decisions. The Logical decision would be to suspend the effort for this year and restart if there is any prize money left after the contest.
Evaluating other teams for 2007/2008
I've been trying to keep track of the other teams and Judge the status of their efforts. There are 9 teams. Armadillo is as ready as anyone is ever going to get. Unreasonable Rocket is not going to make it in 2007. Two teams dropped out by not making the summit. That leaves five teams. Two teams have privately told me they won't make it. One team has asked if they can share test days with me at FAR,I Said yes, no problem. (If they are just starting serious rocket engine tests they won't make it) One more team privately told me they were giving up on the 180 second contest for this year. This leaves one team unknown for the 180 second flight. Only Armadillo has anything posted on the FAA website. I have to conclude that it will probably be the Armadillo show this year at XPC.
Even Armadillo has some issues, they crashed texel and have a supplier problem with their graphite chambers for long duration high pressure operation. (180 seconds). If I were a betting man I'd give 90% odds that there will still be 2nd place 500K available next year.
This has been the most difficult post to write, I know a lot of people have been following and rooting for the father and son team and I'm sorry to let you all down. Be assured that we will continue. We will probably take a month off to rest. Tonight I'm going to do something I have not done in a year. I'm going to sit a and watch the Chargers Patriots game. . I spent 10 years living near Boston, GO Pats, I've spent 15 years in the San Diego area, GO Bolts. So I don't know who to root for, but it should be a good game.
We took the complete vehicle out to FAR to do a four engine static test this weekend. We had a number of transport issues. We finally settled on a U haul trailer.
With the motors mounted the vehicle did not fit. So we unmounted the four motors. This left a fair bit dangling plumbing. Realize that this is a trailer with leaf springs and no shocks. The trailer is rated for 4500LBs we put 230 lbs in it. WE then drove for three hours to Mojave. We stopped early in the trip to check the tie downs and again at Mojave. By the time we reached the Arco station in Mojave we had either damaged the plumbing or shaken the hardware off of the valves for 19 of the 21 valves. The trip killed the vehicle. This ends the 2007 effort.
This is a lesson in construction. WE need to pay more attention to transport with a "Real" suspension and we need a lot more plumbing support brackets etc...
Also what are we doing with 21 Valves?
On Each Quadrant: (4 each for 16)
Main Lox
Main Fuel
Lox Throttle
Fuel Throttle
On the Top (5)
Lox Safety pop off
Fuel Safety Pop off
Master Pressurization
Master Fuel Purge.
Igniter Dual Valve.
This is part of our problem. We could not get the ball valves to throttle/operate fast enough for our throttle and we could not get the fast butterflies to seal so we doubled the quadrant valves. If we had more time we would had fixed the big ball valves with shims and shaped orifices, removing one whole set of valves. We applied a quick fix and it failed.
Going forward/Don Quixote
We have 34 days till the practice session at the NG-LLC site. We have 41 days till the contest. I made a spread sheet with a list of the tasks necessary to compete. I made an optimistic and pessimistic time estimate. If I stopped going to work (I've been working 4 days a week) and worked full time for the next 41 days, the optimistic schedule says I have 7 Extra days before the practice session. The Pessimistic schedule says I'd be 4 days late for the contest.
My Day Job is CTO of Netburner, I'm one of the founders and the success of that company is the source of funding that makes Unreasonable Rocket possible. In the last year I've been putting most of my creative efforts toward this project and my business has suffered as a result. How much more do I commit? These are agonizing decisions. The Logical decision would be to suspend the effort for this year and restart if there is any prize money left after the contest.
Evaluating other teams for 2007/2008
I've been trying to keep track of the other teams and Judge the status of their efforts. There are 9 teams. Armadillo is as ready as anyone is ever going to get. Unreasonable Rocket is not going to make it in 2007. Two teams dropped out by not making the summit. That leaves five teams. Two teams have privately told me they won't make it. One team has asked if they can share test days with me at FAR,I Said yes, no problem. (If they are just starting serious rocket engine tests they won't make it) One more team privately told me they were giving up on the 180 second contest for this year. This leaves one team unknown for the 180 second flight. Only Armadillo has anything posted on the FAA website. I have to conclude that it will probably be the Armadillo show this year at XPC.
Even Armadillo has some issues, they crashed texel and have a supplier problem with their graphite chambers for long duration high pressure operation. (180 seconds). If I were a betting man I'd give 90% odds that there will still be 2nd place 500K available next year.
This has been the most difficult post to write, I know a lot of people have been following and rooting for the father and son team and I'm sorry to let you all down. Be assured that we will continue. We will probably take a month off to rest. Tonight I'm going to do something I have not done in a year. I'm going to sit a and watch the Chargers Patriots game. . I spent 10 years living near Boston, GO Pats, I've spent 15 years in the San Diego area, GO Bolts. So I don't know who to root for, but it should be a good game.
Thursday, September 13, 2007
The New X prize.
I'm really disappointed in the new Google Lunar Xprize.
It would be a great prize 10 years from now, but today it just illustrates the core problem with space access. The high cost of access to low earth orbit.
The grand prize is 20M only twice what the original x-prize, yet the problem is at least 100 times as hard. I can't imagine what group or company would go after this prize.
Even if it is won, I fear it will not add much to reducing the cost of access.
It might be done as a stunt with a 500 gm Microrover.
I fear it will be a cool footnote, and will be a lot like Bigelows Americas space prize, The ratio of difficulty to winnings is just too high. (I personally think that Bigelows prize is of similar difficulty to the Google Lunar Xprize, and is twice the $$)
There are a number of firms working on high performance sub orbital aiming toward orbital launchers , Armadillo, Garvey Space, Micro-launchers, Masten etc...
If the intent of prizes is to encourage space exploration, A prize to encourage transport development would be so much more useful. I'd like to see a prize for a reusable orbital launcher, just something to launch 350 gram can sats.
It would be a great prize 10 years from now, but today it just illustrates the core problem with space access. The high cost of access to low earth orbit.
The grand prize is 20M only twice what the original x-prize, yet the problem is at least 100 times as hard. I can't imagine what group or company would go after this prize.
Even if it is won, I fear it will not add much to reducing the cost of access.
It might be done as a stunt with a 500 gm Microrover.
I fear it will be a cool footnote, and will be a lot like Bigelows Americas space prize, The ratio of difficulty to winnings is just too high. (I personally think that Bigelows prize is of similar difficulty to the Google Lunar Xprize, and is twice the $$)
There are a number of firms working on high performance sub orbital aiming toward orbital launchers , Armadillo, Garvey Space, Micro-launchers, Masten etc...
If the intent of prizes is to encourage space exploration, A prize to encourage transport development would be so much more useful. I'd like to see a prize for a reusable orbital launcher, just something to launch 350 gram can sats.
Wednesday, September 12, 2007
Win some loose some...
Tonight I finished the last little bit of wiring on the vehicle.
All the cable bundles had been run a few days ago, I just had a few misc connectors to solder on or wiring errors to fix.
We then went about systematically checking out quadrants.
Some where in the middle of doing this I tripped on the Ethernet cable going to the LapTop and the resultant experiment in inelastic collisions took out the LapTop screen.
Fortunately there is no shortage of computers in the Breed household.
All the cable bundles had been run a few days ago, I just had a few misc connectors to solder on or wiring errors to fix.
We then went about systematically checking out quadrants.
Some where in the middle of doing this I tripped on the Ethernet cable going to the LapTop and the resultant experiment in inelastic collisions took out the LapTop screen.
Fortunately there is no shortage of computers in the Breed household.
Tuesday, September 11, 2007
Really good news...
The vehicle is 100% hardware complete.
We weighed it and we are at least 10% under our target weight!!!!!!!
I'm not going to publish the weight until I can repeat the measurement, with a better calibrated scale,but this gives us significant performance margin for reaching 180 seconds!
More details:
The target weight with payload was 326 lbs.
The target empty weight was 271 lbs
The actual empty weight 230 Lbs.
My actual empty weight is 15% under Budget!!!
In order to do the 180 seconds I need a realized in flight ISP of ~152
As John Carmack rightly points out it won't be as high as I expect or wish.
The theoretical ISP for the pressures and fuel combination I'm using is 227
So I need to realize 66% of theoretical.
This is with tanks 90% full.
If I go to tanks 97% full I need an ISP of 145
We weighed it and we are at least 10% under our target weight!!!!!!!
I'm not going to publish the weight until I can repeat the measurement, with a better calibrated scale,but this gives us significant performance margin for reaching 180 seconds!
More details:
The target weight with payload was 326 lbs.
The target empty weight was 271 lbs
The actual empty weight 230 Lbs.
My actual empty weight is 15% under Budget!!!
In order to do the 180 seconds I need a realized in flight ISP of ~152
As John Carmack rightly points out it won't be as high as I expect or wish.
The theoretical ISP for the pressures and fuel combination I'm using is 227
So I need to realize 66% of theoretical.
This is with tanks 90% full.
If I go to tanks 97% full I need an ISP of 145
Friday, September 07, 2007
I'll sleep when I'm dead.
So much to do, there's plenty on the farm
I'll sleep when I'm dead
Saturday night I like to raise a little harm
I'll sleep when I'm dead
I'm drinking heartbreak motor oil and Bombay gin
I'll sleep when I'm dead
Straight from the rocket , twisted again
I'll sleep when I'm dead
Paraphrased from Warren Zevon.
Today I machined the last part.
If it all works the rocket hardware is done.
We have been trying to test it for the last three weeks.
We thought we had a chance to test two weeks ago Saturday.
We thought we would test with one motor last Saturday, alas when we flow tested the motor we were going to use, it was unusable, and may be why our last test failed. So I spent the last week building and carefully QA-ing 5 motors. I've taken detailed pictures of the whole process and after the XPC I'll post the drawings and detailed machining documentation.
So here it is three weeks after I first thought we might test the full up vehicle in a static fire, I've worked 18 and 20 hour days for three weeks and we have a shot at being ready for Saturday. I keep telling people we are testing next staurday,and I'm feeling like a flake. There are always a million details. Example Today my son and I are going over the new igniter plumbing and I realized that we had not put in the necessary check valves. So we are redoing that section of plumbing. (My son is currently driving back from the LA McMaster Carr will call with the check valves.) I'll post more later.
I'll sleep when I'm dead
Saturday night I like to raise a little harm
I'll sleep when I'm dead
I'm drinking heartbreak motor oil and Bombay gin
I'll sleep when I'm dead
Straight from the rocket , twisted again
I'll sleep when I'm dead
Paraphrased from Warren Zevon.
Today I machined the last part.
If it all works the rocket hardware is done.
We have been trying to test it for the last three weeks.
We thought we had a chance to test two weeks ago Saturday.
We thought we would test with one motor last Saturday, alas when we flow tested the motor we were going to use, it was unusable, and may be why our last test failed. So I spent the last week building and carefully QA-ing 5 motors. I've taken detailed pictures of the whole process and after the XPC I'll post the drawings and detailed machining documentation.
So here it is three weeks after I first thought we might test the full up vehicle in a static fire, I've worked 18 and 20 hour days for three weeks and we have a shot at being ready for Saturday. I keep telling people we are testing next staurday,and I'm feeling like a flake. There are always a million details. Example Today my son and I are going over the new igniter plumbing and I realized that we had not put in the necessary check valves. So we are redoing that section of plumbing. (My son is currently driving back from the LA McMaster Carr will call with the check valves.) I'll post more later.
Monday, September 03, 2007
Do you have a rocket problem?
If your garage sink has sprouted strange blue plumbing...
If you spend hours in the hot sun with a magnifying glass and a stop watch
staring at streams of water..
If you can quote the National fire protection standards for cryogenic fluids to the code enforcement officer, without notes.
If you know exactly what chemicals are used to denature ethanol, and can quote the stock numbers for the different types from the local chemical supplier.
If you collect strange copper sculptures.
If you know the density of several kinds of alcohol in both English and metric units.
If you have a sleepless night worring about how to rotate an Inertia Tensor
(And your friends solve the problem by return E-mail)
If you have a weekly conference call to a federal agency to explain how you problem is going...
If one of your buddies stops by to visit on the weekend and the first question he asks "are there any stainless chips in the chips on the floor" He's barefoot and his feet are just fine with aluminum chips, but they are not yet tough enough for stainless.
If you are proud of your AN fittings collection.
If you know the hours of and directions to the McMaster Carr will call window.
If you this looks like you, you have arocket problem, seek help.
If you spend hours in the hot sun with a magnifying glass and a stop watch
staring at streams of water..
If you can quote the National fire protection standards for cryogenic fluids to the code enforcement officer, without notes.
If you know exactly what chemicals are used to denature ethanol, and can quote the stock numbers for the different types from the local chemical supplier.
If you collect strange copper sculptures.
If you know the density of several kinds of alcohol in both English and metric units.
If you have a sleepless night worring about how to rotate an Inertia Tensor
(And your friends solve the problem by return E-mail)
If you have a weekly conference call to a federal agency to explain how you problem is going...
If one of your buddies stops by to visit on the weekend and the first question he asks "are there any stainless chips in the chips on the floor" He's barefoot and his feet are just fine with aluminum chips, but they are not yet tough enough for stainless.
If you are proud of your AN fittings collection.
If you know the hours of and directions to the McMaster Carr will call window.
If you this looks like you, you have arocket problem, seek help.
Subscribe to:
Posts (Atom)