Discussion New Quadrocopter and Tricopter UAVP updated with GPS and more - UAVX!

[ta2cba]

Originally Posted by jesolins

Ba! Great! Looking forward to the report. So you are using the ADRXS610's that the MK uses? I thought most UAVP folks were using the MLX90609's now? I am still using the ADRXS300's.
Cheers,
Jim

Hi Jim,

I ordered that IMU for another project which uses ADXRS610 but I would love to try it on UAVX.The only problem is UAVX ACC inputs are I2C not Analog also yaw gyro needs an output of 0 to +5V,this IMU gyros are all outputing 0 to 3.3V.Still the combined PR gyro can be tested as it is similar to IDG300. I will test the gyros against ADXRS 300 and 610 and let you know about the outcome.

With this slim compact IMU, a daughter board with a sensor co processor like we discussed can come handy as an option.

I have two quads and one of them uses ADXRS610's from Sparkfun for the 3 gyros,flies quite okay.The other one ADXRS300's from Ken.I didn't see much of a difference in performance between them.I think I have posted one video in my early posts which is flying with ADXRS610.

My fist UAVP test was with LISY300AL Gyros from Sparkfun for roll and pitch and ADXRS610 for yaw.These performed quite well and these LISY300AL gyros are half price compared to ADXRS or Melexis gyros. I still have the first UAVP home made perf board with these gyros on,I must post a pic so that you can have a good laugh on my pcb work!

This compact IMU infact uses an upgraded gyro in the same order as LISY300AL and a decent ACC. I have a gut feeling that this might be a good compact IMU alternative for UAVX with a sensor daughter board.


Cheers,

ba

[jesolins]

Ba,
When I first got my pre-owned UAPV a couple of years ago, it had a bad pitch gyro. I substituted an NEC gyro that I salvaged out of a Warioware Twisted Gameboy cartridge and it worked fine too... It is quite adaptable.
Cheers,
Jim

Originally Posted by ta2cba

Hi Jim,
I ordered that IMU for another project which uses ADXRS610 but I would love to try it on UAVX.The only problem is UAVX ACC inputs are I2C not Analog also yaw gyro needs an output of 0 to +5V,this IMU gyros are all outputing 0 to 3.3V.Still the combined PR gyro can be tested as it is similar to IDG300. I will test the gyros against ADXRS 300 and 610 and let you know about the outcome.
With this slim compact IMU, a daughter board with a sensor co processor like we discussed can come handy as an option.
I have two quads and one of them uses ADXRS610's from Sparkfun for the 3 gyros,flies quite okay.The other one ADXRS300's from Ken.I didn't see much of a difference in performance between them.I think I have posted one video in my early posts which is flying with ADXRS610.
My fist UAVP test was with LISY300AL Gyros from Sparkfun for roll and pitch and ADXRS610 for yaw.These performed quite well and these LISY300AL gyros are half price compared to ADXRS or Melexis gyros. I still have the first UAVP home made perf board with these gyros on,I must post a pic so that you can have a good laugh on my pcb work!
This compact IMU infact uses an upgraded gyro in the same order as LISY300AL and a decent ACC. I have a gut feeling that this might be a good compact IMU alternative for UAVX with a sensor daughter board.
Cheers,
ba

[ta2cba]

Originally Posted by jesolins

Ba,
When I first got my pre-owned UAPV a couple of years ago, it had a bad pitch gyro. I substituted an NEC gyro that I salvaged out of a Warioware Twisted Gameboy cartridge and it worked fine too... It is quite adaptable.
Cheers,
Jim

Jim I totally agree on flexibility,I think it's not what you use it's all about the trimming of PID parameters and Quad parameters at the end of the day.
And ofcourse the code wolferl and Greg put together is so adaptive,it's amazing.
Btw I really like your quad frame and how neat your build looks,mine is a bit mess always!

Cheers,

ba

EDIT: I am trying to build something like this nowadays.

Lite Machines' Voyeur VTOL UAV - the real thing (1 min 2 sec)

a hand launched MAV that has a contra rotating prop system on top and a Pringles can underneath,kinda a flying pringles!I am going to replace that compact IMU with the one I am using now. It's in it's infancy still and nowadays I am just breaking props! I'll let you know about the outcome if I ever have a long successful flite than few seconds!

[jesolins]

Ba,
Well that is an old photo and since I have been using it as a UAVX testbed for the last year, it has taken on more of a Frankenquad appearance with all my re-welding and repair of the aluminum frame. That frame is too heavy to be efficient, but rugged and good for testing at higher weights representing AUW with cam equipment onboard.
Cheers,
Jim

Originally Posted by ta2cba

Jim I totally agree on flexibility,I think it's not what you use it's all about the trimming of PID parameters and Quad parameters at the end of the day.
And ofcourse the code wolferl and Greg put together is so adaptive,it's amazing.
Btw I really like your quad frame and how neat your build looks,mine is a bit mess always!

Cheers,

ba

[gke]

Back in comms range briefly! Oz is BIG and we don't have full cell phone cover yet and never will. VHF is the only thing that covers everywhere and i forgot to arrange a VHF/Internet hookup before I left.

Anyway it is good to see the constructive discussions of the last couple of days sans our real lives.

On multiprocessor support and other mods. It is a slippery slope. It is pretty clear to me that there are gains to be made by having all the sensors (and the I2C ESCs) on a single bus but only if we use the PIC I2C hardware support. Otherwise the bit twiddling to generate the waveforms swamps any gains. What it would do is reduce the noise effects, which we have not quantified, from the reference voltages and induced noise in the analog interconnections.

The NMEA processing takes a considerable amount of time and as there seems to be no consistent binary format this is probably an area for an external processor but here is the slippery slope. Do you carry most of the Nav function to the additional processor as well providing simple roll/pitch/yaw info across etc etc. An autopilot i wrote several years ago did this and it is essentially the MK solution. I posted a link to a tech report in Rusty's thread way back where all the early discussion on board upgrades also is.

I guess the overall track is to systematically work out where the gains may be had while keeping to the KISS philosophy. When I get back I will profile the code and see where the time is going. Jumping to 40MHz is something high on the list as it will allow much finer grain motor control than the 1/240 presently. This is important in camera shake. It turns out that the RC pulse capture jitter was adding a lot of motor control 'noise' up to r768.

..... Thumbs getting a little tired on my iPhone plus companion saying "we are on vacation" so back later.

Vac finishes 21 Nov - new revision shortly after.

Greg

solution

Originally Posted by jesolins

Ba,
Well that is an old photo and since I have been using it as a UAVX testbed for the last year, it has taken on more of a Frankenquad appearance with all my re-welding and repair of the aluminum frame. That frame is too heavy to be efficient, but rugged and good for testing at higher weights representing AUW with cam equipment onboard.
Cheers,
Jim

[gke]

Hi ba

Regarding telemetry. Yes I can set this up but the update rate would be the same as the GPS rate. This may not be fast enough to do any modelling of the flight dynamics but would be fast enough to do flight displays or post flight replays. I had a scheme on my other autopilot using MS FlightSim to do the displays.

Jim and I have had it in mind to do some motor/prop balancing using the accelerometers and oneidea was to do fast sampling storing it in memory for download when back on the ground with the other stats. No reason for us not to send blocks of samples down in flight as well.

We can pick up on telemetry packet formats when I get back. In the past I have used a byte for packet length first with a trailing checksum. I have code for packet drivers if you need it.

Greg

Originally Posted by ta2cba

Hi Jim,Greg,

Thank you for your heads up in EDF Uavp. I was a bit late to answer was out for a trip.For the time being I ruled out the EDF and I agree about the lack of efficieny and noise issues.I think it is simply more practical and efficient to stick with the conventional BL+Prop arrangement.

The poor man's telemetry add on to hand Terminal is almost finalized,I am working on testing with my UAVP/X.Soon will be able to release. For the time being I am getting inflite voltage and current values of lipo only from the UAVP and logging them in the hand unit to see the fluctuations of power demand while flying.

Greg, I am wondering if is it possible to output continously from one of the unused pins of UAVX pic, the gyro,acc,compass and baro values serially as raw data while in flite. I know the software is tight in coping with all the interrupts etc to keep uavx flying but still didn't put me back to ask at least if it is feasible. Even if only ACC x,y,z values can be output it would be great.

What I am after is a full telemetry to cover all these values of actual flite and log them to analyse and simulate the inflite with a Program on PC to see the full attitude characteristics of flite.

Cheers,

ba

[Sid3ways]

I'm going to be hopping into the project myself as it looks to be fantastic, I don't know why I wasn't aware of it before (although I'm new to quads). And thanks to jesolins wisdom I think I'm going to pick one up.

Figured I'd post here first to see if anyone has one for sale new or used first before I head of to Quadroufo to get the board. I'll certainly be going over this entire thread with a fine tooth comb to absorb all this great info. Just wanted to say what a great product and I'm glad to have seen it.

[Greg swiss]

Dear all

I'm back, after executing all mods, I could find here
In addition I added a simple 5v-source, which was no problem at all.

I also packed the baro sensor in foam (snowball) to avoid wind distortion,
The only problem I see, is still the warming-factor ...

In the next couple of days I try to get the quad in the air and the parameters aligned
for a stable flight...

I guess it takes me quite a bit of time, to bring the quad in the air... Let's see.

I really like your news in the meantime...
- invention of ba
- gyro cube of jim
- 40Mhz code of gke
- GPS board of don

Chapeau gentlemen

Best, Greg swiss

[jesolins]

Welcome Andy!
Cheers,
Jim

Originally Posted by Sid3ways

I'm going to be hopping into the project myself as it looks to be fantastic, I don't know why I wasn't aware of it before (although I'm new to quads). And thanks to jesolins wisdom I think I'm going to pick one up.

Figured I'd post here first to see if anyone has one for sale new or used first before I head of to Quadroufo to get the board. I'll certainly be going over this entire thread with a fine tooth comb to absorb all this great info. Just wanted to say what a great product and I'm glad to have seen it.

[jesolins]

Hi Greg,
Nice mods. It is hard to tell from your photo so I have to ask: Is that styro foam on the baro? Remember that it must be the open cel type of foam like they use on microphones to block wind noise or similar that you can get air through. Even the pool noodle foam is not good for this use.
Cheers,
Jim

Originally Posted by Greg swiss

Dear all

I'm back, after executing all mods, I could find here
In addition I added a simple 5v-source, which was no problem at all.

I also packed the baro sensor in foam (snowball) to avoid wind distortion,
The only problem I see, is still the warming-factor ...

In the next couple of days I try to get the quad in the air and the parameters aligned
for a stable flight...

I guess it takes me quite a bit of time, to bring the quad in the air... Let's see.

I really like your news in the meantime...
- invention of ba
- gyro cube of jim
- 40Mhz code of gke
- GPS board of don

Chapeau gentlemen

Best, Greg swiss

[foliage]

Greg, Jim,
Have you seen the dynamic position hold (DHP) of Microdone, can we come close to it.

dph (dynamic position hold) (2 min 49 sec)

http://www.rcgroups.com/forums/showp...postcount=1829
Jack.

[jesolins]

Hi Jack,
Yes, Greg and I emailed about this as it looks like an interesting way of refining a position hold. Personally I would want some way to disengage it too. Greg responded to this in the Quadpowered thread: http://www.rcgroups.com/forums/showt...7#post13554647
Cheers,
Jim

Originally Posted by foliage

Greg, Jim,
Have you seen the dynamic position hold (DHP) of Microdone, can we come close to it.
http://www.rcgroups.com/forums/showp...postcount=1829
Jack.

[jesolins]

Gents,
I found this very detailed site for motor and lipo set up info: http://scriptasylum.com/rc_speed/index.html I added it to my Quadrocopter and Tricopter Mega Link Index
Cheers,
Jim
Many Thanks to all the Veteran's for your service!

[ta2cba]

Originally Posted by gke

Hi ba

Regarding telemetry. Yes I can set this up but the update rate would be the same as the GPS rate. This may not be fast enough to do any modelling of the flight dynamics but would be fast enough to do flight displays or post flight replays. I had a scheme on my other autopilot using MS FlightSim to do the displays.

Jim and I have had it in mind to do some motor/prop balancing using the accelerometers and oneidea was to do fast sampling storing it in memory for download when back on the ground with the other stats. No reason for us not to send blocks of samples down in flight as well.

We can pick up on telemetry packet formats when I get back. In the past I have used a byte for packet length first with a trailing checksum. I have code for packet drivers if you need it.

Greg

Hi Greg,

Apologies for the late ans,was away for few days. Certainly a telemetry data output in the order of GPS refresh rate would be brilliant. At least it might give a chance to do after flight/during flight avionics display on PC. I see that there is still one port pin left unused on PIC,may be we can give it a try with that one if you could reroute the IMU data to that pin if you have time in coming days
I have a RF link telemetry established between the quad and hand terminal now.It is a very cheap simple 433 mhz modules based rf link working on 2400 bps manchester code.I tested it this weekend and works pretty much okay up to 200 - 300 meters. For the time being it's only transmitting lipo voltage and current while in flight. I can extend this to cover the extra data from flite PIC.

Cheers,

ba

[ta2cba]

Originally Posted by gke

Back in comms range briefly! Oz is BIG and we don't have full cell phone cover yet and never will. VHF is the only thing that covers everywhere and i forgot to arrange a VHF/Internet hookup before I left.

Anyway it is good to see the constructive discussions of the last couple of days sans our real lives.

On multiprocessor support and other mods. It is a slippery slope. It is pretty clear to me that there are gains to be made by having all the sensors (and the I2C ESCs) on a single bus but only if we use the PIC I2C hardware support. Otherwise the bit twiddling to generate the waveforms swamps any gains. What it would do is reduce the noise effects, which we have not quantified, from the reference voltages and induced noise in the analog interconnections.

The NMEA processing takes a considerable amount of time and as there seems to be no consistent binary format this is probably an area for an external processor but here is the slippery slope. Do you carry most of the Nav function to the additional processor as well providing simple roll/pitch/yaw info across etc etc. An autopilot i wrote several years ago did this and it is essentially the MK solution. I posted a link to a tech report in Rusty's thread way back where all the early discussion on board upgrades also is.

I guess the overall track is to systematically work out where the gains may be had while keeping to the KISS philosophy. When I get back I will profile the code and see where the time is going. Jumping to 40MHz is something high on the list as it will allow much finer grain motor control than the 1/240 presently. This is important in camera shake. It turns out that the RC pulse capture jitter was adding a lot of motor control 'noise' up to r768.

..... Thumbs getting a little tired on my iPhone plus companion saying "we are on vacation" so back later.

Vac finishes 21 Nov - new revision shortly after.

Greg

solution

Hi Greg,

You are so right about this slippery slope on this daughter board. I think the specs might be something like this.

- Main board - Daughter board comm via I2C hardware port between two PIC's

- Daughter board to contain all power supply and filtering necessary for main board and sensors..A RS232 level converter can also be accomodated on daughter board for GPS - PC conn for GPS setup,Thanks to Don's brilliant GPS pcb.

- Daughter board to contain Gyros,ACC,Compass,Baro,Gps,co processor pic dealing with signal conditioning and data gathering from all sensors to be passed to main board pic when acknowledged.

- Main board to keep the Receiver and BL SC connections and switches.PC connection + the higher functions flite control PIC.

I think the connection between the main board and daughter board can be limited to 4 wires.+5V,GND,SDA,SCL which can be connected via the baro/compass I2C connector. This is what came to my mind while scribbling a possible scenario schematic over the weekend. I will try to put that schematic on cad and post for your review and ideas.

I believe that daughter board can be the right answer to sort out mod issues and make the UAVX more flexible and versatile.

Cheers,

ba