15 replies to this topic

[FredericG]

I was wondering how to tune my CC in a fixed wing. What I would like to use trimmers on my TX to modify some PID settings in flight.

I see two approaches:

A. Do it on the flight side. We would need new settings that dictate what spare channels control what settings with what boundaries.
B. Do it in the ground side. GCS would periodically receive the current channel input values and translate that to settings that are transmitted to the flight side

MK has such a feature on the flight side, but it is very clumsy as one cannot specify the boundaries.

I think option B provides most flexibility, but more latency

Frederic

[peabody124]

If we do it I vote for A because half the people doing this will want to do it in a way that doesn't require GCS.

HOWEVER I still maintain this feature should not be rushed into the master branch. I think in the long run we will have lots of features like this which people want and it will make the code fairly clunky. I also anticipate in a year or two we'll be mostly often with tablet for this sort of thing so no need to bloat the code.

The way I would architect it though that might end up reasonably clean will be to define a ManualControlSettings enum for "ExtraChannelMode" where we can define arbitrary sets of mappings. The have a switch statement on that enum that calls

extraChannelStabilizationTuning(ManualControlData * cmd)

For example. This will generalize nicely for people doing pan tilt as well. Once we have python scripting working properly this will be greatly simplified- there will be one function called and what it will do will depend on the python script loaded. This has always been the long term plan to implement these features.

Also as a warning. When I did this a long time ago one technical annoyance that raises it's head is that when you change a setting that causes an ACK'd update on telemetry. If you make that occur at 50 Hz you will hammer telemetry. I would probably make that setting update at 5 Hz, either by a modulo counter or better by comparing the system time to the previous update.

[Gary Mortimer]

I think you would want it to use either sliders or pots in the TX not the actual trims you might well have used them to get the wing flying nicely by hand.

Perhaps data mining a hand flown log would be better. After all if you can fly it around fine by hand you ought to be able to gain some data?

[peabody124]

Dale has some code that will analyze a log from a flight where you basically run it unpleasantly unstable. However I'm not sure that's how most will do it. In PT we found tuning in the air fairly easy for planes. More risky for quads since they won't fly themselves if you make a mistake.

Then again I've tuned my plane without TX plenty of times. Just toss, fly a loop, land, tweak. Repeat till awesome.

[Les Newell]

It strikes me that what we really need is some easy way of implementing plugins. In this case the plugin simply needs to read an unused channel, apply scaling and range checking then route it to a UAVObject. If you want this functionality, install the plugin. There is certainly no need to start hacking around with ManualControlSettings and it's associated code.

As I see it there are three possibilities for plugins:
1) selected at compile time. This is the easiest but the least user friendly.
2) Dynamically loadable modules. Very powerful and flexible but needs storage. OP has the SD card but CC could have a problem.
3) Support scripting. This gives the most code bloat and has CPU load issues. Lua is about the fastest and most compact of the common scripting languages but even so it may be too much. Same storage issues as option 2.

[peabody124]

Les Newell, on 06 May 2011 - 11:44 PM, said:

1) selected at compile time. This is the easiest but the least user friendly.
2) Dynamically loadable modules. Very powerful and flexible but needs storage. OP has the SD card but CC could have a problem.
3) Support scripting. This gives the most code bloat and has CPU load issues. Lua is about the fastest and most compact of the common scripting languages but even so it may be too much. Same storage issues as option 2.

Strictly speaking 2 would work well since we have plenty of spare flash and FreeRTOS can support time-time modules. 3 is where I see the long time future being and Dean Hall (wrote PyMite) has been playing with our hardware.

[Les Newell]

In that case my vote would be for option 2. I think it would also make sense for most of the modules to be run as plugins. There are lots of great ideas for OP but the problem at the moment is that every configuration has to be compiled in at the same time. Even now a lot of good ideas are being scrapped or put on hold simply because they would contribute towards code bloat. This is only going to get worse. Having loads of Git branches scattered around is all very well but it is likely to end up a nightmare to administer.

For plugins to work properly, you would really need dynamic UAVObjects as well. I know this all involves a lot of boring architectural redevelopment which is not nearly as much fun as flight control development but I really think it needs doing.I know I keep harping on about this but it is important.

I think that is the main thing I got right with FlightOS. The combination of flexible module configuration and dynamic inter-module comms makes development and custom configurations easy. Admittedly the modules have to be selected at compile time on FlightOS but that is purely due to the severely limited resources on an AVR.

[peabody124]

Les Newell, on 07 May 2011 - 11:18 AM, said:

In that case my vote would be for option 2. I think it would also make sense for most of the modules to be run as plugins. There are lots of great ideas for OP but the problem at the moment is that every configuration has to be compiled in at the same time. Even now a lot of good ideas are being scrapped or put on hold simply because they would contribute towards code bloat. This is only going to get worse. Having loads of Git branches scattered around is all very well but it is likely to end up a nightmare to administer.

For plugins to work properly, you would really need dynamic UAVObjects as well. I know this all involves a lot of boring architectural redevelopment which is not nearly as much fun as flight control development but I really think it needs doing.I know I keep harping on about this but it is important.

We actually already have both of these abilities, we just don't use them. The object manager is entirely dynamic in terms of object registration (of course the complete set of object must be defined at compile time, but they don't have to all be registered). We just don't really use this feature. We've talked about switching registration to something that occurs during module initialization.

The modules themselves, can also easily start and stop. There are two main mechanism for this. With modules that have their own FreeRTOS task you can start/stop/resume/suspend tasks at will. For modules whose functionality is implemented through UAVObject callbacks, those callbacks can be registered and unregistered. This would be an example of a reasonable thing to run as a separate module, it can register a callback on the ManualControlCommand and then when desired update StabilizationSettings. However, you still need to handle somehow knowing if someone wants to register that callback at startup. Stac has been working in the background on code to make most of the configuration of the hardware occur dynamically too. This will allow things like swapping the FlexiPort from USART to I2C. Part of this will be launching the appropriate modules.

However, until all that is done and working properly, I stand by putting these things in branches instead of kludging it all together with tons of conditionals somewhere.

[FredericG]

Today, selecting the modules you wan to have in is already very simple, but it is at compile-time via the MODULES (I introduced that )

MODULES =  Actuator Telemetry GPS ManualControl Altitude AHRSComms Stabilization Guidance FirmwareIAP FlightPlan
#MODULES += Osd/OsdEtStd

Indeed, our architecture has what is needed to load modules in from flash. But still, for this problem you still need to transport the settings in a uavobject.
I do like the idea of doing this in a pyhton script at the flight side, this is very flexible, but this will not be for CC

I believe you discard too quickly the option to do it in GCS.
Ok, you need GCS at your side while tuning, but I think it also has advantages. It could be made available very soon and it does not have any influence on the flight code.

Frederic

[peabody124]

FredericG, on 08 May 2011 - 04:56 PM, said:

I believe you discard too quickly the option to do it in GCS.
Ok, you need GCS at your side while tuning, but I think it also has advantages. It could be made available very soon and it does not have any influence on the flight code.

I certainly have no objection to implementing on GCS. I'm just saying that will satisfy about half the people that want this feature, maybe even less. It does alleviate most of the other problems though.

[FredericG]

I was thinking about a plugin in GCS, while James was mentioning a flight python script.

But, this made me think, I can now also write pyhton script at the ground side

So a made a little prototype of the concept, I will see how well it helps me tuning my new CC plane

This little script allows me to change the Ki value of PitchPI between 5 and 25 with a knob on my radio..

while True:
 	try:
            	# get update of ManualControlCommand 
            	objMan.ManualControlCommand.getUpdate()  
            	
            	# calculate value out of Accessory1 input (-1 ... +1)
            	txControl = objMan.ManualControlCommand.Accessory1.value
            	value = 15 + txControl * 10
            	objMan.StabilizationSettings.PitchPI.value[0] = value
            	objMan.StabilizationSettings.updated()
            	
            	print "\r%-1.2f => %2.4f" % (txControl, value),
            	time.sleep(.1)
            	
	except TimeoutException:
            	print "Timeout"

Frederic

[Gary Mortimer]

I know thats awesome Frederick but as ever I am a little far behind.

Just so I know whats happening, you are talking to the GCS via an Xbee and flying with a normal TX

As you fly your moving a slide or rotary dial and that changes the PIDs for stabilization.

It then leaves them at the setting you find the best.

I know you can use the GCS as it stands to adjust in flight but that assumes we have a friends who can on hand!

Most excellent work Frederick.

[dankers]

This is exactly why I wanted Python scripting on the flight side, its a unique to OpenPilot and means the platform is very expandable with scripts.

[CheBuzz]

While flight scripting is an awesome and advanced feature, I believe FredericG wrote this to run on the ground side. So what I see as happening is that Frederic is using his pyUAVTalk implementation to receive ManualControlCommand objects, and then sending StabilizationSettings objects back to the plane. No GCS required, just this script running with some sort of telemetry link to the airborne.

You could pretty easily extend this script so that upon pressing the space bar or some other key, you would now be changing pitch Kp. And so on...

[FredericG]

Gary Mortimer, on 17 May 2011 - 07:26 PM, said:

As you fly your moving a slide or rotary dial and that changes the PIDs for stabilization.

Exactly. This is only done while tuning; once the optimum point is found it is fixed.

Gary Mortimer, on 17 May 2011 - 07:26 PM, said:

Just so I know whats happening, you are talking to the GCS via an Xbee and flying with a normal TX

It's a bit different.
Somewhere in the system, some code has to take the value of one of the aux-tx-channels and influence one of the PID parameters. The discussion we had was about the different options where this code could reside. Options that where mentioned:

• in a plugin in GCS
• in some (dedicated) C-module on the flight side
• in some dedicated python code on the flight side (not available yet, and will only be in OP, not CC)

What I have done here, is still another approach where I made a small python script at the ground side. So this script takes the place of GCS, and could be seen as a Proof-Of-Concept or a prototype of a GCS plugin but does not integrate with GCS in any way.

This is one of the thinks python is very good at, prototyping and tooling IMHO

Gary Mortimer, on 17 May 2011 - 07:26 PM, said:

I know you can use the GCS as it stands to adjust in flight but that assumes we have a friends who can on hand!

Exactly. With CC there are only 6 input channels. 4 control channels, 1 flight-mode switch, so this leaves me with just one parameter I can tune from the TX at a time... that's a pity.

[FredericG]

CheBuzz, on 18 May 2011 - 04:59 AM, said:

While flight scripting is an awesome and advanced feature, I believe FredericG wrote this to run on the ground side. So what I see as happening is that Frederic is using his pyUAVTalk implementation to receive ManualControlCommand objects, and then sending StabilizationSettings objects back to the plane. No GCS required, just this script running with some sort of telemetry link to the airborne.

Correct

CheBuzz, on 18 May 2011 - 04:59 AM, said:

You could pretty easily extend this script so that upon pressing the space bar or some other key, you would now be changing pitch Kp. And so on...

Yes, lots of options