Is the MatrixPilotQuad code flyable ?

[Igal R]

Is the MatrixPilotQuad code flyable ?

Any info on this ?

[William Premerlani]

Igal,

MatrixPilotQuad is flyable, but be warned that it is "under construction", changes on a daily basis, and there are no instructions yet for it in the Wiki.

At this point, the only function is provides is stabilization, and it has only been tested on a custom platform that Ben and I have built, picture attached. The reason that it is in the repository is so that Ben and I can work on it together. It has not yet been tested on the ArduCopter platform. 

Ben and I intend to work on it over the winter, and hope to have a released version in the spring.

Best regards,

Bill

[tshado]

Hello Bill,
Thanks for this status on Matrixpilot on Quadcopter
I have been posting some questions in UAVHELIBOARD discussion group
but it was difficult to get as much details

Best regards,
Jean-Claude

>  DSCF1283.JPG
> 2002KViewDownload

[Igal R]

I have a frame that i can test.

If i will use UDB4 the outputs are 1,2,3,4 ?

 

 

 

בתאריך 21 בנובמבר 2011 15:03, מאת William Premerlani <wprem...@gmail.com>:

Hi Igal,

Yes, the quad is in a + configuration.

Basically, the platform is a "Draganflier" without the electronics. The company, rctoys, sells the frame.

http://www.rctoys.com/rc-toys-and-parts/DF-COMPLETE-AIRFRAME/RC-PARTS-DRAGANFLYER-FRAME.html

You would also want to get the extra bracing.

http://www.rctoys.com/rc-toys-and-parts/DF-FrameBracing/RC-PARTS-DRAGANFLYER-FRAME.html

Total cost of the frame plus bracing is $135 US

Best regards,

Bill

On Mon, Nov 21, 2011 at 7:38 AM, Igal R <iga...@gmail.com> wrote:

As far as i can see the quad is in + configuration ?

בתאריך 21 בנובמבר 2011 14:32, מאת William Premerlani <wprem...@gmail.com>:

[ben levitt]

Hi Igal,

Just so you know, the code here:

   http://code.google.com/p/gentlenav/source/browse/#svn%2Fbranches%2Fquad_testing%2FMatrixPilotQuad

has not been tested yet.  It is a refactoring of the code here:

   http://code.google.com/p/gentlenav/source/browse/#svn%2Fbranches%2Fquad_testing%2FMatrixPilot

which has been tested by Bill and myself.  But the MatrixPilotQuad code will hopefully be tested, adjusted, and moved to trunk for further development sometime this week.

Ben

[Adam Barrow]

Bill / Ben,

 Thanks for all the updates on the progress of MatrixPilotQuad. If I were going to start trying to help, where would be the most assistance? Also, do you feel it is really important to use the same frame at this stage in the development? I already have a different Quad frame (Gaui 330X) that I've been flying with a separate stabilization unit, but would rather start converting to true UDB control.

Regards,

Adam

[William Premerlani]

Team,

Regarding the working version UDB quad controls.

First of all, this is a work in progress, so if you use it, you will be on the "bleeding" edge. Enough said.

Next, Ben is correct, for the moment, the tested version is http://code.google.com/p/gentlenav/source/browse/#svn%2Fbranches%2Fquad_testing%2FMatrixPilot

In other words, use the MatrixPilot directory and project for now, and watch the repository for changes.

Regarding quad frames, the present code has been tested with very light carbon frame, with 4 small brushed motors. I will eventually test with ArduCopter frame. If you want to test with other frames, knock yourself out, but you might have to adjust the gains. Right now, they are in the file servoMix.c:

#define ROLL_KP 0.04

#define PITCH_KP 0.04

#define ROLL_KD 0.8

#define PITCH_KD 0.8

#define YAW_KD 0.8

#define ROLL_KDD 0.8

#define PITCH_KDD 0.8

#define ACCEL_K 1.0

KP are proportional gains

KD are rate gains

KDD are second derivative gains (they dampen wobble)

ACCEL_K dampens vertical movement

Input channels:

1: roll

2: pitch

3: throttle

4: yaw

Output channels:

1. Front motor

2. Right side motor

3. Rear motor

4. Left side motor

Front and rear motors should spin counter clockwise.

Left and right should spin clockwise.

Configuration is +.

Front of UDB faces front of quad.

No GPS, no magnetometer. Just a UDB.

OpenLog is optional. Baud rate is 115200

Right now, software will run on either UDB3 or UDB4.

On power up, software will record offsets and trims when LED stops flashing. Tx should have sticks at neutral trim, throttle all the way off.

At the moment, the controls engage right after offsets and trims are recorded, so be careful, the motors will be "twitchy". Although they will not spin very fast, they might spin a little bit. This is on my list of things to fix, but I am not in a hurry about it, I have an old Futaba Tx, and I solve that with the throttle trim tab. I set the tab to mid range before power up, and then set it to "full off" after trims are recorded.

Once again, it really was not my intent for anyone to be using this yet, but as long as you understand the controls are very crude at the moment, go ahead and use them, if you want. Just be very careful.

Best regards,

Bill

[Riccardo Kuebler]

Hi Bill, Ben,

is it planned to support x configuration too ?
I always flew with this configurations and am wondering if I could stay with that or have to change my way to fly quadcopters.

Best regards,

Ric

2011/11/22 William Premerlani <wprem...@gmail.com>

[Igal R]

I have configured everything without props.

It looks like front motor should be connected to channel 3  back motor to channel 1

Right  motor to 4 and left moto to channel 2 and had to reverse the elerons in my JR9303

My board type is  RUSTYS_BOARD

Tommorow i will install props and see how it flys .

The first thing to do is to add some kind of arming and disarming procedure .

Multiwii you must hold rudder right and thorttel min for 2 second to enable motors to spin .

And to disarm you must hold rudder left and motor min for 2 seconds.

Hope tommorow we will se liftoff.

בתאריך 22 בנובמבר 2011 03:00, מאת William Premerlani <wprem...@gmail.com>:

[William Premerlani]

Hi Igal,

I just double checked the wiring of the motors on my quad, you are correct, the motor channels are:

1. rear

2. left

3. front

4. right

So, the motor wiring is exactly flipped front/back and left/right from what I said in my previous posting. Sorry about that.

For yaw stabilization to work, front and rear motors must spin counterclockwise, left and right clockwise, as looking down on the quad. If that is not the case, then you must flip the sign of the yaw stabilization.

Best regards,

Bill

[Peter Hollands]

Team uavdevboard,

I would like to add a few comments to Bill's answers to this thread. It is clear that there is a great deal of pent up demand for the UDB to be used for Quads. Pent up demand for Quads, could result in an avalanche of support questions, so I think we, as a group,  need to be careful.

I would ask that we keep the following in mind:-

• a) recognize that the current quad code is not meant for normal user consumption yet. It is alpha code meaning that it is going to have many more features added before a formal release is made.
  
•  b) try to  keep quad support questions away from Ben and Bill, and let them be free to develop the code, so that a formal launch  can be made later.

As we all know by now, Bill is an amazing engineer in our R&D department. He is able to construct new insightful mathematical models that in a commercial setting would see many valuable patents being registered. And then, he is able to both design electronics,  write code, and debug the detail, until the maths work in reality. Ben is incredibly good at structuring code fast to be modular, reusable, and can write functional code that is easy to support, at a great speed. Ben can extract unbelievable functionality from the dspic series, and innovates with features like the On Screen Display code, and the ability for MatrixPilot to support many different types of air frames, as well as  hovering and inverted flight.

These days, when users have problems, quite a few of the other core members of uavdevboard try to answer those questions. We do that so that Bill and Ben can do what they are  really good at, and that is also what is fun for them .... innovation.  However, their nature is always to try and help people, and to share knowledge. So they are always being pulled both ways.

Its just fine if people want to start using the nascent quad code in the repository. That is the beauty of open source. But that code is nascent R&D, it is not productised, and is therefore not suitable for lot's of support. At the moment, Ben and Bill have identical quad hardware, so that they can be concerned with pure R&D and not the engineering development associated with supporting lots of different types of quads (That will come later).

So the point of this post, is not to stop people from experimenting. That is super. But please a) recognize that the current code is alpha (lot's of features still need to be added), and that is not meant for normal user consumption. b) Ideally, we should keep quad support questions away from Ben and Bill, and let them be free to develop the code, so that a formal launch of productized code can be made later. Once the formal code is launched, then we can collectively provide support, with code that is more feature complete, and with Wiki documentation in place.

I expect that Ben or Bill may want to comment with their own thoughts on this topic.

Best wishes, Pete

[William Premerlani]

Hi Peter,

Thank you very much for your comments about Quads. You are spot on.

The only point I would like to emphasize is that the code it not meant for normal consumption yet. Functionality is very basic, there is no documentation, and no arming/disarming function. I think the average user will run into problems if they try to use it now. For example, Igal recently pointed out that the motor channel assignments were not what I thought they were. Everything was backwards. He must have figured that out by ground testing without propellers. If he had gone straight to flight testing, his quad would have quickly flipped over, because the roll and pitch feedback would have been positive instead of negative.

So, I would prefer that average quad users be patient, and resist the temptation to connect the UDB to a quad. Please wait a bit.

For advanced users, you are welcome to try out any Quad code that is in the repository if you want to, but I will not be able to help you if you run into problems or have questions. Be very careful, do not make any assumptions, and do plenty of ground testing with the propellers off before you attempt any flights.

Best regards,

Bill

[Igal R]

You turn any quad + to x just by setting up delta wing or elevons in your RC TRANSMMITER .

You should't change anything , not that the UDB will be facing 45 degrees side ways in the direction of the motor that was the forward motor .

 

There will be a problem in way point mode.

 

בתאריך 22 בנובמבר 2011 18:32, מאת Riccardo Kuebler <kue...@ticino.com>:

[markw]

Hello All,

This is my first post to the group, although I have been lurking for a while. I have been working with the V2 ArduIMU in a 6' Telemaster for the past year or two (mostly adding bugs to the code) and have worked in the past as a Systems and Electrical Engineer and as an embedded systems programmer.  I've been interested in RC since the early 70's, and fly both fixed wing and helis.

First, thanks to all those who have contributed to this group and to the Wikis; they are extremely valuable resources for experimenters.

I have recently acquired a UDB4 and installed it in an AeroFPV frame, following the example described on the MatrixPilotHeli Wiki. I would also like to reiterate Bill's caution to be careful in experimenting with a platform the size and power of the AeroQuad copters; it is my opinion that a manual failsafe mechanism is advisable which guarantees manual override of all ESC inputs via the transmitter. I use a 4 channel mux to select between the UDB outputs and the RX throttle channel output.

I'm also working my way through Peter Hollands' recently posted "Intro. to MatrixPilot Interrupts" (thanks Pete) while learning the code, and would like to contribute my initial observations, in hopes that they might be useful to others, especially those using the UDB4 version of the code:

The UDB4 supports up to 8 PWM inputs, on Input Capture pins IC1-8, and 8 PWM outputs on Output Compare pins OC1-8.

radioIn_udb4.c:udb_init_capture() sets all input capture interrupts to priority 6. 

INT0Interrupt: 

The pulsewidth check is conditionally compiled into the FAILSAFE_INPUT_CHANNEL ISR, not necessarily channel 5  (FAILSAFE_INPUT_CHANNEL is defined in options.h).

All PWM input ISRs trigger at twice the radio frame rate.  Since my Spektrum DX7 frame rate is 45Hz these ISRs fire 90 times per second in my UDB.

T4Interrupt:

This chain of up to 9 interrupts is triggered by servoOut.c:start_pwm_outputs() which is called from the heartbeat ISR background.c:_T1Interrupt() at 40Hz. Since each interrupt generates the falling edge of one pulse and the rising edge of the next (in _T4Interrupt()), there is only one interrupt per output PWM channel. It seems that the dsPIC33F's Output Compare module PWM mode would eliminate the need for this ISR.

T5Interrupt:

dsPIC30F intructions may take one to three clock cycles (FRM:CPU page 2-28). T5 counts down from 4K to 0 then generates an interrupt which increments _cpu_timer. Since timer 5 runs at the instruction clock rate (16MHz) it counts down to 0 in precisely 4096/16 = 256 usec of wall clock time.  This gives _cpu_timer a resolution of 256usec. Since the _T1Interrupt() ISR reads (and resets) _cpu_timer at 40Hz, or every 25msec, cpu load is _cpu_timer * 256 / 25000, or approximately _cpu_timer percent. (in udb_init_clock() why not load PR5 with 16*250=4000?)

PWMInterrupt and T3Interrupt or (UDB4) T6Interrupt and T7Interrupt:

On the UDB4, PWMInterrupt is renamed to T6Interrupt and T3Interrupt to T7Interrupt. 

These names are defined in the C30 support header file for the specific dsPIC processor e.g. p33FJ256GP710A.h for the UDB4. Documentation is in the C30 Compiler User's Guide (DS51284F-page 103).  The compiler automatically fills in the interrupt vector to point to the interrupt function when the specified names are used. Note that these ISR names are referenced nowhere else in the code; the ISRs are referenced only through the addresses loaded into the Interrupt Vector table(s).

Happy Holidays,

Mark Whitehorn

[proc_rock]

Hi everybody,

Co-incidentally, I just got my quad copter with UDB4 off the ground
tonight. Could not do much because of the enclosed space and fear for
our lives (see link below).

http://www.youtube.com/watch?v=KxIuImkUwSE

One thing that I did run into - I had to swap front and back, and left
and right channels - my mistake. I must have been looking at UDB3
quad copter documentation by mistake. All is good when using the
options.h file. Here are the stabilization settings that worked,
albeit a bit wobbly:

#define ROLL_KP 0.3 //up from .1
#define PITCH_KP 0.3 //up from .1

#define ROLL_KD 0.4 //down from .8
#define PITCH_KD 0.4 //down from .8

I'm guessing with these a bit since I have zero experience with UAV or
even RC planes.

I'm taking copious notes, and will post those when I've gotten a bit
further along.

Now that I've got it off the ground, I'll take a step back and design
a better frame and use more appropriate props. Here's my hardware set
up:

Motors: Turnigy 2217 20 turn 860kv 22A Outrunners
ESCs: Turnigy Basic 18A
RC: Spektrum DX5e
PVC/plumbing parts
3SP1 20C 4900 mAh lipo (about .5 kg)
8x5 props

What a great project you guys are doing. I can't imagine the time
you've put in.

--
Sean

[William Premerlani]

Hi Sean,

Nice to hear you have your quad working...I looked at the video, it looks like the gains could still use a bit of tuning.

I assume that you are using the latest version of the quad software from the repository, (1123 or newer), and that you are working out of the MatrixPilotQuad subdirectory. It is a work in progress, very rough at the moment, I will post here whenever I make significant changes.

Regarding the motor channel sequencing, I had it backwards at one point in the documentation. So, if anyone is trying to use the code, do a lot of ground testing without props before you try any flights. When you tip one of the arms of your quad down, the motor on that arm should speed up.

Both + and X configurations are supported.

Right now, the default gains are for a small quad that I built using the carbon rod frame of a "draganflier". So you will likely have to use other gains.

KP gains are proportional, KD are rate gains.

KDD are rate of change of the gyros, I found that just the right amount of KDD suppressed the tendency for the quad to wobble.

Best regards,

Bill

[William Premerlani]

Hi Sean,

Nice to hear you have your quad working...I looked at the video, it looks like the gains could still use a bit of tuning.

I assume that you are using the latest version of the quad software from the repository, (1123 or newer), and that you are working out of the MatrixPilotQuad subdirectory. It is a work in progress, very rough at the moment, I will post here whenever I make significant changes.

Regarding the motor channel sequencing, I had it backwards at one point in the documentation. So, if anyone is trying to use the code, do a lot of ground testing without props before you try any flights. When you tip one of the arms of your quad down, the motor on that arm should speed up.

Both + and X configurations are supported.

Right now, the default gains are for a small quad that I built using the carbon rod frame of a "draganflier". So you will likely have to use other gains.

KP gains are proportional, KD are rate gains.

KDD are rate of change of the gyros, I found that just the right amount of KDD suppressed the tendency for the quad to wobble.

Best regards,

Bill

On Fri, Dec 30, 2011 at 1:59 AM, proc_rock <sean.b...@resonatesolutions.ca> wrote:

[William Premerlani]

Everybody,

I forgot a couple of things that might of of interest to any of you who are experimenting with the quad software:

1. You should be using the quad_testing branch of the repository, MatrixPilotQuad subdirectory.

2. There is some debugging data that comes out at 115,200 baud. It would help me if you could capture some data from some of your flights and send it to me.

Best regards,

Bill

[proc_rock]

Hi Bill,

Yes, I'm using the quad_testing branch of the current repository (a
few days old), with my own copy of options.h. Glad to send you data -
how long of a data capture would you like? This frame/prop set up
does not have much of a future. It's quite heavy and props are not
tuned for the motors. Would you rather wait until I have a more
middle of the road set up?

Thank you for the info

--
Sean

[William Premerlani]

Hi Sean,

Wait until you have a better setup before you capture any data.

Mostly what I am interested in looking for is signs of a wobble instability. It will show up quite clearly in the data, if there is one.

Typical wobble frequency is in the range of 0.1 to 4 Hz, so about 1 minute of flight time is all I need.

Best regards,

Bill

[markw]

Hi Sean, 

Thanks for posting your system details and the video.

Here's my configuration:

AeroFPV frame from AeroQuadStore.com

Motors: KD A22-20L 1050KV

ESCs: Turnigy TY-P1 25A

OrangeRX 9ch receiver (Spektrum compatible)

Spektrum DX7 TX

GWS 10x4.7 tractor props

APC 10x4.7SFP pusher props

flying weight ~1300 grams with 3S 2100mAH LiPo

Total current on 3S in hover is 19A for 192W.

Flight is fairly stable with the default PID gains (rev1143),  but bumping the ground can cause an oscillation.

--markw

[Anish Mohammed]

Hi Markw,
Quick question possibly silly one. I was wondering what the board was to the right of Udb board

Regards
Anish

Anish Mohammed
Twitter: anishmohammed
http://uk.linkedin.com/in/anishmohammed

> <AeroFPV.JPG>
> <failsafe_annotated.jpg>

[William Premerlani]

Hi Mark,

If bumping the ground is generating oscillations, I suggest trying a lower value of ACCEL_K. You could even try a value of 0.

ACCEL_K provides for vertical damping, but if the accelerometer on the UDB is not aligned horizontally with the center of gravity of the aircraft, it can generate an oscillation after a bump.

Also, so far, I have not put any integral gains in the feedback controller. That is on my list of things to do after I totally revamp the controls.

Right now the feedback is proportional, derivative, and second derivative.

My plan is to start with a fresh page for the controls. What is there now will eventually become "manual mode" to provide backup for my research on a better "stabilized" mode.

Also, everybody, I am a little surprised, humbled and a little bit frightened, at how quick some of you are exploring the quad code while it is still under construction. I will be very, very careful about what I release.

Best regards,

Bill

[William Premerlani]

Anish,

I bet the board to the right of the UDB on Mark's quad is a fail-safe mux.

Best regards,

Bill

[Anish]

Thanks Bill :).
Regards
Anish

Sent from my BlackBerry® wireless device

---

From: William Premerlani <wprem...@gmail.com>

Sender: uavde...@googlegroups.com

Date: Fri, 30 Dec 2011 20:02:45 -0500

To: <uavde...@googlegroups.com>

ReplyTo: uavde...@googlegroups.com

Subject: Re: Is the MatrixPilotQuad code flyable ?

[markw]

Hi Anish,

Bill is correct, the extra board is a multiplexer constructed using two DIP ICs, a CMOS 4013 to decode a PWM channel, and a 74157 mux. You could also use the DIYdrones failsafe mux here: https://store.diydrones.com/product_p/br-0001-10.htm

I've attached a system diagram and schematic. I'm using the gear channel on my radio to control the mux; one position selects the UDB PWM outputs 1-4 and the other (failsafe) routes the RX throttle channel to all ESCs. To connect and disconnect the battery I select failsafe and low throttle. This would come in handy if one of my code changes caused the UDB to hang and send "undefined" commands to the ESCs. Unfortunately, selecting failsafe while in flight would be a very bad idea.

--markw

[markw]

Thanks Bill,

I'll experiment with ACCEL_K after I get a feel for the effects of the P, D and DD parameters. This is my first quad, and I was never concerned about the dynamics of my Telemaster. Also, the UDB accelerometers and gyros are positioned as close as possible to the center of the frame.

I did notice what seemed to be a lag in throttle response, maybe that is coming from ACCEL_K, but then I have cheap ESCs and motors...

I noticed that you said were interested in log data; I've attached the logs from my last two hover sessions using rev1143 with the X configuration. There was a large trim error in both flights (needed forward/left stick for level hover) even though the second flight was initialized with the UDB dead level. I hope they're long enough to be useful; my system config. is described in an earlier post to this topic.

Please don't let my experimentation inhibit your development in any way; I consider it a privilege to be allowed to use your development code and will be glad to contribute to testing in any way I can. I examine each change made to the code before applying updates to my working copy.  

--markw

 

[William Premerlani]

Hi Mark,

I have not noticed lag in my throttle response. The ACCEL_K does not have any effect until the quad begins to accelerate. So, if you were to make a step change in throttle, the first thing that would happen is the props would speed up. There would be some delay in that just due to the inertia of the props.

Best regards,

Bill

[William Premerlani]

Team,

Just to keep you all updated on what I am doing with MatrixPilotQuad.

As some of you have noticed, you might observe a slight roll and/or pitch offset that you have to manually trim.

I did some measurements today to find out why. It is what I thought:

There are no integral terms in the controls yet. So any asymmetries in the motors, ESC, or the airframe, will require manual biasing.

Tests confirmed that.

So, the next step is to start with a blank piece of paper for the controls. I have some ideas....will keep you posted.

In the meantime, here is a video I made of today's test flight. Just for the fun of it, a couple of times I flew my quad a few inches away from the camera.

Best regards,

Bill

[William Premerlani]

Team,

I also uploaded the video to youTube.

Best regards,

Bill

[Wouter van Verre]

Hi Bill, 

Thank you for uploading the video. I am very much impressed by how stable the quad is. Congratulations on that!! Is the core algorithm (the dcm algorithm) the same as in the current MP repository, or did you have to improve it to achieve this level of stability?

Kind regards and good luck with the rest of your research,

Wouter van Verre 

PS: Happy new year everyone =]

Sent from Samsung Mobile

[William Premerlani]

Hi Wouter,

Thanks.

I am keeping the working code for quads in the repository, in case anyone wants to try it out. It is in the quad_testing branch. The project is in the subdirectory MatrixPilotQuad. Here is a link.

Best regards,

Bill

[Anish Mohammed]

Hi Mark,
 thanks. I did locate the same on buildyourowndrone.co.uk i shall plug my ubd4 along with mux on one of my quad frames shorlty. BTW the two frames that i have are arducopter 3 dr and quadrame ( Jakob ), motors are jdrones and 20-22 l with 10X4.5 any words of advice on PID values...
regards
Anish

[William Premerlani]

Hi Anish,

The present version of MatrixPilotQuad does not have any integrators in the feedback controls, so strictly speaking, its not a PID controller.

What it does have is proportional, derivative, and second derivative. The idea is a robust, quick-and-dirty control that will not produce any surprises. It is going to eventually be manual control for a fall back position for developing fly-by-wire.

I added the second derivative terms to suppress wobble.

Without any integrators, it will not adjust for roll or pitch bias of your quad, so you will not be able to just let go of the sticks.

I plan to start on more advance controls by combining some of Robert Mahoney's ideas with my own. In particular, I have some ideas for cleaning addressing the different biases due to wind and due to airframe bias.

One of my own ideas is a way to account for acceleration effects without making any assumptions.

Best regards,

Bill

[markw]

Anish,

That looks like the same mux board to me, thanks for the link.

Based on my experience to date, I expect you'll have to decrease the KD and KP gains from the defaults, but will have problems with biases unless your motors and ESCs are well matched, as Bill has already pointed out. Mine is capable of a stable hover with default gains, but large roll and pitch trim errors are present, perhaps due to variations in motor KVs. Yaw stability is pretty good though.

I am currently studying the code while waiting for better weather to do gain testing (today's flight was in 15mph winds at 0C). Will probably add an auxiliary input channel to allow gain adjustments in flight.

--markw

[William Premerlani]

Hi Mark,

It was interesting to hear that you were flying in 15 mph winds. The up side to not having integrators yet in the MatrixPilotQuad implementation is that winds do not cause integrator windup. The down side is that you have to manual compensate for trim errors.

As I may have mentioned, I did some tests with my quad that show the source of my trim errors is variations in motor and ESC characteristics. In my case, I am using permanent magnet, brushed motors. Each motor runs at a slightly different speed.

The next step in my plan is to implement my ideas for the controls. When I am done, the firmware should be able to separately compensate for wind and for airframe trim. We'll see

Best regards,

Bill

[Anish Mohammed]

Hi Mark,
I have ordered it, btw did think of hacking one with three way, with a second flight controller/ap :).
Shall post my progress soon :)
Regrds
Anish

Anish Mohammed
Twitter: anishmohammed
http://uk.linkedin.com/in/anishmohammed

[Anish Mohammed]

Hi Bill,

 I guess that to me sounds I need to get some help with test flying , given my flying skills :). Btw when could we expect your newer version with ideas incorporated, I am looking forward to having a matrix pilot quad.

Regards

Anish

Anish Mohammed

Twitter: anishmohammed

http://uk.linkedin.com/in/anishmohammed

[William Premerlani]

Hi Anish,

I expect to have a releasable version of MatrixPilotQuad done in the spring. Between now and then I will be adding various features a step at a time, doing research as I go along, so I cannot give you a schedule. Actually, my plan was to work on it without telling anyone or letting anyone use it until it was finished. But I decided that the best place to keep the working software is in the repository, so I was not able to keep it a secret.

The next step will be to implement a non-linear, DCM based control "engine" that everything else will be based on. Attached is an outline of the basic idea. At the time I started thinking about it, it was in terms of fixed wing. But the same concept will work on quads or VTOL. The idea is to specify the evolution of the DCM in time, including its rate of change. So, what I have to do next is create a "fly-by-wire" that will convert pilot inputs into the values in the attached. If I don't get too distracted, that will probably take another month. But please do not make any plans that depend on it.

Then there will be integration of dead-reckoning computations.

Next, a brand new idea for accounting for acceleration. (Document also attached.)

Then, the things that build on top of that, such as loitering and waypoint navigation.

Somewhere along the line I will add barometer and ultrasound.

Also, somewhere along the line I have some ideas for further improving the accuracy of attitude estimation.

My goal will be to squeeze as much performance as possible out of a simple airframe and as few sensors as possible by solving "insanely hard" math and physics problems.

I use a research approach, so it is difficult to say when things will be done. Sometimes I when I am working on one idea, I get distracted with another one.

Best regards,

Bill

[Mark Whitehorn]

Thanks Bill,

I've made a few small code changes that solved the trim issues for me and have found values for KP, KD and KDD that work fairly well for hovering. I've noticed that hovering in ground effect is a much greater challenge than out of ground effect. For my airframe, the (indoor) ground effect threshold is about 3 feet. Here's a link to a YouTube video from one of today's outdoors short tests: AeroFPV/UDB4 test.

On integrator windup: If I understand correctly, you need to change the control mode to fly-by-wire (changing the PID setpoint)  instead of injecting loop error proportional to manual inputs.

I also need to implement a low-voltage alarm; when one (or more) ESCs hit the low-voltage cutoff, the results aren't pretty.

Thanks for the opportunity to play with this, it's a lot of fun and props are cheap,

--markw

--
Mark Whitehorn
kd0...@gmail.com

[William Premerlani]

Hi Mark,

Thanks. You are absolutely correct, the way to eliminate integrator windup is to change the control mode to fly-by-wire. I am going to implement that next for roll and pitch, add the integral terms, test it, and then update the repository. After that I am going to revise the yaw control so that the yaw rotation response will be around the earth Z axis instead of the body Z axis.

It will be interesting to see what KD and KDD will do to the manual input. (The change to fly-by-wire will have the effect of adding these terms for the manual inputs.) It should provide a more lively feel to the controls, but it might also generate a lot of noise as well. We'll see.

Best regards,

Bill

[Mark Whitehorn]

Bill,

I expect that fly-by-wire will feel a lot safer, since the system can impose limits on bank angle and stick deflection can directly command those angles. If the control loop has sufficient bandwidth, it might even eliminate the problems in ground effect. 

I see that some heli tail servos accept a PWM frame rate of 280Hz. I also read here: http://aeroquad.com/showthread.php?419-Modifying-an-ESC-s-firmware-to-support-higher-pwm-input-rate

that "Most ESCs will handle up to around 400Hz without any problems". 

Have you considered whether increasing the motor PWM frame rate would be useful?

regards,

--markw

--
Mark Whitehorn
kd0...@gmail.com

[William Premerlani]

Team,

I have revised the quad_testing branch, MatrixPilotQuad. r1156 now has fly-by-wire control of pitch and roll, and KI feedback. I just did some testing, I was able to take my hands completely off the controls, the KI feedback automatically trims out pitch and roll offsets in 10 to 20 seconds. I used a fairly low KI gain, 0.01. The time constant of the trimming is approximately equal to KP/KI.

Also, I suppress the controls until the throttle is at about 20%. That keeps the integrator from winding up while the quad is on the ground, and it also keeps the props from twitching in response to moving the quad around prior to flight.

I did not change yaw control, its still the same. I intend to completely change how that works, to fly-by-wire control in which commanded yaw is executed in earth frame of reference. That will make turning during forward flight a lot easier.

Best regards,

Bill

[William Premerlani]

Hi Mark,

Regarding frame rate, so far I have not seen any issues related to that, performance at this stage is much better than I thought it would be. I will wait and see if I run into any problems because of frame rate, I will consider raising frame rate at that time. Some of the ideas that I intend to implement should work just fine without needing to raise the frame rate. We'll see.

Best regards,

Bill

On Thu, Jan 5, 2012 at 9:46 AM, Mark Whitehorn <kd0...@gmail.com> wrote:

[markw]

Bill,

I just did a test hop with the 1156 code and just had to remove the
expo I had programmed into my transmitter to get more control
authority at center stick.

Your fly-by-wire code is definitely more stable than the previous code
and really shows off the capability of the DCM code to maintain
orientation.

My quad is now destined to become an FPV platform.

many thanks,
--markw

> >http://aeroquad.com/showthread.php?419-Modifying-an-ESC-s-firmware-to...

> > that "Most ESCs will handle up to around 400Hz without any problems".
>
> > Have you considered whether increasing the motor PWM frame rate would be
> > useful?
>
> > regards,
> > --markw
>

> > On Wed, Jan 4, 2012 at 9:06 PM, William Premerlani <wpremerl...@gmail.com>wrote:
>
> >> Hi Mark,
>
> >> Thanks. You are absolutely correct, the way to eliminate integrator
> >> windup is to change the control mode to fly-by-wire. I am going to
> >> implement that next for roll and pitch, add the integral terms, test it,
> >> and then update the repository. After that I am going to revise the yaw
> >> control so that the yaw rotation response will be around the earth Z axis
> >> instead of the body Z axis.
>
> >> It will be interesting to see what KD and KDD will do to the manual
> >> input. (The change to fly-by-wire will have the effect of adding these
> >> terms for the manual inputs.) It should provide a more lively feel to the
> >> controls, but it might also generate a lot of noise as well. We'll see.
>
> >> Best regards,
> >> Bill
>
> >> On Wed, Jan 4, 2012 at 10:02 PM, Mark Whitehorn <kd0...@gmail.com> wrote:
>
> >>> Thanks Bill,
>
> >>> I've made a few small code changes that solved the trim issues for me
> >>> and have found values for KP, KD and KDD that work fairly well for
> >>> hovering. I've noticed that hovering in ground effect is a much greater
> >>> challenge than out of ground effect. For my airframe, the (indoor) ground
> >>> effect threshold is about 3 feet. Here's a link to a YouTube video from one

> >>> of today's outdoors short tests: AeroFPV/UDB4 test<http://www.youtube.com/watch?v=JNipI2wAgm8&context=C3662c5cADOEgsToPD...>
> >>> .

[William Premerlani]

Hi Mark,

Good to hear. I appreciate the testing that you are doing.

By the way, I just committed a minor improvement to Quad, it is available in r1158: I have incorporated the KD terms for roll and pitch control into the fly-by-wire, so the fly-by-wire control is now PID. In the version that you just flew, the fly-by-wire was just PI. The D term in fly-by-wire provides a feed forward signal that improves the roll and pitch response to commanded step changes in roll and pitch. I think you will find the new controls much more responsive than r1156. I invite you to try r1158 when you get a chance, see if you like it better.

Best regards,

Bill

[Mark Whitehorn]

Bill,

I flew for a few minutes with rev1158 and noted quicker reaction to control inputs, but it felt like one or more of the gains might now be too high. I expect they were borderline before. I'll try reducing gains for my next flights since stability is now quite high.

I've attached the telemetry in case you want to look at it. My logs are showing a fair number of bad records, I wonder if my cheap 2GB SD card is too slow.

The training gear is off now: http://youtu.be/zQOnVTZEMlY

thanks,

--markw

--
Mark Whitehorn
kd0...@gmail.com

[John McClelland]

Hi Mark

 

Just following your progress.  Is your Quad an AeroQuad?  Looked like it from the video.  Jerry Chapman and I started working on these with a modified version of MP a while ago.  We had a wiki on the development at http://code.google.com/p/matrixpilotheli/wiki/QuadContent  The release code was just bare bones for stabilization.   I had implemented a dev version of the code with altitude control using a fusion of a sonar sensor for low altitudes and a baro for high.  

 

We both got side tracked, but I plan to get back to it.  Sounds like Bill’s code is a much better way to go.

 

I had some problems with the motors “clicking”, almost like an arc down periodically.  I was using Turnigy 18A ESC’s and BP 2217-9 motors.  Did you ever experience this?

 

John

 

---

From: uavde...@googlegroups.com [mailto:uavde...@googlegroups.com] On Behalf Of Mark Whitehorn
Sent: Friday, January 06, 2012 4:11 PM
To: uavde...@googlegroups.com
Subject: Re: Is the MatrixPilotQuad code flyable ?

 

Bill,

[William Premerlani]

Hi Mark,

Glad to see you took off the training gear....I thought about using training gear during my research, but I never got around to it. So far, there has been only one broken propeller, when I my son-in-law tried out the very first version, and he flew my quad into wall...

The feedback computations are exactly the same in rev1156 and rev1158. The only difference is the addition of a feed-forward KD term for roll and pitch. So the stability behavior should be exactly the same, but certainly the controls will have a much different feel.

After you are satisfied with your gain tuning, I would be very interested to know whether you prefer rev1156 or rev1158.

Best regards,

Bill

[William Premerlani]

Hi Mark,

By the way, thank you so much for taking the videos, they are a big help. And thanks for the feedback, I appreciate it as well. Its always useful for me to hear the opinions of the users.

I am going to work on improving the yaw control next. I plan to implement a heading hold function, similar to that provided by heading hold gyros that helis use.

Best regards,

Bill Premerlani

[Mark Whitehorn]

Hi John,

Nice to "meet" you. Yes it's an AeroFPV frame from the AeroQuad store and thanks for the wiki, it was probably what pointed me to AeroQuad in the first place. I happen to have an ultrasonic sensor that's been sitting around since the 70's (original Polaroid dev. kit) and saw use on an RC truck a decade or two ago. Time to get it out again for the auto-land task.

Before I got started with my UDB4 I noticed that Bill had newer code in the gentleNav repository, so I started with that. It does seem to be working well and I hope you and Jerry are able to get back into the quads soon.

On ESCs and motors, I bought what HobbyKing had in stock at the time: Turnigy TY-P1 25A ESCs and KDA20-22L motors. One of the motors has a little play in the bearings (the other 4 seemed perfect) and I burned one winding after dunking a motor or 3 in the snow, but the motors seem to all be reasonably well matched and to date have survived perhaps 20 or 30 minutes of hovering.  Since those motors are only $12 each, they might be worth a try.

--markw

--
Mark Whitehorn
kd0...@gmail.com

[Mark Whitehorn]

Bill,

Flew again with KP reduced from .09 to .07 and KD and KDD both reduced by about 20%.

That smoothed out the response and it definitely feels better now. I'll vote for 1158.

thanks,

--markw

--
Mark Whitehorn
kd0...@gmail.com

[Daniel Gmail]

Hi. Keen start again with this quad code. 

Few questions. 

I just need to download all the files from quad branch?

Will it support udb 2?

Is it only stabilize function not no gps module needed?

Thanks. 

[William Premerlani]

Team,

Be careful with flying your quad in a circle, MatrixPilotQuad r1158 is not ready for that yet. The present version is intended for hovering and/or straight line flying only.

During circling, there are acceleration effects that cause errors in the estimation of the level position. I have figured out how to compensate for acceleration in quads, but I have not implemented it yet.

So, be careful if you fly in a circle, it could put your quad into a death spiral. The best thing to do is to yaw align the quad with the earth, not with the direction of flight. That should help.

If you align the quad with the direction of flight, there will be a constant error in the accelerometer vector in the quad frame of reference that will eventually cause trouble.

If you align the quad with the earth, the error in the accelerometer vector in the quad frame of reference will change in time, and the average error over a complete circle will be zero.

Best regards,

Bill

[William Premerlani]

Hi Dan,

Download all the files from the quad_testing branch. Open the project under the MatrixPilotQuad subdirectory.

It should support all versions of the UDB, including the green board, but it has been tested only on UDB3 and UDB4.

I am note sure how well a UDB2 will work with a quad. The issue is vibration. The UDB3 and UDB4 are vibration resistant, the UDB2 is not. So be careful.

If you have the green board, select the board type as GREEN_BOARD.

If you have the red board with the vertically mounted LISY gyros, select RED_BOARD.

You do not need a GPS or a magnetometer. All you need is a UDB.

Best regards,

Bill

[Anish]

Hi Bill,
Thought of dropping in a line about ur post on diydrones about Henrys's post on quarternian's. I know both Henry and Yuan, I am impressed with their enthusiasm and drive. I do admit that have been very good to me, have given me friends and family discount on frame, forebrain and seraphim :) hence I got to play with it.
I wouldn't rank their expertise in hardware (electronics) or programming or mathematics as much as their enthusiasm :) Thought I should share this with you, as there is a small chance you might have thought of them as mathematically very saavy folks (professional mathematicians ), hence you sharing your thoughts on computational optimisations etc.
Regards
Anish

Sent from my BlackBerry® wireless device

---

From: William Premerlani <wprem...@gmail.com>

Sender: uavde...@googlegroups.com

Date: Sun, 1 Jan 2012 21:51:59 -0500

To: <uavde...@googlegroups.com>

ReplyTo: uavde...@googlegroups.com

Subject: Re: Is the MatrixPilotQuad code flyable ?

[William Premerlani]

Hi Anish,

See my recent comments on diydrones regarding the recent post on quaternions.

DCM and quaternion representations are entirely equivalent. You can transform back and forth. There is no difference in accuracy or transient response.

In the present version of MatrixPilot, I actually use both representations. In my opinion, in most cases, DCM is the most convenient representation to use for most of the computations we do in MatrixPilot, but there are a couple of places were quaternions are more convenient, so I do the conversion.

Computing quaternions is a little bit more efficient computationally than DCM, but in MatrixPilot the amount of CPU power used on computing DCM is less than 1%. The largest CPU loads are from communications and A/D conversion.

As a minor point, I note that it is not necessary to do either divide or square root in the renormalization process for either DCM or quaternions. You can use a Taylor's expansion instead.

Also, when I first started out, I was careful not to use divide or square root very much in MatrixPilot, because divide takes 17 CPU cycles, and square root takes a lot more than that. But we found that the architecture of MatrixPilot and the PIC that we are using are very efficient with regard to CPU loading. The single CPU on the UDB4 is currently at about 10% loading, and it is doing the work of the 3 CPUs in the latest version of the Ardu system.

Best regards,

Bill Premerlani

[William Premerlani]

Team,

By the way, if anyone wants to continue this discussion, I have started a new thread:

http://groups.google.com/group/uavdevboard/browse_thread/thread/b7cd42a5974682a1

Best regards,

Bill

On Sat, Jan 7, 2012 at 10:46 AM, Anish <anish.m...@gmail.com> wrote:

[markw]

Correction on the motors, I actually have KDA20-20L motors rated at 1020kV.

The quad is hovering on 24A at an all-up weight of 1620g and the motors don't even get warm pulling 6A each.

--markw

[Daniel Tan]

Team, I am providing you an alternative to a nice simple frame which is Carbon rod arm with fibreglass center plate.

 

http://www.multircshop.com/site/index.php?route=product/product&path=36&product_id=54