Jump to content
Daniel Wee

My little NAV/OSD project - under construction

Recommended Posts

Hello Daniel, Mark.

Can you post here when can we order and where? i will check the thread regulary now.

Edited by mugur

Share this post


Link to post
Share on other sites

Hi Mugur,

You can't purchase anything anywhere yet, the boards haven't been made yet. We'll make a post when we have a better idea of the time frame for when they will be available.

- Mark

Share this post


Link to post
Share on other sites

Perhaps this is daft, but I note the groundspeed vs. airspeed issue on a few of these demos. How tricky would it be to interface a small airspeed board like the the airspeed expander from the add-on range for the Eagletree Micro Logger? Cheap, and the daisy-chain interface looks straightforward... although I guess Eagletree may be a bit coy about the details...

Share this post


Link to post
Share on other sites

It's possible I suppose, depends on the sensor - whether it's digital or analog. May need to re-work the software a bit. This is open source so I'm sure even if I didn't do it, someone would! That's the great thing about open source code. You can flash different versions of OSD as you like when they become available. So far, I've not had a great need for air-speed although I can see how it can be useful. My original idea was to keep this thing as simple (and therefore affordable) as possible. (Even if I sold 50 of these, I can barely buy an diversity receiver or two.) But a good quality OSD with expansion possibilities, that's the goal. So if there's something you want to add, it should be possible. The CPU has lots of processing power left over and the dsPIC30F4011 which I will be using has more free pins. One issue that could be a problem though, is that the SPI port is being used by the BOB-4 and there's no addressing so basically a scheme has to be had for daisy chaining the different SPI devices. Either that or bit-bang a general purpose I/O for SPI. Hopefully without the need to disable interrupts.

Daniel

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

I've the mentioned Eagle Tree expansions in use (height, airspeed, servo current, memory expansion, etc.) and they are daisy chained via I2C not SPI (too many /CEs :D), each of the sensors have a tiny I2C ADC onboard but not the memory expansion of course (see attached pic).

//Erwin

post-6-1189683290_thumb.jpg

Edited by helitron

Share this post


Link to post
Share on other sites
they are daisy chained via I2C not SPI

Helitron, do you know if anybody has published the protocol for Eagle Tree's I2C interface? I guess, if one knows the amplifier model it's possible to pull it off the manufacturer's datasheet.

Share this post


Link to post
Share on other sites

Helitron, do you know if anybody has published the protocol for Eagle Tree's I2C interface? I guess, if one knows the amplifier model it's possible to pull it off the manufacturer's datasheet.

No, unfortunately not, I tried to find it. But I think there should be no protocol, only standard I2C communication. There is a datasheet for the I2C ADC, the real name of the device is LTC2481 from Linear Technology. But as Daniel mentioned above I think also it would be cheaper to make your own board.

By the way, I just ordered this tiny pressure sensor for only $9.90 for trying:

http://www.futurlec.com/HP03D.shtml

is also a I2C device.

Cheers,

//Erwin

Edited by helitron

Share this post


Link to post
Share on other sites
By the way, I just ordered this tiny pressure sensor for only $9.90 for trying:

That's a good find, but there is no diff sensor for the airspeed indication.

If EagleTree's protocol is replicated it will open the way to use any of their sensors and their prices are reasonable. If that's indeed a LTC2481 chip, than hooking to it is just a matter of reading Linear's datasheet. They say LTC2481 will send three 9 bit packets for each data sample - I don't know if that's a universal standard but it sounds pretty easy.

Sorry if I am taking this thread off its target.

Share this post


Link to post
Share on other sites
Hi Mugur,

You can't purchase anything anywhere yet, the boards haven't been made yet. We'll make a post when we have a better idea of the time frame for when they will be available.

- Mark

Thank you Mark. I know i can't buy it yet. That is why i have asked if it is possible to post here when and where...

Edited by mugur

Share this post


Link to post
Share on other sites

Daniel Wee, i am really amazed by your project. The 5Hz GPS combined with pixel-resolution scrolling on the compass, and with UAV-capabilities too, makes it the best OSD-solution aviable in my opinion. I would like to build my own right away. What programmer do i need for the dsPIC30F-series? I use a lot of PIC16-series microcontrollers, but i guess my simple JDM-programmer is not enough for the dsPIC30F-series. I can see you are planning on using a 4011 instead of the 4012? I sampled both from Microchip, the 4011 in standard PDIP packaging, and the 4012 in SOIC packaging (maybe i'll make the first SMD DragonOSD? ;) ), just to be sure. I plan to make my own PCB-layout, so i am also wondering if the schematic on page 7 still is up to date? By the way, how does the DragonOSD autopilot perform in low altitude? When i first saw your project, i was very sceptical of only using a GPS for UAV-capabilities (no pressure sensor, piezo-gyro, thermopile-sensors or anything like that), but after seeing your videos it sure seems to work very nice. Have your ever had any troubles with the autopilot?

By the way, check out my project, EOS1. I have created

a thread here on RC-Cam and a video is aviable here.

Edited by jonpet55

Share this post


Link to post
Share on other sites

Hi jonpet,

Thanks for your nice comments. A couple of things - let me answer them one by one:-

1. The chip I am intending to use for the SMD boards is the dsPIC30F4011. It's not very much different in price and has an extra UART and several extra ADC pins and other resources. The only catch is that it comes in a TQFP44 packaging which makes it hard for guys who want to breadboard this thing. The 4012 will work just fine for that as the two parts are pretty much identical from a software point of view. You only need to compile with the 4011 id that's all. So, 4011 will work as will the 4012. 4012 if you're breadboarding, 4011 if you like SMD and need more pins for your own use.

2. The schematics are pretty much the same BUT I have now re-designed the circuit to use fewer components, about 10 less, and now runs on 3.3V instead of 5V. I have actually made a prototype but need a few more parts which I will get this Monday, to complete the prototype. I will then test to see if the new design works as well as the old design. Other than that, there were some design changes which I wrote up in some of the subsequent articles, relating specifically to the 2N3906 as a level shifter. You should incorporate those changes into the old schematic. I probably should release an updated schematic but I'll only do so after I've tested the revised design. The boards that will be sold will be using the improved design.

3. The autopilot works well but there are some caveats. It doesn't do well if the plane does not have some inherent stability, meaning it works better with planes that have dihedral or polyhedral wings, for example. It cannot tell if it is upside down so a strong gust of wind could potentially throw its orientation off. For this to work, ideally, the changes and movements should be slow and gentle. As such, I have implemented this primarily as a "fly-home" feature rather than a full UAV multi-waypoint system (which it could do actually since I have included the basic code for it). What will REALLY help is if you have a stabilizer either using a thermopile or a gyro/accelerometer based system. But even without that, the rate of turn and rate of climb based corrections will still work for normal navigation. It is very sensitive to the GPS performance though, and for this reason, I am recommending the EB-85A's with the latest firmware. I've tried to confuse the new firmware GPS but have been unable to do so thus far. However, when used properly - ie. properly tweaked and plane is correctly trimmed, and not in overly strong winds, the autopilot has worked every time.

There is room for improvement in the autopilot code but I opted for a safe implementation. My original implementation was acting directly upon data feedback. For example, if it wanted to turn left, and wind was preventing this, if would continue to increase aileron until it overcame the wind to achieve desired rate of turn, or reach maximum throw. This was pretty aggressive but caused some problems when GPS readings were not spot on. So I went with a less aggressive algorithm but that meant that it could not counteract wind effects as well.

This whole thing started out as a theory - since I already had the board and the GPS, I figured why not? I can test this out without paying any additional money and only need to write some sort of loop in software. I wondered if it would work, and how well. So when the thing started working, after lots of tweaking of the code and parameters, I was really happy. Lots of people didn't try this because of the assumption that it would not work but I had nothing to lose. Lesson learnt: Never say die until you have tried it. It's not perfect but it's good enough for the job. I believe it might be Occam who said that it was a sin to do with more what can be done with less. I later found out that guys like U-NAV are probably doing the same thing, except that they're charging an arm and a leg and have no OSD to boot.

4. The board can be programmed in several ways. You can program the chip directly and then plug it into the board. Or you can use any ICD2 compatible ICSP programmer (I use the Olimex ICD2 programmer) and plug that into the programming header on the board. Alternatively, you can use a bootloader (I am thinking of one of the public domain bootloaders) which will cost you about 120-bytes of program space but then allows you to upload a hex file directly from the serial port through the GPS port (with a suitable level converter). I've not tested this yet but there is no reason why this should not work, and may be the way to go for most people. Personally, I like and use the ICSP header to program this thing.

Lastly, your EOS1 project is great! If my country wasn't so small, I'd be inspired to try something similar. Those lower space photos are just great.

Daniel

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

Thank you for your great answer and the positive feedback on my project!

I think that answered about everything I thought was unclear.

The 4011 is aviable in both TQFP44 and DIL40, so you could actually breadboard the 4011 too, but then size is the problem... The 4012 is aviable in DIL28 and SOIC28. SOIC28 is not that hard to solder (while TQFP is close to impossible to solder by hand), so I think i will go for the 4012. By the way I use an Olimex programmer too; the PIC-PG1 (I'ts on time buying a new one). ;) I bought a FMA Co-Pilot yesterday, so i'll combine it with the DragonOSD. I have an EM-411 GPS laying around too, but i want a smooth compass and a good autopilot, so now i have to buy an EB-85A too... Is it easy to change the GPS-baud rate to 4800 baud in case i want to test it with the EM-411? About the PCB; I think I'll wait designing a PCB until you release the new schematic, so i'll just use a weroboard for now.

Again; really impressive stuff! Can't wait to get my Microchip samples...

Edited by jonpet55

Share this post


Link to post
Share on other sites

Yes, some of the modules come with 4800 as default, but even if it's not, it's quite easy to change the baud rate. Note that the EB-85A uses the MTK command set so if you EM-411 does not use the same command set, there could be problems. You could, of course, easily change the command strings yourself since the source code is available to all now.

Daniel

Share this post


Link to post
Share on other sites

Ok, i was actually wondering if it was easy to change the baud rate on the DragonOSD, not the GPS.

Jon Petter

Share this post


Link to post
Share on other sites

Looking for some feedback here - what do you guys think about the onboard CR2032 powering the GPS as backup? This will allow it to start warm rather than cold, and get a lock more quickly. Do you feel this is necessary?

Currently, the board is 1" by 3.5" (26mm by 89mm). If I got rid of the CR2032 holder, the board can actually be made considerably shorter. On the other hand, the current board sizes matches the BOB-4SG size perfectly and can be stacked with spacers. This, I think, makes mounting easier - 1 combined module, rather than 2 boards. Do you guys prefer a smaller board - maybe without the battery, or perhaps a similar sized board but with more resource pins available for your own programming. Is having the memory backup important to you at all?

Daniel

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

I think that if the board size is currently the same as the BOB-4SG, then I say leave it on. What's the thickness of the two boards stacked together?

Regarding the extra resource pins: could they be used to later implement more external sensors? If so, then keep them!

Share this post


Link to post
Share on other sites

The thickness of the stacked boards depends on your spacer I suppose. In my case, the maximum height - ie. from the tip of the highest point to the tip of the lowest component is between 19-21mm. It looks like this:-

DSC_6445.jpg

DSC_6446.jpg

That measurement would include the length of the connector pins. Excluding those, board to board is only about 8-9mm. This photo is of my own prototype and so it's still using the dsPIC30F4012 in the PDIP packaging. This is NOT the production board. The actual board we're getting is much nicer than this. I put this one together just to test if the concept works. I've not soldered on the voltage regulator yet but as you can see, much of the space is taken up by the CR2032 battery holder, the various connectors, and the voltage regulator.

I haven't brought out the spare pins as yet but the new MCU will have the ability to take on another two analog sensors, say a temperature sensor for example. For the barometric sensor, you will need an external high resolution ADC and that can be done through a OneWire interface, for example. The board is actually pretty compact - even with the TQFP44 packaging. I'm having a hard time routing it all on just two sides. I really should do a 3 or 4-layer board.

Lastly, I am thinking of making maybe 10-sets (maybe 20, depending on demand) of DragonOSD with BOB-4SG's ready to go. Basically, you just need to provide power, camera, transmitter. No need to solder the interconnects between the boards. I'm thinking of including the EB-85A with the set - all for about $270 (DragonOSD, BOB-4, EB-85A). Anyone interested in something like this? [bOB4 - $105, EB-85A, $99, so the DragonOSD is about $66 only]. The board by itself should be about $95.

Daniel

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

Personally, I'd leave it the same size (same as the BOB4) remove the battery, replace it by a small ultracap (that uses about 1/4th the area) and fill the space with pins/pads.

Edited by Kilrah

Share this post


Link to post
Share on other sites

That's a good idea, I'll probably incorporate that at some point in the future. I saw a 1F cap but it's about the same size as the CR2032 so I didn't bother with it, plus I don't know how long the cap will last.

Daniel

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...