Gluonpilot Version .5 Beta

[Mitch]

This goes back beyond my short term memory so I don't know if I've changed this much since I posted it but here are links to the magnetometer and calibration stuff as of those dates!


http://www.gluonpilot.com/forum/viewtopic.php?f=3&t=16

http://www.gluonpilot.com/forum/viewtopic.php?f=6&t=28

[Tom]

Yes, it's been a while
Plans on putting the gluonpilot in your cool VTOL plane?

[magellan]

Re Incorporating a 3 axis magnetometer:

I think it would be a terrific asset to have the possibility to add a modular magnetometer like the DIYdrones store break out Jordi build around the 5843.
http://store.diydrones.com/HMC5843_Trip ... 843-01.htm
It would be good for quads and good for fixed wing too. I also like the idea of it being modular so in a fixwing, we can place it away from sources of magnetic disturbance like motors and Esc.

I know William Premerlani got it working on the UAV Devboard with great results apparently.
Since Gluon is DSPIC based, just like the UAV Devboard, I imagine we can use some of his code as a framework to make the Gluon 9 DOM (or DOF as some call it!) or use Mitch's code.
With GPS, and a good airspeed sensor, we could have a rock solid autopilot solution.
The question is, do we have enough processing power for all this hardware working together? I am too much of a noob to answer that kind of a question!
Cheers,

Olivier

[Mitch]

The magnetometer is very low bandwidth and is probably best implemented in a filter to update state estimates, similiar to the way the gps is used now. Incorporating it alone does not require a huge amount of calculation overhead. The calculation overhead is in maintaining the entire state of the system. I think the best approach with the stuff we have now is to use the existing gluonpilot simple_quaternion routine and update with the magnetometer along with the gps. I suspect that is what Tom has in mind?

[Tom]

Hi Olivier,

Because the gluonpilot is 3V3-based, the simpler board from Sparkfun is a better choice. I hope to interface it in a couple of weeks to use in my quadrocopter
Processor power is not (yet) an issue. I didn't do any real optimizations yet, and still about 25% of the CPU time is idle. Maybe this winter I'll change the kalman-code from floating point to DSP, which will be a huge increase in idle processor cycles
An airspeed sensor would be good for gain control in high winds. However, there are software algorithms to estimate windspeed... which might make an airspeed sensor no longer needed.
Gain control doesn't require a lot of processing power.

[Tom]

Yes Mitch! It won't have a lot of overhead. I have no plans yet to implement it into the kalman filter as well... no real advantages.

[magellan]

Mitch, Tom, thanks for your replies.
Looking forward to future developments.

I think I am going to order a Gluon within a month. How are you doing for stocks?
I only need the board, no GPS or FTDI cable, I plan to use an MTK GPS from the OpenPilot project.

Regards,

Olivier

[Tom]

Hi Oliver,

Only one module left! I'll start buying new components for the assembly. But from experience I must admit that this usually takes at least 2 months...

Tom

[magellan]

Hi Tom,

Are you planning to make any changes in the hardware design for your next release or are will it remain the same?

Thanks,

Olivier

[Tom]

Hi Oliver,

I'm open to all suggestions
However I would prefer to keep the gluonpilot "basic", and make all extentions on the I2C or SPI port.
I could add cheaper hardware... but then again, it would complicate the code with a lot of #ifdefs like most other autopilots out there.
Currently I'm only considering extra outputs (or should I do that using an I2C servo pwm extention board?) and an extra analog input.
Pitot tube = probably I2C

Tom