SPI between ArduPilot, ArduIMU, SCP1000

Finaallly tonight got this to work more completely. SCP baro sensor to IMU was not so hard. Getting IMU and Pilot to work was more trouble for me.

The layout I chose is: ArduIMU is spi master, SCP1000 and ArduPilot are slaves.

ArduIMU requests airspeed from the ArduPilot, it will be used in combination with the gps based speed in the IMU. It will send the resulting AHRS data to the ArduPilot, as a predefined message, with variables in a certain order. The IMU requests baro from the SCP1000, it will be used in the IMU for altitude, better than the gps altitude. The IMU has the gps connected to it, it will send the req'd lat/lon, etc to the Ardupilot also over spi.

As a slave on spi bus, ArduPilot uses the SPI interrupt to trigger shifting each new byte of data in & out of the spi data register SPDR. like this: http://www.rocketnumbernine.com/2009/07/03/using-spi-on-an-avr-3/

Even though it's a slave, The SCP1000 uses an extra input to the IMU to tell it when it is ready with a new pressure reading, then the IMU proceeds with asking for it over spi. It could be done other ways, but in higher resolution mode, the SCP only samples about every .5 second. So this way the data is collected precisely when it's available.

Pins on ArduPilot:
this won't really work with current boards so well, for normal planes. I require only one servo channel. The spi slave requires use of d10, as SS, normally used for servo 2 output. Soldered to a via to access it and get it to a header with the d11, d12, d13.

Pins on ArduIMU v1:
needed two additional pins, output SS to the Ardupilot, and an input for data ready from the SCP1000. soldered to d8 and d9 (pins 12,13) on the atmega, and brought to a female header. the normal spi pins are nicely available already.

Level converter:
The SCP1000 is a 3.3v device, don't fry it with 5v lines. made a level converter with a dozen or so discrete components. like this: http://delphys.net/d.holmes/hardware/levelshift.html I even tortured myself with tiny surface mount transistors, oh so fun!

Code:
If anyone desires a similar scheme maybe this is a starting point. And maybe people will have suggestions for me. I'm sure there are things to improve. With the 1280 based ArduPilot, pins should not be an issue, and this should be faster communication between the micros than UART. But the code may be more complicated, and harder for people to get into.

What it does so far is get the airspeed data from ArduPilot back to IMU, in response to a particular message number. And read the pressure sensor. Next will add one larger message from the IMU, with all the data that Pilot would like to have. Should be not too hard, framework is there for messages, just define them appropriately on both ends. There are added .pde files, spi.pde and scp1000.pde that have the relevant code, and some variables and declarations on the main .pde file. should be able to just take the spi and scp1000 files to add in to other code.
ardu_100104.tar.gz

This is based on not the latest IMU & AP code, I need to work with that next too. Oh, the IMU code also is modified for 406 gps.

Hope this is helpful, please let me know if any questions / comments. Thanks!

Views: 979


Admin
Comment by Morli on January 4, 2010 at 11:52pm
looks good so far and I like it too :) . pls take into consideration the new devices like Ublox gps and some expansion for other compatible sensors :) , thanks
Comment by Will Coffey on January 14, 2010 at 9:38pm
Hey there Dale. I am currently working with an SCP1000 pressure sensor to replace the GPS altitude reading. I was wondering what sort of results you were getting from the sensor. I have mine in High resolution mode but Im not happy with the noise the readings seem to be displaying. I was hoping that if you had some spare time you could check out my data and code which I have attached. It is nowhere near what the datasheet advertises as a 1.5pa accuracy.
Pressure Testing.xlsxSCP1000rev1_1.pde
Thanks in advance,

Will
Comment by Will Coffey on January 14, 2010 at 9:39pm
I should have put a space between those two links. They are separate links to an excel document and a .pde file.

Cheers,

Will
Comment by Dale on January 14, 2010 at 10:32pm
Hi Will,

what speed is the scp1000 being read at, there are a couple of different modes it can do. I'm using the slow higher precision mode.

here's what mine looks like, there's a quick plot of calculated altitude in meters (above power on altitude), and baro pressure in Pa. there is some noise, but it does stay pretty close to only +-1Pa, and the crazy thing can show me the difference between +- maybe .25 of a meter, lifting it up and down. it does drift some from the power on reading. but should sure beat GPS altitude. scp1000data_100114.xls

here's the scp code I'm using, unzip the file and look for the scp1000.pde file in the ArduIMU folder, got more of the spi communication working also. ardu_100114.tar.gz

Loooks like you're using mode 0A, high resolution mode, ok. Really don't know if this could be it, but page 11 in the data sheet talks about clearing the Operation register before writing in the mode you want (0A). Doesn't look like you do that, but you do some other things maybe instead. Speculation maybe it's not really in mode 0A?

How fast is the DRDY line going back high, how many readings per second are coming out? that would verify what mode it's in.

so could try like this:

void init_scp1000()
{
pinMode(SCP_DRDY,INPUT); // SCP1000 data ready signal input to IMU

delay(60);
delay(90); //page 7 recommends, although not likely needed, since already other delays since system power on.

read_scp1000(); //page 11 instructs to not set operation if DRDY high, it is likely ready by now, so read first
write_register(OPERATION,0x00); //page 11 instructs to clear operation register first, and wait 50 ms
delay(50);

// Serial.println("SCP1000 High Speed Mode 09, ~9Hz, 15bit");
// write_register(OPERATION,0x09);

// Serial.println("SCP1000 High Res Mode 0A, ~2Hz, 17bit");
write_register(OPERATION,0x0A);

//Serial.println("SCP1000 Low Power Mode 0B, ~1Hz, 15bit");
//write_register(OPERATION,0x0B);

temp_pressure = 400000; // initial value for filter, in counts, ~100kPa
}
Comment by Will Coffey on January 14, 2010 at 11:34pm
Hi Dale,

Thanks for such a fast response! I will have a look into the clearing of the operation register prior to setting High Precision mode but the DRDY pin is definitely pulsing at around 2Hz which makes me think the code is working correctly in that section at least. Ill skim through your code and see if there are some important delays I have missed. If I can get the altitude accurate to within +-0.5m I will be happy.

Thanks again, Ill let you know how it goes. If you have any more thoughts I would love to here them :)

Cheers,

Will
Comment by Will Coffey on January 16, 2010 at 7:27pm
Hi Dale, I have read the data sheet 100 times now and am positive that I was reading the sensor right however in my research I came across a code example by VTI written in C. This morning I ported that code to arduino and found my pressure readings are still fluctuating but Im thinking its just the environment im in at the moment (inside an air conditioned factory). Ill try some more in depth testing outside later however I think whatever results I get will be far superior to the GPS altitude which is just all over the place. The ported code from VTI knocked about 2K off the code size if your interested. I have attached the new version below. I should also apologize for the credits in the previous code I uploaded as much of that work can be found on the Arduino forums.

Cheers,

Will
Comment by Ralph Loveday on January 19, 2010 at 5:51pm
I was getting noisy figures in my application until I remembered that the datasheet says that the sensor is light sensitive. Have you got a cap for the sensor? Try putting a coffee cup over it.
Comment by Will Coffey on January 19, 2010 at 7:06pm
Oh your right. Ive ordered one of the rubber gaskets to put over it. Thanks for that, very helpful. Ive been flat out with other stuff lately but ill upload a new set of test data at some point so people can see how accurate these things are. Far superior to GPS altitude. Im also using a venus gps which updates at 10Hz so im thinking of making a complimentary filter with the majority of the weighting being on the more accurate 1Hz pressure sensor. Just means Ill have some idea of altitude in between the pressure sensor readings. I might find that I dont need altitude updates more than once a second though.

Developer
Comment by Mark Colwell on January 19, 2010 at 7:39pm
Are you happy with venus GPS ?? I was thinking about getting one.. Does it get a DGPS lock? True 10hz?
Comment by Will Coffey on January 19, 2010 at 10:54pm
Hi, so far I have not tried the DGPS function but I am getting position updates at around 10Hz (havent tested that but it is dam fast!). The module is easy to use and I would recommend it. Hope this helps.

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2018   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service