16 replies to this topic

[peabody124]

Currently the output mapping is fairly limited.  I'd like to propose a change with two goals.

1. Allow modules to directly control output channels, bypassing the actuator module.  This will allow up to have more output channels that mixer channels.
2. Abstract away the output type from the API

Modules:
Actuator renamed to Mixer.  The way we will configure output channels will now be to explicitly map a driver and output to a mixer line.  It will claim the outputs you configure them and use them, but things like camera stabilization can also claim them.

PIOS_Output: a new common PIOS API to talk to any output type
PIOS_OUTPUT_SetChannel(uint32_t driver, uint32_t channel_number, float channel_value, task handle)
PIOS_OUTPUT_ClaimChannel(driver, channel, task_handle) - prevent multiple writers (ideally should pass in a task handle).
PIOS_OUTPUT_ReleaseChannel(driver, channel, task_handle) - needed if we change configuration

driver structure exposes the relevant set function function, eg
const struct pios_output_driver pios_servo_output_driver = {
.write = PIOS_Servo_Set,
};

PIOS_Servo: the PWM output specific implementation.  It will have additional functions
UpdateFrequency -- this is modality specific so should be configured as such?
SetRange (??) -- where should the scaling be handled.  I'm thinking in this level of the driver and the input can be a float.

PIOS_ESC: This will be an output layer optimized for our ESCs

PIOS_Buzzer: Output layer for buzzers

So basically this will make it a bit easier to extend functionality without hacking the actuator module.

The GCS output configuration will need a fairly heavy rewrite to take this into account.

----------------

Questions:
1. Things like UpdateFrequency for PWM output.  Where should that be handled in the firmware?  I think we add a board specific file that installs various callbacks on settings.  ActuatorSettings becomes renamed to PWMOutputSettings.

---------------

Pros: this will expand our flexibility a lot more with custom modules etc

Cons: now that lots of places are directly talking to outputs they will all need to be aware of safety issues like arming/disarming.

What do you guys think?

[peabody124]

I should have pointed out I'll take care for the FW rework but I'll be picking someone from the GCS volunteers thread to work on the GCS rewrite.

[PT_Dreamer]

Shure that sounds great, it will increase flexibility a lot witch is a good thing
The only concern as you referred is safety. Perhaps when an output is configured the function may have a boolean safety field that when true requires an "armed" status when that output is set.

[peabody124]

That's true, and it could be checked at the driver level.  I like the idea, it would just depend on the efficiency of querying the armed status for each output channel update though.

[cinekopter]

400Hz PWM Output for digital Servos   ---and i go crazy---- - for a standalone Gimbal-Steering...like picloc did it...

...thats my Vote !....possible ?..or in the Future?

..sorry...

[peabody124]

We already have 400 hz output.

[Tallak Tveide]

How about irda for still image. Either time lapse or triggered by receiver input

[peabody124]

Please try and keep this thread on the technical implementation details.  Not feature requests .  However the motivation behind this is extensibility like camera triggers and all sorts.

[Kenn Sebesta]

peabody124, on 10 December 2011 - 07:17 PM, said:

Cons: now that lots of places are directly talking to outputs they will all need to be aware of safety issues like arming/disarming.

It's kind of scary that all output modules not have a central kill point. Surely there is some way to send their output through an assert or something which checks that the system is indeed armed.

By the way, at the same time we can fix the armed/disarmed/motors inactive language problem.

[peabody124]

Well currently they do.  It's just a matter of do we move that kill control into the lower driver level (which isn't meant to know about UAVO's so that's really out)

Can you link to the previous discussion?  Armed currently only has a significance for some classes of actuator.

[Kenn Sebesta]

peabody124, on 10 December 2011 - 09:05 PM, said:

Well currently they do.  It's just a matter of do we move that kill control into the lower driver level (which isn't meant to know about UAVO's so that's really out)

Can the API to the lower driver level be written such that it requires two values, one the actual PWM output and the other a flag? The flag that's passed would be the currently armed state, and would be a magic number such as (pulling it randomly out of thin air) 0x5F1A2307. This of course we be given in a define. This way if the command looks like

flag=1;
setout(100, flag);

it fails an assert and if it's given as

flag=currentArmedState;
setout(100, flag);

it passes an assert. So it's not single point control, but it makes it very easy to catch by the precompiler (search the module codes for this value and throw a compile-time error if it's found anywhere else but in the only spot permitted) and very hard to get around except by extreme conscious choice (at which point it's your business anyway what you're doing. Your code ain't getting into 'next', that's for sure.)

peabody124, on 10 December 2011 - 09:05 PM, said:

Can you link to the previous discussion?  Armed currently only has a significance for some classes of actuator.

Disarming does not completely disarm the vehicle. Should it?

[jes1111]

On the issue of "armed", could we have actuator types assignable to groups, each of which has an "arming switch". A gimbal with high-torque servos can be just as dangerous to your fingers as the props, but you wouldn't necessarily want it subject to the same arming switch as the motors. Similarly, you may want a PWM buzzer operable independently of any arming switch. So: Motor Group, Gimbal Group, Misc Group, etc.

Re: frequency, if one implemented actuator groups as above then it could/should be possible to nominate an update rate "per actuator type per group", e.g. PWM Actuators in the Motor Group => 50Hz, PWM Actuators in the Gimbal Group => 333Hz.

What about the related "back channel" on actuators - I2C from OP-ESCs, etc - and its objects/frequencies?

Re: what you say about claiming outputs - would that leave it possible to assign more than one actuator to a particular task? e.g. gimbal roll axis might require two servos, each of which will have its own end- and neutral- points.

[peabody124]

Well currently I anticipate the arming will still happen at the module layer.  So for example the Mixer module will be aware of some of the types of outputs listed in Kenz' link and arm them appropriately.  The camera stabilization module could have it's own arming considerations instead of relying on what the Actuator module does currently.

As for update frequencies that's very hardware specific.  For example all the time on CC the PWM outputs are actually set at 530 Hz ( the rate of stabilization ).  However, the pulse only occurs at whatever the pwm output rate is set at.  These aren't a free parameter and are grouped based on the timer they are hard-wired too.  Other drivers would have similar considerations.  Some form of grouping logic like that could be implemented at the level of GCS but wouldn't make as much sense in the firmware layer.

For the ESC back channel that will basically be an addition set of functions exposed via the PIOS_OPESC_ driver layer, and then a Module which communicates with this.  I've already started working on this bit.

[stac]

I took a stab at this a while ago but got mired in the details of the (unfamiliar) actuator/mixer code and dropped it.  I'm sure you'll have a much better chance of pulling this apart.

This will be a huge improvement.

peabody124, on 10 December 2011 - 07:17 PM, said:

PIOS_Output: a new common PIOS API to talk to any output type
PIOS_OUTPUT_SetChannel(uint32_t driver, uint32_t channel_number, float channel_value, task handle)
PIOS_OUTPUT_ClaimChannel(driver, channel, task_handle) - prevent multiple writers (ideally should pass in a task handle).
PIOS_OUTPUT_ReleaseChannel(driver, channel, task_handle) - needed if we change configuration

Scaling

One possibility would be to handle scaling in the PIOS_OUTPUT_SetChannel function.  The "float channel_value" could be a value from 0-100 percent of max.  Each of the underlying drivers would then need to provide a ".getrange" function call that would give back the HW min/max values for that [driver + channel_number].

When the upper layers call PIOS_OUTPUT_ClaimChannel(), the .getrange() call could be made once and saved so that subsequent calls to PIOS_OUTPUT_SetChannel() could properly scale to the HW range.

Putting the scaling into the PIOS_OUTPUT layer allows us to handle things like user-configurable limits on travel generically outside of the driver in units that are independent of the actual output used.

PIOS_OUTPUT_SetUserLimits(driver, channel, min_percent, max_percent, task_handle)

This would have nothing to do with the actual HW limits but rather deal with things like "don't turn this servo less than 12% or more than 73%" scenarios.

const struct pios_output_driver pios_servo_output_driver = {
   .write = PIOS_Servo_Set,
   .get_hw_range = PIOS_Servo_GetRange,
}

Disarming

I think it makes sense for arming/disarming to be handled above the PIOS_OUTPUT layer.  Here are some supporting arguments:

• Comments asking for different groups (motors vs. camera stab vs. etc) of outputs to have separate arm/disarm settings.  Seems like a reasonable request to me.
  
• Each controlling module can have a different set of criteria for when to be armed/disarmed.
  
• Controlling modules will each have a different idea about what it means to be disarmed.  Motors go to zero, camera stab goes to neutral servo outputs, weapons GPIOs go to "don't launch missiles" :) etc.  "Safe" is not one particular state.

What the PIOS_OUTPUT layer needs is the idea of channel "locked".  PIOS_OUTPUT_Lock() would mean that subsequent calls to PIOS_OUTPUT_SetChannel() would be ignored until a corresponding call to PIOS_OUTPUT_Unlock() would be called.  If you want to be completely paranoid, you could give the user a "secret/combination" when they "lock" the channel, and then ignore calls to "unlock" unless they pass you the result of the "lock" call.

On disarm, each module could call:

PIOS_OUTPUT_SetChannel(some_safe_value);
the_secret = PIOS_OUTPUT_Lock();

To rearm, each module could call:

PIOS_OUTPUT_Unlock(the_secret)

This leaves the policy for what it means to be disarmed to each module but also adds some enforcement of the locking into the PIOS layer.

Quote

Questions:
1. Things like UpdateFrequency for PWM output.  Where should that be handled in the firmware?  I think we add a board specific file that installs various callbacks on settings.  ActuatorSettings becomes renamed to PWMOutputSettings.

I think the update frequency of the PWM output groups could maybe be put into hwsettings.  It's the sort of thing that you can only really configure on groups of PWM pins anyway.  In the GCS output configuration dialog, we could display this as a readonly attribute for each PWM output.  In the hwsettings, we would have read/write control over the frequency for groups of PWM pins.

[peabody124]

Great points Stac. I'll forward with this.

Scaling
I like the idea of handling it in the output layer with a callback.  However, I'm not sure about a separate SetUserLimits because that means there will be two settings for each range and I'm not sure what additional information it would really convey.  This does put the (-1,0,1) -> (min, neutral, max) transformation in one place though.

Also keep in mind the hardware limits (so for example the min, neutral, max pulse time) come from user configurable settings.  That means they will be loaded in some module, pushed into the lower driver, and then queried by the PIOS_OUTPUT layer.  I'm happy with this, but just wanted to make it explicit.

Disarming
Ok.  Copy on the handling it in the modules.  I think the pros here outweight the cons.  I also like the idea of a lock/unlock function - not because I think it's terribly much safer than simplying repeating PIOS_OUTPUT_SetChannel(safe_value) but because it will be clear what is happening.  I think the safety key is overkill though - who are we really trying to keep out.  I'd rather just make sure only one module claims it at a time.

Update frequency
Yeah, HW settings seems appropriate.  I think we'll end up splitting the HwSettings into an RevoSettings and CCSettings or something to be more explicit too.

[Crubier]

Just a quick post to say that the whole idea of this thread is extremely nice and will really help a lot for new/experimental uses of OpenPilot.
Furthermore, this is definitely a big leap into the compliance with the project philosophy of a modular design for many kind of uses.

Thanks, I can't wait to see that, and I can give a hand if needed.

Edited by Crubier, 13 December 2011 - 02:30 PM.

[Dado]

//Pros: this will expand our flexibility a lot more with custom modules etc

hi guyz, im not programmer but ive develop possible sollution how to for modular design, i think it would be worth a while for you to check it out, maybe you will see something that might help with stuff you are talking.

http://forums.openpi...and-fitting-ui/

flysafe