14 replies to this topic

[Jean-Paul]

Hi,

I read some posts here and see that it takes a lot of processing power to decode the NMEA at 10Hz. Why don't you use the same firmware than DIYDrones which support a binary output? (http://store.diydron...p/mt3329-01.htm)

If you have a binary output you might be able to connect the GPS to the AHRS board and save one serial port on the main board.
Also I think it can be a good idea to put the pressure sensor on the AHRS board so you will have a complete AHRS/INS with all the sensors and algorithms.


Jean-Paul

[peabody124]

The advantage of NEMA is it is a standard so all GPS can be used.  For the STM32 NEMA processing is trivial and is not even on the radar for CPU usage.  The AHRS actually has serial pins available if we wanted to do that, but we wanted to keep the functionality separate for now.  

Regarding the binary protocol, it's not as widely used partly because it's buggy (see for example the recent bug they had to patch) and non-standard so it ties your firmware to that device.  You'd end up with a lot of switches in the code based on all the GPS people tried to support.  Also Dave got our firmware optimized for UAV use.

[dankers]

peabody124, on 20 September 2010 - 03:48 AM, said:

Also Dave got our firmware optimized for UAV use.

I'm writing a longer reply to this but a correction here, Angus gets the credit for a lot of this, he did the majority of the GPS testing and work.

[peabody124]

dankers, on 20 September 2010 - 04:26 AM, said:

I'm writing a longer reply to this but a correct here, Angus gets the credit for a lot of this, he did the majority of the GPS testing and work.

My bad, before my time

[dankers]

Hi Jean-Paul,

This has been debated a lot with in the project, there are a number of reasons why we did things the way we have. The first one is NMEA allows people flexibility because it is a standard so people can use their existing GPS units if they wish, it also doesn't lock us in to any on vendor so if a product gets discontinued or simply a better product is available, it allows people to use that with no problems. Additionally some people want to use very high end GPS units with the INS and our design allows that option as well as giving all of the power of the AHRS over to filtering and sensor fusion. I know some people are not so keen on NMEA however, it goes much better with the ethos of an Open platform to use standards, even if the standard isn't exactly great.

Another big issue is the wonky MTK firmware that supports binary, I am more than a little surprised and disappointed to see that on that link they are still lying about "exclusive" firmware, I am sure they paint this as "marketing" but as it is not true, I'll be honest and call it what it is, a lie. This is now fairly well known and several people have confirmed this with the actual vendor, why they persist in this dishonesty baffles me but it is telling however.

Because DIYDrones just rely on other projects to do the expensive R&D work which they just take (in our case without any credit), they never get the full picture. The binary protocol supporting firmware was around when we were testing the units, long before DIYDrones even knew what the MTK3329 was however we were warned off it because it was extremely buggy and lets be realistic here, we are dealing with UAVs which have the potential to cause injury so pushing out known buggy firmware is not at all ethical and can damage our hobby.

As their platform is 8 bit AVR based, they are very limited and are forced to use a binary protocol so they just adopted the early beta firmware and labelled it as exclusive. Additionally, that firmware is not developed by the skilled US team that did the NMEA firmware but by a local Taiwanese team, to add the binary support needed a rewrite, this rewritten firmware is not only buggy but also performs worse than the NMEA only firmware. The funny part of this is that if DIYDrones actually tested the units instead of "adopting" things and just shovelling stuff out to make money, the SkyTraq would have been a far superior choice for them as they are forced to use binary. The binary supporting firmware of the SkyTraq is much more solid and just as accurate as NMEA mode, certainly if we went the binary route at the start there is not a shadow of a doubt it would have been a SkyTraq unit. This is the huge irony, while the MTK was the perfect unit for OpenPilot, it is not the right unit for their project at all, so by just simply rushing to copy us without thinking they took the wrong turn and have ended up with very immature firmware on a critcal system component. In the long run they would have been much better just doing their own testing and I highly doubt they would have gone with the MTK as of course the firmware issues would have been obvious straight away. Of course, it is very possible that this reality has now dawned and hence are trying to just unload their remaining  bare modules to get rid of them, I would not at all be surprised and the limited time offer in your link could indicate this.  

You must also realise that OP was designed to be an incredibly flexible platform and one that is meant to last, as we are non-profit we don't have to churn out revision after revision of hardware to keep making money, this frees us up to do the right thing for end users. This again comes back to why NMEA was chosen as this way we avoid vendor lock-in and can allow people to use and test any GPS units if they want to. Of course, because of the flexibility built in to OP, it is possible to do exactly as you wish and we only need to do a software change. So, for sure adding this as an option is possible but only once the binary firmware is much more stable and is comparative in performance to the NMEA firmware, this could take MTK a while. I highly recommend not going anywhere near that firmware until it is well and truly tested and certainly well out of Beta, err I mean "exclusive" release. I fear that people who have bought them are already finding this out, lets hope no one gets hurt.

Moving the pressure sensor in this version will not happen and although it makes the OP AHRS a 10DoM unit, we do lose other functionality. Long ago when the project first started myself, Angus and Vassilis spent some time on Google Wave planning the platform, although OP's main goal is that of an AutoPilot, the hardware was designed for so much more and to be as flexible as possible. Here's the four key reasons why the pressure sensor is where it is:

1. The OP can be a complete Open Source logging platform with real time telemetry. If you look at the main board this will be obvious, the SDCard, I2C peripheral input, the GPS connectivity (another reason why it connects to the main board), the modem connectivity, the power sensor connectivity and of course the on board pressure sensor. Basically a more powerful, more flexible, lower cost and Open Eagletree style platform with the extra feature of transmitted telemetry as well.

2. A Variometer for RC gliders, this is a bit of a niche but these are normally expensive systems, see the Seagull Glide for example. It would be fairly simply to implement one with the OP main board and a pair of cheap radio modems, I know a few of the competition Glider guys and they would love something Open like this.

3. OpenPilot Light, using thermopile sensors connected to the main board, it would be possible to have a complete fixed wing AP that works well for less than $150 including all sensors and GPS, as we are using the powerful STM32 this would be by far the best price to performance ratio AP around. It might still happen but is a very low priority for the project, the issue is that is really offers just fixed wing support and we really have focused on Fixed Wing, Quads and Helis from the very start. This is also another reason why the GPS is where it is as well.

4. Support for different 3rd Party AHRSs. If you look at some thing like the VN-100 or the Paparazzi IMU they have SPI support and as is common for most 3rd party IMUs or AHRSs there is no pressure sensor. So for people wishing to use other AHRSs with OpenPilot, having the pressure sensor on the main board gives them this option and yet again also relates to why the GPS is where it is.

I hope the reasons now show that we made the right choices and gave great consideration to how the platform is designed, part of being an Open platform is to try to keep things as flexible as possible, really thinking things through and performing massive amounts of testing. Also being non-profit, we are going to engineer things to give people freedom to use parts they already have and try to force them to buy our hardware, this also reduces waste and is kinder on the environment. This also plays a factor in why we are still testing the hardware and making sure it is perfect before we release it, we don't need to shovel out over-hyped half finished stuff as soon as possible in some planned obsolescence scam, the idea is our hardware will stay unchanged for as long as we can make it last.

There has been so much care, effort, expense and thought put in to the OpenPilot platform, at least as much as a high end commercial platform and we are still refining it. I am not just replying to you but also to the other people that are interested in OpenPilot and don't see the tremendous work that the developers put in to it behind the scene. It is unfortunate that non-developers are not really aware of all this work, it should be obvious that this project has been built from the ground up, we did not just adopt another platform and rush it out as fast as possible, what we care about is the actual fun of creating something cool and something world class.

The whole idea with OpenPilot is to have fun and also to create something really truely awesome, otherwise I don't see the point of doing things. The whole aim at the start was not to create just another AP but to create a Free platform that is at least comparable to MicroPilot, this is a hard task as that platform took them years to create but things are looking good so far and all the hard work done by the people here is paying off.

[Jean-Paul]

Hi,

Thank you for your complete answer!
Now I see why the board is like that: for flexibility. You made an awesome work on the design of this autopilot. I thought it was "just" an autopilot but the hardware could be use for a lot of application!

Do you think the STM32 has enough processing power to parse NMEA + run the EFK/INS at a fast rate?

Also what about an airspeed sensor? For a fixed-wing it's much better to have an airspeed sensor. Of course we can add an I2C or analog sensor but it would be better to have the sensor on the board.


Jean-Paul

[dankers]

Jean-Paul, on 21 September 2010 - 01:41 AM, said:

Thank you for your complete answer!
Now I see why the board is like that: for flexibility. You made an awesome work on the design of this autopilot. I thought it was "just" an autopilot but the hardware could be use for a lot of application!

We also have a member here adapting it for use in jet turbines as some kind of throttle management platform, its very exciting.

Quote

Do you think the STM32 has enough processing power to parse NMEA + run the EFK/INS at a fast rate?

Depends on the algorithm complexity I think and the rate you need to parse NMEA at, however, it is far better use of the OP platform to split the tasks and allow the AHRS STM32 to be dedicated to the INS, then that issue never arises - hence the architecture we have. If we were forced to go that route, binary would be a better option because no matter how fast your NMEA parser is, a binary protocol is less overhead, in which case a SkyTraq or even a uBlox would be a better choice for a GPS unit.  

Quote

Also what about an airspeed sensor? For a fixed-wing it's much better to have an airspeed sensor. Of course we can add an I2C or analog sensor but it would be better to have the sensor on the board.

The plan is to use the EagleTree airspeed sensor, in fact the developer who originally reverse engineered this sensor for use in the Paparazzi project is one of the founders of OpenPilot. It is not on the main board simply because this sensor would not really be that useful for a Quad or on a heli so two out of the three platforms we support have little use for it. I actually see this as another huge advantage of being non-profit that we can use what is out there already without concern of losing money to other companies, this saves huge amounts of wheel reinventing.

[Matt L]

Quote

Additionally some people want to use very high end GPS units with the INS and our design allows that option as well as giving all of the power of the AHRS over to filtering and sensor fusion.

NMEA is good incase people want to use high performance GNSS receivers such as the OEMstar:
I think that I saw one for about $170. These are pricey boards.


The Spirit DuoStar-2000 is a very lightweight one:

Quote

I actually see this as another huge advantage of being non-profit that we can use what is out there already without concern of losing money to other companies, this saves huge amounts of wheel reinventing.

Reverse engineering efforts aside, Jeti makes some nice sensors: (apart from the fact that we already have these two sensors covered)



There are so many possibilities for constantly adding to Openpilot.

[dankers]

Thank you Matt!! I was not aware at all of the Jeti modules, that is very cool and another alternative as well. Actually the current sensor could be a good solution in the short term as things are still be debated about how to go with ours and we have a couple of choices about which way to go. For people that need one now, the Jeti could work very well as long as it can be reverse engineered.

[Jean-Paul]

Do you know what is the CPU usage of the AHRS & main board with the current code?

Have you chosen the MK GPS because of his speed or because of his accuracy?

For the airspeed sensor, you could put a place on the main board to sold an airspeed sensor and if people want to use it for a quad they don't sold it but if they want to use the board for fixed wing they can sold their own sensor. What do you think?

[Jean-Paul]

I forgot to ask you, what is this custom firmware which is optimize for an UAV use?

Thanks.

[dankers]

Jean-Paul,

Thanks for being here but honestly I am so incredibly busy right now so can't give a long reply, a lot of this has been talked about on the forums a great deal already, especially the GPS. The MTK3329 was used because of its accuracy due to its solid / well written firmware, there are even diagrams from independent user tests showing this on the forums as well.

Much effort has been put in to this project, the hardware has been tested over almost 10 months now and refined in a gradual process of evolution, we will not be making drastic changes to it at this late stage as it will mean much more testing and delay. The key thing we have done is all our testing internally and at my expense, we will not sell beta level stuff as it is not ethical and not how we operate. Changes to the hardware that only benefit one platform (fixed wing) and where we have a perfectly good alternative already just ain't going to happen as the testing / cost is not worth it.

[Gary Mortimer]

Somehow I missed that there was no pitot, its a must for me! If Jeti sensors could be used then perhaps they could keep talking to the Jeti box and hey presto simple telemetry for flight following. You absolutely have to have current sensing so you can work out your endurance or rather any lack of it. Why might that be? Well stronger winds at altitude. You can work out a rough distance available and choose to come home for an early bath if your UAS is not going to make the route. I forgot that multi rotor folk can't go far from home ;-)

[dankers]

I believe the Pitot support could be added in a matter of hours and you are obviously correct, it is a requirement for fixed wing navigation, this is why Vassilis added it to Paparazzi and as he is a founder of this project, I think he will want it here as well.

The current sensor is critical and is a missing piece, it is being worked on but there the first part of next-gen hardware will be making the main board quad mountable.

[Jean-Paul]

I tried to find out fews tests of the MTK gps but there is nothing on the forum.  I also googled it but haven't find anythings. Do you have tests to share please?

Thanks.