Sparkfun "UAV Dev Platform" - PIC18 + GPS + IMU

[poynting]

http://www.sparkfun.com/commerce/product_info.php?products_id=707

Price: $299.95

Features:


20-Channel SiRF III GPS Receiver[/li]
PIC 18F2520 Controller (with onboard 3.3V and 5V glue logic)
4MHz oscillator
3 Input, 2 PWM output points
6-Wire ICSP debug header
3 seperate colored status LEDs
2 General purpose switches
On board 3.3V and 5V regulators (150mA max)
10m Positional Accuracy / 5m with WAAS
GPS Outputs NMEA 0183 and SiRF binary protocol

[Tom Harper]

Nice set up. Are you going to try it?

The binary output of the GPS looks interesting.

[Unterhausen]

Tom,
Why is the binary output more interesting? I have some of these GPS units and I'm going to integrate them into robots.

These units look really nice. Too bad it's only 2 axis on accelerometer and gyro. It does meet the max dollar amount where my wife might not notice though.
Eric

[Tom Harper]

Eric,

Hey, you get a bigger allowance than I do!

The binary protocol should be faster and easier to parse. I assume that OEM units will eventually drop NMEA and go to binary. I tried to locate the binary protocol reference manual on Sirf's web site but couldn't find it. Emailed the local salesman. Maybe he can (will) help.

[Mr.RC-CAM]

Attached is the Sirf III binary protocol manual.

[Tom Harper]

Thank you!!!!!

[Unterhausen]

you can always get it through sparkfun

[sodman12]

price is just about right. not to much. 350 is a little on the heavy side but 299 is just right

[space_case]

Too bad there is not a third PWM. You could maybe grab the heading off of the GPS and drive the rudder.

[Mr.RC-CAM]

Too bad there is not a third PWM. You could maybe grab the heading off of the GPS and drive the rudder.I think that you would find that the PWM features are not easily used to derive servo signals. Instead, Servo pulses are nearly always handled with a timer module and some interrupt code. In other words, having only two hardware PWM's is not a problem at all.

[poynting]

Binary protocol for GPS is a benefit in my eyes. Fixed length, fixed form packets are easier (and less computationally intensive) to decode than variable length NMEA.

I would probably upgrade the crystal to 10MHz and run at a 40MHz internal clock. You could add another Gyro if you wanted to completely give up any attempt at temperature compensation (because you'd need the extra AtoD input). Sparkfun sells the gyro break-out boards already mounted for $65.

[LukeZ]

You could add another Gyro if you wanted to completely give up any attempt at temperature compensation (because you'd need the extra AtoD input).Not sure what you mean by that... there are inexpensive digital temperature sensors - no AD port needed, just an SPI or other serial interface, which you could bit-bang on a spare I/O pin, but the PIC they're using may even have a hardware implementation, I can't recall. Check out the DS18S20 (http://www.sparkfun.com/commerce/product_info.php?products_id=245), also sold at SparkFun.

...And sorry if I misunderstood your post, and this is all old news to you.


Luke

[Unterhausen]

You could add another Gyro if you wanted to completely give up any attempt at temperature compensation (because you'd need the extra AtoD input).
that's an interesting tradeoff I hadn't thought about. The price on this is very good.

They keep coming out with really neat products.

[poynting]

Not sure what you mean by that... there are inexpensive digital temperature sensors...

I'm familiar with the sensors, but this is an option I hadn't really thought of. The Analog Devices gyros each have an independent temperature output that one would normally use for temperature compensation over the range. From my experience, the temperature reading from any one gyro is usually within a couple of degrees of others in the same system. However, the temperature inside the gyros raises as they warm up, usually by 5-10 degC, but sometimes by as much as 20 degC if they're in a closed space with other electronics. I don't know if this could be measured accurately enough from outside the gyros. I think it would be best to go ahead and measure the temperature of at least one gryo and do some compensation.

The thought if I2C brings up another option along the same lines. One could use an external AtoD, via I2C. The schematic has Self-Test 1/3 on Pin RC3 and SR2, a switch, on Pin RC4. These are the hardware I2C ports in that PIC. I think you could give up both of these to interface to an I2C ADC and gain a pretty significant benefit with 8 channels of 16-bit AtoD. At that point, you could shuffle things around a bit and use the 16-bit for the gyros and temps, and get back a couple of GPIO or 10-bit AtoD.

[Unterhausen]

I think the internal temp reading is the way to go. Most of these devices do have I2C versions, they are more expensive and the system design is harder. My impression is that they are superior devices.

[LukeZ]

I think you could give up both of these to interface to an I2C ADC and gain a pretty significant benefit with 8 channels of 16-bit AtoD. At that point, you could shuffle things around a bit and use the 16-bit for the gyros and temps, and get back a couple of GPIO or 10-bit AtoD.I agree that an external I2C A/D is an interesting option - but if you're going to use a 16 bit converter, you're looking at designing an entirely new board, or a secondary board, at the least - at any rate, you wouldn't be able to just slap it on some proto-board. Those things need very clean and stable voltages to get the max resolution out of. In fact I've heard that at 16 bits you really need to use a four layer board at least. In any case, my feeling is it wouldn't be trivial.

However, you don't need 16 bits to read temp, 10 bits would be fine. But I guess if you want to do the gyro sampling with this other A/D you'd want more than 10 bits. Anyways, stuff to think about. It all begins to get more complicated.

For more money, you can also buy gyros/accelerometers with digital or PWM out, rather than analog. Might be something to look into.


Luke

[scouser]

Has anyone used the SiRF binary protocol yet?

I am waiting for my board, but when I am up and running with the control code that came from Sparkfun's website I want to explore using the binary protocol, particularly for vertical speed.

Scouser

[FAKHREALAM]

Has anyone used the SiRF binary protocol yet?

I am waiting for my board, but when I am up and running with the control code that came from Sparkfun's website I want to explore using the binary protocol, particularly for vertical speed.

Scouser

Any progress so far with Sparkfun board. I am thinking to check out one too.
How fast this board can decode GPS data. Is any one tried it.

Fakhre Alam

[scouser]

Hi all,

My board has arrived in London UK, so should be in Liverpool today/tomorrow/Monday. I am also waiting for an ICD2, but I should be able to start soon.

Scouser :)

[scouser]

My Sparkfun board arrived last Monday, but I am still waiting for the ICD2 to come from Hong Kong. :) :(

That was also the day that I got out of hospital following a shoulder operation. I will have to keep my arm immobile in a sling for about 4 weeks. It won't stop me flying but I am at my wife's mercy for transport to the field! :eek:

First impressions are excellent. It came complete with servo leads and plugs and a 2 pin connector on J1 for external power. The board does not have all the components labeled but it was quite easy to trace the circuit and see that the jumpers are small blobs of solder that bridge tiny pads on the board. All the optional jumpers had been bridged on my board.

I am stuck with the program that Sparkfun used to test the board until I get the ICD2, but it appears to be the same as described in Sparkfun's Manual.
The board is fitted in my Multiplex Magister and is running on 5 volts from a Ubec. The Sell channel is running on channel 5 of my radio, controlled by mixed switches to select modes.

The switches SR1 and 2 are configured for servo reversing. None of my other GPS has had a powered aerial, so I was impressed to get a cold fix in 5 minutes inside my house, where the others can't see any signals. Everything works as expected, except the elevator movement, which is very small. I won't be able to test the homing mode in the air until I can change the program, because my radio's failsafe maintains the servo pulses. On the ground, I just unplugged the Sel channel from the Rx!

Snow and wind are forecast here this weekend, but I'll sweet talk my driver if it becomes flyable. :rolleyes:

Scouser

[scouser]

Hi all,

Today is an excellent day. My ICD2 arrived from China. I haven't had time to check it fully yet, but it seems to be OK.

The weather was good enough to fly and my wife was kind enough to drive me to the field.

I normally use the ailerons on this model as the main steering/rolling control. Steering the model with the rudder seems coarse to me...first the model yaws...then it rolls... and finally it turns. It works, but one of the things that I want to explore later is steering with the ailerons.

I was flying with one arm inside my coat and my right arm in a sling (broken clavicle) so I was happy just to check out the mixed, autopilot/manual, mode which worked fine. The autopilot's steering corrections were just like manual rudder steering.

I had expected the pitch corrections to be too small, but they worked too. The mixing rate can be varied and I found that the higher rates were needed on both channels to cope with today's turbulence.

Switching between the modes did not give me any problems either.

scouser

[aboveall]

HI all, :)

I am new to this and I find it very interesting. Can anyone also show how to connect and program it?

[scouser]

Hi aboveall,

On this link: http://www.sparkfun.com/commerce/product_info.php?products_id=707 there is a picture and links to manuals about the board. The first manual describes the hardware.

The picture shows five orange leads from the board. Three leads plug into a radio receiver and the model's servos plug into the other two.

The program can be changed by the user using hardware and software from these people: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=64

There is a lot to get your head around but these forums are full of examples of other self-starters.

regards,

scouser

[scouser]

Hi everyone,

I'm having problems programming my board. Can anyone help me to get going?

The Chinese ICD2 that I bought was broken, so I got a PICkit2 (made by Microchip) with a demo board and tutorial. All the tutorials work fine, including debug mode, but they are written for the demo chip, so the assembler is not transferable. When I connect to the UAV board I can't debug. The IDE says that the debug code is transfered, and the debug vector is set, but then I get:

"PK2Error 0028 Unable to enter debug mode"...and

"PK2Error 0024 PICkit2 was unable to establish Vdd on the target. (Attempted 5.00V - Read 0.00V."

I can write to the UAV board, and I can check the code in memory (with a different program from the IDE that programmed the chip).

I have used Sparkfun's UAV assembler program from their site and TinoR6's C program, both with similar results.

Have other people had more success?

Best regards,

scouser

[scouser]

Hi all,

I might have the answer to my own problem! :o

The PICkit2 calls for a 470 ohm resistor between Vdd and Vpp, whereas the ICD2 debugger needs a 10K in that place. the board was developed using an ICD2. I will try adding a resistor between the ICSP header pins and see if that solves my problem.

scouser

[scouser]

Hi all,

My problem is that I am rusty at assembler programming and this PIC chip is a very complicated device. I couldn't work out whether my chip was broken or I was trying to program it wrong. It was fine with the software that Sparkfun had used to test the board, but not when I programmed it. I got myself a breadboard and a PIC16f282 and learned how to program and debug that, simpler, chip.

There are lots of configuration registers in the PIC18f2520, and some are not accessible using the standard instruction set. Just setting the oscillator correctly required lots of reading and head scratching! I had naively expected the Sparkfun software to configure everything when the program was written to the memory. I can now see that that would not be a straight forward thing to do.

If anyone else is playing with this system, the high-address configuration bits are accessible through MPLAB IDE's configuration menu. The Visual Initializer tool didn't help me because it just introduced different errors! I think that programming in C will involve the same issues. In C it is easy to set the registers, but you still need to study the Data Sheet (392 pages) to know what to set!

The PICkit2 does most of the things that the ICD2 can do. It can only set one debug breakpoint whereas the ICD2 is unlimited. The UAV board's 10K resistor (R3) doesn't appear to be critical. You must select "Debug" and not "Release" on the top line of the IDE, before you build the project, to enable debugging!

Perhaps now I can get on with modifying the software, as I intended.

scouser

[zik]

There's no doubt that PICs are pretty complicated to get started with. You might want to do a google search for some example code for the 2520 you can work from, just to get going. It does take a while to get all those configuration registers right on the PIC18 series.

[scouser]

My system is working better now. My problems were all down to configuration settings and learning to use the Microchip tools.

I had only expected to only be able to set 1 debug breakpoint in the program, but I have been able to use up to 3.

In both Sparkfun's assembler program, and TinoR6's C program, it has been easy (but necessary) to adjust the navigation constants that account for the UAV's latitude. The Sparkfun program uses the switches on the board for servo reversing, while the C program must be rewritten in several places to do the same thing.

Despite the C being easier to read at first, because it makes extensive use of imported headers and libraries, it is often harder to follow the details in C than in assembler.

I still haven't had the C program flying properly yet. The small parts that I understand appear to work properly, if a little strangely. For example, a heading error is calculated and the servo is deflected proportionally. A 180 degree error generates 100% pulse width, 90 degrees - 50% etc. From my full-size and model experience I would expect to use a constant turn until within 10-20 degrees, and then a reduction to roll out on heading. Use full deflections only to counteract severe turbulence. (That works for me in full-size ac in thunder storms etc)

I haven't had the assembler program navigating to a point either (because my receiver's failsafe continues to generate pulses if the TX is turned off). It did circle properly, however, which is 99% the same thing.

I'm still not sure which program will be the best foundation for my changes.

scouser

[FAKHREALAM]

My system is working better now. My problems were all down to configuration settings and learning to use the Microchip tools.

I had only expected to only be able to set 1 debug breakpoint in the program, but I have been able to use up to 3.

In both Sparkfun's assembler program, and TinoR6's C program, it has been easy (but necessary) to adjust the navigation constants that account for the UAV's latitude. The Sparkfun program uses the switches on the board for servo reversing, while the C program must be rewritten in several places to do the same thing.

scouser

I went through the assembly code (PWM&ADC and rudd_cntrl file), seems it written good, is any one tried the original code provided on sparkfun.com. I am interested in buying one unit, let me know is any one use it for auto pilot mode with RC plane (how good this unit and software is).

Fakhre Alam

[scouser]

It has been very interesting, but hard work, getting to grips with this board.

As I said in post #21, it worked just fine in my Magister. It was developed to control a two channel, powered glider and will function fine in that role. The gps receiver is only used to return to the launch point or circle the present location. The board is sold, however, as a "development platform" which makes it clear that it is intended that users should program it themselves. The "glider" program was written in assembler language, and is available from:

http://www.sparkfun.com/datasheets/GPS/EvalBoards/UAV%20Test%20Code.zip


There is potential for the board to do much more, which is what I am exploring.


There is a "C" program, written by TinoR6, which he has made available from:


http://forum.sparkfun.com/viewtopic.php?t=10181

I haven't made this run properly in my plane, but I have used chunks of it as starting points for my own programs.

Are all microprocessors this strange? I've found the Microchip PIC hard work. For example, I couldn't see why the radio inputs were being corrupted, until I re-read the PIC datasheet note, about not using "polling" when using "interrupt on change". I suppose these quirks are the trade off for functionality.

I also discovered that my Spektrum radio sends the servo pulses, very tightly packed, in the order 2, 6, 3, 4, 1, 5. Other radios might send them simultaneously, so the program mustn't depend on those assumptions.

I still haven't switched the gps into SIRF mode successfully. TinoR6's routines to set & decode the NEMA strings work fine.

I've decided that I want to control the roll servo properly, instead of the rudder. I've fitted the board vertically into the back of a Multiplex Mentor. The fuselage is huge, but I had to carve some foam away to create the cavity. The orientation change makes the yaw gyro becomes a roll gyro, and the fore-and-aft accelerometer is now vertical.

I'm waiting for better weather to test my latest changes.

scouser

[scouser]

Fakhre Alam asked:

"How fast this board can decode GPS data. Is any one tried it."

In both NEMA and SIRF modes the highest fix rate that can be requested is 1Hz.

In NEMA mode, the yellow led flashes when a fix is transmitted and that is every 2 seconds.


scouser

[FAKHREALAM]

Fakhre Alam asked:

"How fast this board can decode GPS data. Is any one tried it."

In both NEMA and SIRF modes the highest fix rate that can be requested is 1Hz.

In NEMA mode, the yellow led flashes when a fix is transmitted and that is every 2 seconds.


scouser

PLEASE LET ME KNOW, IS THIS BOARD WORTH BUYING ?.
IS ANY ONE TRIED IT WITH THE MODES AVAILABLE ?, IS AVAILABLE CODE WORKS IS AUTO PILOT MODE ? IF YES HOW GOOD IT IS, ANY ISSUES ?.

FAKHRE ALAM