UPDATE!! Got the Servo Outputs running today. They offer 15 bits of precision and are synchronized to the guidance/control functions to minimize latency in the control loop. Also got the Magnetometer running and am talking to the GPS receiverUPDATE #2: May 24 2009: Just got Current Voltage and Temperature Monitoring done. Also have the Attitude Estimation Running. Check it out.Pic32 Autopilot Attitude Estimation.Received my boards from the board house Friday and began building and testing. Power supplies went on first and seem to work fine - clean outputs and efficient. Next went on the processor. I wrote some preliminary code to toggle one of the LEDs and all seemed to work fine. Next I went ahead and mounted everything else and began writing code to grab all the sensor data. I also got the USB port working so I could feed the data to a PC for viewing. Here is the status.Power Supplies - workingProcessor - working12 bit AD - workingGyros - workingAccelerometers - workingAirspeed Sensor - workingUSB - workingAltitude Sensor - Not DoneMagnetometer - workingGPS Interface - workingRF Interface - Not DoneCurrent Monitor - workingVoltage Monitor - workingSD Card - Not DoneServo Outputs - workingPWM In - Not DoneAs you can see there is a bit more hardware to checkout, but it should go pretty fast. I have set up the core timing and am sampling the sensors at 100 Hz via a 5KHz state machine. Right now it's taking 1.5% of the processor throughput to sample gyros, accels and airspeed. I'm estimating 2 to 2.5% when I'm done. That should leave plenty of throughput for guidance/control and communications functions.A very preliminary look at the IDG500 gyros indicates about 0.24 deg/sec noise PtoP (about 0.1 RMS) and .3 deg/sec bias drift after 1 hour. This testing will be ongoing particularly after I have all the acquisition code done.I want to finish getting the hardware validated and to let people know I have 4 un-stuffed boards if anyone is interested. Be warned though - surface mount assembly experience is necessary. Just take a look at the magnetometer and gyros! I might be willing to mount some of the parts for people. Cost will depend on what you want mounted.Let me know what you think!RegardsBrian
Just wanted to give you a little status on PicPilot Board #2. It arrived in just a couple days via Priority Mail in great shape. I'm glad you offered an assembled version! This design is so compact and the discrete's are so tiny, It would take a lot of time and skill to apply solder paste, place the components and then flow the board. I do a fair amount of surface mount assembly but you did a much better job than I could have.
My MPLAB environment is up and I have been able to Make the code project, load it and run. I've even done a small cosmetic mod to the telemetry format, recompiled, and the data comes out now with my change. It's good to know that the base software works and the development IDE works with the system.
Next task is to get the XBee radios up and running so I can switch over to them from the USB port. USB isn't bad but since this is intended to fly, why not get the data link going as soon as possible? I have the config program from their web site but it may generate a question or two before it's running.
I did also download Microchip's FatFS file system for the microSD card. For now, I will work on that separately from the IMU code. But it would seem to be a good basis for an on-board Flight Data Recorder. May even paint the sd card orange like the big boxes!
Last thing, I also brought up Python and have your "moving box" demo script running. Looks just like your video, it rocks and rolls along with me as I move the board around. I will try to get the Ardu Ground Station going too once I find all the Labview modules.
Thanks for the great support, this is fun now and going to get better as we get to the helicopter platforms.
Sign me up for a board, either bare or kitted. I fly a Pantera 50 r/c heli and have been searching for an autopilot framework. Your board fits my bill with its five servo ports and magnetometer. This provides control capability for all the standard CCPM heli servos, and the magnetometer gives a heading reference while on the ground or in a hover. If we can filter the altitude sensor, then it may be able to "keep station" in a unassisted hover mode. Wow!
I already have and use the Microchip development environment here. It will be fun to port Bill P.'s DCM code over to this platform and then add the new control loops for heading and altitude. Just say when, I'm ready.
Fixed point for sure. There is ample resolution/dynamic range for the task so no reason to take the throughput hit implementing floating point on a fixed point processor. Some of the navigation tasks on the other hand might require floating point. I'll know for sure when I take a closer look at that down the road.
Thanks, Brian, for your detailed answer. Looking forward to seeing your code. Are you implementing DCM in fixed point, as in Bill Premerlani's design, or are you using floating point?
Hey Roy,
I've been using Pics for years, and when Microchip introduced the Pic32 I decided to enter their "PIC32 Design Contest" as an excuse to come up to speed on it. I think overall it's a great chip. Lots of peripherals, fast and inexpensive. The design environment is Microchips standard MPLAB that can be used for the entire Microchip line of processors. They have a free version that supports the Pic32 and includes a C compiler. The free version of the C compiler does have some limitations on the optimization features that can only be unlocked with the pay version, but they are minor and I'm being careful to avoid any issues along those lines so if anybody wants to pick up code development on my autopilot they can do so with the free compiler.
There are plenty of examples for using the various peripherals on the microchip website including USB, I2C, SPI, Uart, AD and even free FAT16 and FAT32 file systems for use with compact flash, SD cards or USB thumb drives. I am a little disappointed in the DSP library. They have a great library for the DSPic and are working towards making the Pic32 library completely compatible but I'm finding it's not quit there yet so I'm having to code up some of the functions myself. It also seems some of the optimizations that would make the DSP library perform at it's best can only be enabled with the pay version of the compiler. Not a big deal really, still plenty of power to get the work done.
I have some experience with the ARM core, but when I started this project the Pic32 was fresh in my mind so I could quickly map out how everything would fit together. The fact is that a 16 bit processor is more than adequate for stabilization and control, I just thought it would be nice to have the 32 bits for navigation and to make sure I had enough throughput for the bells and whistles.
I'm far from being done with code, but I'm far enough along that I'll start posting some code in a few days that you can look over. I'm working now on the open loop DCM estimator now (no drift compensation yet). Should be done with that by the weekend if life doesn't get in the way.
Great project! As Brij mentioned, we're working on our own controller board (well, I should say he is - I don't have his skills :-). I was just wondering what led you to choose the PIC32 over another 32-bit chip - ARM for example? How is the compiler and other tools? How easy it is to access the on-board peripherals? Are there good library routines, or is it simple to do "manually"? Are there good example code projects out there? Do yo (or anyone else) have experience using one of the ARM chips is this or similar application?
(I, too hope to implement "DCM" on a quadrotor - probably even the entire integrated comp filter / feedback control algorithm that was described in one of the Mahoney papers)
Jack,
Yea, we are definitely at the mercy of the consumer world as far as what technology is available to us at a reasonable price. I think there must be some fabrication issues with trying to integrate all three gyro axis on one substrate though. You can kind of see x and y gyros being integrated together because they're on the same plane but through in the x axis and it becomes more of a three dimensional die fabrication situation.
Brij,
Don't let the I2C code scare you off. I'll be posting some of my code soon. look it over and I think you'll see it's not so bad. With the Pic32 much of the work is done in hardware. Not sure about the Arduino. I haven't had a reason to jump into that pool yet. Maybe it has to implement a purely software based I2C engine?
I plan on using the Ardupilot ground station initially. I've already started outputting some compatible messages. Eventually I'll need more capability particularly for two way communications. I'll decide then if I want to build on the Ardupilot ground station or start something new.
Invensense said they'd have 3 axis IMU chips by the end of 2007. Maybe the legions of upper managers they're hiring will get the ASIC design done, but it'll never be as cheap as Singapore Technology. They're still selling the 2 axis ones because their only imagination is cell phone image stabilization.
Brij is correct, the LISY300AL measures Z down thru the board. I've defined positive X being out the long edge of the board in the direction of the airspeed ports, positive Y out the right side when your facing forward and positive Z being down. Standard right hand rule will apply.
The LISY300AL is most likely temporary until the IDZ-500 comes out at the end of june. The LISY300AL is actually a fine gyro with good drift and noise specs, but has a low resonant point that could be an issue with a helicopter. It could be isolated from the high frequencies with proper mounting though. I'll make a final decision after the IDZ-500 is released and after using the LISY300 for a few weeks.
Briz, I'm actually sampling the gyros at 100Hz, but have a state machine running in my main 5KHz timing loop to divide the tasks up in such a way that only a small amount of code has to be executed each interrupt pass. Several of the devices are I2C which has a lot of overhead for checking buss condition ect.. plus is fairly slow at only 400kbps. This structure allows all the slow I2C transfers to go on in the background without wasting time waiting for START conditions, ACK, or byte transfers. A second interrupt could also be used for this, but I prefer to minimize interrupts if possible to maintain better control over timing and minimize context switching overhead.
I'll most likely average two samples and call the attitude estimator and control loops at 50Hz, but this is flexible. I also may up the gyro sample rate to 200Hz to get some more Nyquist margin. My gyro bandwidth and filtering is predominantly handled with the external analog filter. I'll play with that a bit too.
You said you are using the IDG500 gyro. Looking at your board, it appears that the larger of the two gyro chips is a LISY300AL. LISY300AL = single axis, IDG500 = dual axis. I realize it depends on the mounting of the board within the airframe, but which chip is taking care of which axis, since it appears that both chips are in the same plane of reference. Wouldn't you just be measuring XXY or XYY axes instead of XYZ?
What am I missing here? Have I simply misinterpreted the drawing?
Comments
My MPLAB environment is up and I have been able to Make the code project, load it and run. I've even done a small cosmetic mod to the telemetry format, recompiled, and the data comes out now with my change. It's good to know that the base software works and the development IDE works with the system.
Next task is to get the XBee radios up and running so I can switch over to them from the USB port. USB isn't bad but since this is intended to fly, why not get the data link going as soon as possible? I have the config program from their web site but it may generate a question or two before it's running.
I did also download Microchip's FatFS file system for the microSD card. For now, I will work on that separately from the IMU code. But it would seem to be a good basis for an on-board Flight Data Recorder. May even paint the sd card orange like the big boxes!
Last thing, I also brought up Python and have your "moving box" demo script running. Looks just like your video, it rocks and rolls along with me as I move the board around. I will try to get the Ardu Ground Station going too once I find all the Labview modules.
Thanks for the great support, this is fun now and going to get better as we get to the helicopter platforms.
Andy
I already have and use the Microchip development environment here. It will be fun to port Bill P.'s DCM code over to this platform and then add the new control loops for heading and altitude. Just say when, I'm ready.
Andy
Brian
- Roy
I've been using Pics for years, and when Microchip introduced the Pic32 I decided to enter their "PIC32 Design Contest" as an excuse to come up to speed on it. I think overall it's a great chip. Lots of peripherals, fast and inexpensive. The design environment is Microchips standard MPLAB that can be used for the entire Microchip line of processors. They have a free version that supports the Pic32 and includes a C compiler. The free version of the C compiler does have some limitations on the optimization features that can only be unlocked with the pay version, but they are minor and I'm being careful to avoid any issues along those lines so if anybody wants to pick up code development on my autopilot they can do so with the free compiler.
There are plenty of examples for using the various peripherals on the microchip website including USB, I2C, SPI, Uart, AD and even free FAT16 and FAT32 file systems for use with compact flash, SD cards or USB thumb drives. I am a little disappointed in the DSP library. They have a great library for the DSPic and are working towards making the Pic32 library completely compatible but I'm finding it's not quit there yet so I'm having to code up some of the functions myself. It also seems some of the optimizations that would make the DSP library perform at it's best can only be enabled with the pay version of the compiler. Not a big deal really, still plenty of power to get the work done.
I have some experience with the ARM core, but when I started this project the Pic32 was fresh in my mind so I could quickly map out how everything would fit together. The fact is that a 16 bit processor is more than adequate for stabilization and control, I just thought it would be nice to have the 32 bits for navigation and to make sure I had enough throughput for the bells and whistles.
I'm far from being done with code, but I'm far enough along that I'll start posting some code in a few days that you can look over. I'm working now on the open loop DCM estimator now (no drift compensation yet). Should be done with that by the weekend if life doesn't get in the way.
regards,
Brian
Great project! As Brij mentioned, we're working on our own controller board (well, I should say he is - I don't have his skills :-). I was just wondering what led you to choose the PIC32 over another 32-bit chip - ARM for example? How is the compiler and other tools? How easy it is to access the on-board peripherals? Are there good library routines, or is it simple to do "manually"? Are there good example code projects out there? Do yo (or anyone else) have experience using one of the ARM chips is this or similar application?
(I, too hope to implement "DCM" on a quadrotor - probably even the entire integrated comp filter / feedback control algorithm that was described in one of the Mahoney papers)
Thanks
Roy
Yea, we are definitely at the mercy of the consumer world as far as what technology is available to us at a reasonable price. I think there must be some fabrication issues with trying to integrate all three gyro axis on one substrate though. You can kind of see x and y gyros being integrated together because they're on the same plane but through in the x axis and it becomes more of a three dimensional die fabrication situation.
Brij,
Don't let the I2C code scare you off. I'll be posting some of my code soon. look it over and I think you'll see it's not so bad. With the Pic32 much of the work is done in hardware. Not sure about the Arduino. I haven't had a reason to jump into that pool yet. Maybe it has to implement a purely software based I2C engine?
I plan on using the Ardupilot ground station initially. I've already started outputting some compatible messages. Eventually I'll need more capability particularly for two way communications. I'll decide then if I want to build on the Ardupilot ground station or start something new.
Brian
The LISY300AL is most likely temporary until the IDZ-500 comes out at the end of june. The LISY300AL is actually a fine gyro with good drift and noise specs, but has a low resonant point that could be an issue with a helicopter. It could be isolated from the high frequencies with proper mounting though. I'll make a final decision after the IDZ-500 is released and after using the LISY300 for a few weeks.
Briz, I'm actually sampling the gyros at 100Hz, but have a state machine running in my main 5KHz timing loop to divide the tasks up in such a way that only a small amount of code has to be executed each interrupt pass. Several of the devices are I2C which has a lot of overhead for checking buss condition ect.. plus is fairly slow at only 400kbps. This structure allows all the slow I2C transfers to go on in the background without wasting time waiting for START conditions, ACK, or byte transfers. A second interrupt could also be used for this, but I prefer to minimize interrupts if possible to maintain better control over timing and minimize context switching overhead.
I'll most likely average two samples and call the attitude estimator and control loops at 50Hz, but this is flexible. I also may up the gyro sample rate to 200Hz to get some more Nyquist margin. My gyro bandwidth and filtering is predominantly handled with the external analog filter. I'll play with that a bit too.
Brian
You said you are using the IDG500 gyro. Looking at your board, it appears that the larger of the two gyro chips is a LISY300AL. LISY300AL = single axis, IDG500 = dual axis. I realize it depends on the mounting of the board within the airframe, but which chip is taking care of which axis, since it appears that both chips are in the same plane of reference. Wouldn't you just be measuring XXY or XYY axes instead of XYZ?
What am I missing here? Have I simply misinterpreted the drawing?
-
1
-
2
-
3
of 3 Next