Model data

More
09 May 2012 10:48 #239 by FDR
Replied by FDR on topic Re: Model data
Telemetry:
We need support for Walera's telemetry module(s) and telemetry capable receivers, that's one protocol. But if we will support other receivers, we should support other telemetry modules and their protocols too, I guess (at least in the distant future ;) ).
So universally we need to configure the protocol, the number of values (aka channels) to receive, unit for all of them, and a configurable alarm bound to...

Please Log in or Create an account to join the conversation.

More
09 May 2012 10:52 #240 by rcH4x0r
Replied by rcH4x0r on topic Re: Model data
>>- Channel Type (analog, binary, trinary)

Probably not a good idea. It would be better to treat switches exactly the same as analogue devices i.e.

-Binary (0 & 100%)
-Trinary (0, 50 & 100%)

Have you given any thought to the design of the 'mixer'? I suspect this will be the real meat of the problem

Please Log in or Create an account to join the conversation.

More
09 May 2012 10:56 - 09 May 2012 10:57 #241 by FDR
Replied by FDR on topic Re: Model data
Oh yeah, I forgot about some settings:
- Power Amplifier;
- Fixed ID;
- Stick position switch (better would be a "Channel Value Switch");
- Timers with alarm;
- Trainer settings...
Last edit: 09 May 2012 10:57 by FDR.

Please Log in or Create an account to join the conversation.

More
09 May 2012 11:44 - 09 May 2012 11:52 #242 by FDR
Replied by FDR on topic Re: Model data
I was thinking about the file format.
I will try to describe one possible format came to my mind (it is a bit like dfu):

- It should start with some readable mime-type-like, for example 'DEVI' :lol:
- Then there should be a version first, to assure future extensibility with backward compatibility.
- after that may be the size;
- a name on fixed length;
- contents entry count;
- here begins the content table (with unified entry sizes);
- the actual binary data;
- and the last four bytes is CRC.

The key is the entry record. It would contain:
- a unique lookup string or value, which identifies a setting (group);
- data structure type, for example i8, u8, i16, u16, i32, u32, or more complex ones like curve points;
- number of such a structures in row;
- offset to that data;
- data length perhaps.

This structure probably has to be changed in the future, that's why the version number is so important. Walkera missed to version it, they may have difficulties in the future if they want to add features...


EDIT: Almost forgot, the most difficult part is that some settings are repeated by some factors we should know about. It is the channel most of the time or the flight mode, or even by both! Of course the code could know this by hardcoding the setting code, or we can include this in the entry record for a more universial approach...
Last edit: 09 May 2012 11:52 by FDR.

Please Log in or Create an account to join the conversation.

More
09 May 2012 12:23 #244 by rcH4x0r
Replied by rcH4x0r on topic Re: Model data
Certainly some magic at the front of the file is required to positively identify it as model data. I think that different model types should/could expect different model data contents - a 120 degree swash plate has no meaning to a glider after all so why include it?

A layered approach to reading/writing the model data would be a good idea. Each layer would be responsible for reading/writing a wrapper around the inner contents. The inner contents should be opaque to the lower layers and not visible to upper layers. This is very similar to the way TCP/IP packets are processed in a networking stack. Each layer would require it's own length btw.

So the lowest layer would read the 'magic' plus the type of model & the length of the inner packet. Then a layer on top that understands heli, aircraft or submarine model data. The aircraft type may then have a glider or powered type on top of that.

The benefits are that the complexity of the model data code is reduced and the size of the model data is also reduced to just that which is required.

We could consider getting away from the idea of one file per model, a database would allow far more efficient storage (most model data sets are << 4KB) but at the cost of some complexity.

The encoding problem has been solved many times by minds far brighter than us, it might be worth doing some research - Bencoding and CSN.1 spring to mind but I am not suggesting they are the ideal solution).

>>Airplane specific options
>>- Flaps switch
>>- Landing Gear switch

Some thought on how the mixer will work is definitely required before you go too far down this path. Flaps are not always binary controls (how will you let the user assign an analog knob to control the flaps if your model data expects a switch - especially if the switches have been specialised out as "on - off" devices)?

I think that the mixer would have N arbitrary inputs some of which are data inputs to a transfer function (stick position for example), some of which are control inputs to the mixer (normal, idle up 1, idle up 2 etc) and M outputs.

Please Log in or Create an account to join the conversation.

More
09 May 2012 14:42 #245 by PhracturedBlue
Replied by PhracturedBlue on topic Re: Model data
My idea for the format was probably close to what rcH4x0r has in mind. A header followed by a table describing which features are present and their offset in the file (generic data, type-specific data, location of each channel,...)
you'd then have a parser that dealt with each capability.
This makes it easily extensible (add a new type, and you can add more data).
Each data type has something similar. a list of configurations defined, followed by the data.
Thus a channel that needs no curve settings, but instead only max/min would be realy small, whereas a rudder control with separate curves for normal and D/R, trim settings, etc would be as big as needed. Again using a key to define the setting (rather than a hardcoded 'struct' format) allows for extensibility.
I understand the benefit of a database, but I am concerned it would be harder for users to manage their models since we'd need external programs to build and maintain the database, and sharing would be harder. Since we'll likely be using our own format, having the ability to easily share model data is important.

All that said, I think it is better to finish the list of what capabilities we need. It will make it easier to define a format which is likely to last.

Please Log in or Create an account to join the conversation.

More
09 May 2012 15:19 #246 by FDR
Replied by FDR on topic Re: Model data
All right!
I just worried about the size of the data description. However if some of the data is optional it will help, but if somebody makes a lot of changes, the file size might go large...
Actually the Walkera format has a lot of redundancy in it. For example a program mix is either normal or curve, but both settings take their own space...

Will my XLS help in that?
Now I rather use the model configurator , because it is much easier to see, what settings are there...

Please Log in or Create an account to join the conversation.

More
09 May 2012 15:41 - 09 May 2012 15:42 #247 by rcH4x0r
Replied by rcH4x0r on topic Re: Model data

PhracturedBlue wrote: My idea for the format was probably close to what rcH4x0r has in mind. A header followed by a table describing which features are present and their offset in the file (generic data, type-specific data, location of each channel,...)


Well, I am thinking more in terms of how C++ and derived classes or TCP/IP packets work. Think onion skins and you won't be far off. The onion skin model would help us to avoid a lot of redundant data since it simply wont be present.

The alternative is probably lots of code like this:

if(airplane)
{
}
else if(helicopter)
{
}
else if (...)

Which would suck :sick:

Certainly we should try and thrash out the model data format as far as is possible but this is so closely tied to the mixer (probably a bad name but 'transfer function' is worse <sigh>) that some thought about that is required too.
Last edit: 09 May 2012 15:42 by rcH4x0r.

Please Log in or Create an account to join the conversation.

More
09 May 2012 15:49 #248 by PhracturedBlue
Replied by PhracturedBlue on topic Re: Model data
I'll try to address all the questions about model data here...
I'm in agreement with rcH4x0r, defining the channel type has little value. treating switches as analog should work fine.

Honestly, I haven't flown anything other than 4ch planes and 6ch helis, so I don't have a good feel for everything that is needed.

General stuff:

The file names need to be 8.3, but there is no need that model names be limited to 8 characters. Given the desir to support other languages, I'd say we should not use filename as the model name.

Protocol is radio-protocol. so it'll be devo, dsm2, flysky, frysky, etc. It has nothing to do with number of channels.

I could see it being useful to have a different theme for airplanes, helis, and ground vehicles (I'm mostly thinking about the layout of the main-screen)


Transmitter power: Why would thissetting be per-model? Wouldn't this be a transmitter config vs a model config?

Fixed ID: again, why isn't this a transmitter setting? If I want to share models between users, then saving the fixed-id doesn't make sense. Or maybe I have it backwards. is Fixed ID unique to a given receiver?

Stick position switch/channel value switch: I'm not sure what you mean here. Is it like transmitter mode1 vs mode2? That would not seem to be model specific to me. If you mean how channels are mappedto hardware, I think that should also be abstracted so that the same model data can work on multiple transmitters.

Timers/Alarms. What are these used for? Are they really model specific? An example of a use would be helpful.

Trainer Settings: What types of settings do you have here?

Model specific:
I expected that mixing could be generalized rather than needing special code for helis vs planes. so we could define a generic mixing capability that could handle collective, ailerons, etc. I'm not sure I understand the need for pitch curves. If the mixing capabilities include curves, then I don't really need to predefine specific sets. So this stuff may not actually be model specific, but instead mixer settngs would go into their own section.

Channel data:
What does 'trim value' mean? You mean what value it should start up as? Yes we need that
Limited mode seems to mean that the trim only applies over part of the range. so at full thrown, the trim doesn't apply. We could probably do that by setting a trim max/min limit

Forget about the 'expo' part of the curves. we need to be able to define curves for high vs low rates. I was thinking that having a set of curves for high and low rates would give full control, and not require any additional 'expo' settings. With curves, I don't really need max/min channel values, since the curves will define this for us. If we define 100% as the 'real' maximum value, then low rate curves would just peak out at 75%

I've made various updates to the article. Please feel free to directly modify it.

Please Log in or Create an account to join the conversation.

More
09 May 2012 15:58 - 09 May 2012 16:00 #249 by rcH4x0r
Replied by rcH4x0r on topic Re: Model data
Absolutely there should be a separate settings for Tx and model.

Tx settings might include backlight brightness, low voltage cutoff, stick mode etc etc

I think a hard limit on channel ranges is a good idea, I can see that some combinations of stick inputs and mixer function could drive the channel output beyond a desirable maximum (in act I read a review of a high end Futaba Tx that had just such a feature).

I'm not the smartest guy in the wold and when I set out to design something I always find it helpful to go look at what other people have done. Not just to steal the good ideas but, perhaps, more importantly to avoid bad ideas. I'm going to suggest we download and analyse some other RC system manuals and see what people who have been doing this for a long time have done... I will start with my DX6i and T8FG manuals.

Edit: And lets use UTF-8 for any strings (not some bastard love child of UTF-7 like big W, ok?)
Last edit: 09 May 2012 16:00 by rcH4x0r. Reason: string love

Please Log in or Create an account to join the conversation.

More
09 May 2012 16:02 #250 by PhracturedBlue
Replied by PhracturedBlue on topic Re: Model data

rcH4x0r wrote: Well, I am thinking more in terms of how C++ and derived classes or TCP/IP packets work. Think onion skins and you won't be far off. The onion skin model would help us to avoid a lot of redundant data since it simply wont be present.

The alternative is probably lots of code like this:

if(airplane)
{
}
else if(helicopter)
{
}
else if (...)

I agree that we want a data format that minimizes duplication/unnecessary info, and that I really don't want if/then/else conditions in the firmware for the model type. That is why I was thinking we may have different 'themes' (think main window layout) for different models. However, there are things like showing an icon for flaps/gear/etc that we need to design to not need if/then/else cases to display. I think that moves into trying to define a GUI spec, though it will likely be tied to the model data in some way.

Please Log in or Create an account to join the conversation.

More
09 May 2012 17:10 #251 by MatCat
Replied by MatCat on topic Re: Model data
Transmitter power should be per the model not the entire TX, and that is how it is setup with walkera firmware too. For example I fly my Genius CP on a little less then full power because I am never going to fly it 1km+ away, I also fly my FPV Bixler on 10db power setting so that my amp gets proper input power so I can go for a few miles :P.

Please Log in or Create an account to join the conversation.

More
09 May 2012 19:55 #253 by FDR
Replied by FDR on topic Re: Model data

PhracturedBlue wrote: General stuff:

The file names need to be 8.3, but there is no need that model names be limited to 8 characters. Given the desir to support other languages, I'd say we should not use filename as the model name.


Agree.

PhracturedBlue wrote: Protocol is radio-protocol. so it'll be devo, dsm2, flysky, frysky, etc. It has nothing to do with number of channels.


Not really. It would be great if we could support the old Walkera protocols. The whole old Walkera userbase is obset about the DEVOs are not backward compatible.
Those protocols of 24xx, 26xx and 28xx transmitters are bound to be 4, 6 and 8 channel. Yes it is obsolete, but a lot of helis out there use these protocols. Some RCGroups users have 20-30 of them...

PhracturedBlue wrote: I could see it being useful to have a different theme for airplanes, helis, and ground vehicles (I'm mostly thinking about the layout of the main-screen)


Ah, I see. Don't know how useful it is, but no need to drop good ideas just because they seem useless for some. They might be very important for others. ;)

PhracturedBlue wrote: Transmitter power: Why would thissetting be per-model? Wouldn't this be a transmitter config vs a model config?


It is model based, because one doesn't need the whole 100mW power for an indoor micro heli, while it definitely needed for large airplanes. The full power drains power faster and cause unwanted radiation indoors...

PhracturedBlue wrote: Fixed ID: again, why isn't this a transmitter setting? If I want to share models between users, then saving the fixed-id doesn't make sense. Or maybe I have it backwards. is Fixed ID unique to a given receiver?


Fixed ID in Walkera word means no auto binding, i.e. faster bind process. You can set the fixed id value from 1 to 999999 (it default some value unique for the transmitter). The transmitter sends that id to the receiver, which memorize it, and can only cleared by plugging a "bind plug" (should be called unbind plug) into the receiver. One can assign different id for all of his models, avoiding to control it with the wrong model selected, which can be catastrophic.

PhracturedBlue wrote: Stick position switch/channel value switch: I'm not sure what you mean here. Is it like transmitter mode1 vs mode2? That would not seem to be model specific to me. If you mean how channels are mappedto hardware, I think that should also be abstracted so that the same model data can work on multiple transmitters.

Timers/Alarms. What are these used for? Are they really model specific? An example of a use would be helpful.


Now the DEVOs have two definable stick position switches. They are software switches. It means that when the choosen stick reach a defined position the SPS changes it's value from off to on (or vice versa). It can be used to turn on/off a lot of things, for example a mix can be activated when aileron is 50% left. However the most use they get for starting the timers. When you raise the throttle to 5% it starts the countdown timer, which is programmed for 4:30, because you know, that after that you should land before the battery goes flat. That's the only way you can dependantly measure flight time. (Actually it would be better if it was Channel Value Switch, so throttle hold can stop it in case of the throttle, and it would be more reliable in idle up modes too...)
So the timers are model specific, because each model has different flight times.

Telemetry data for the battery voltage is a better way, but not always available. More about it later...

PhracturedBlue wrote: Trainer Settings: What types of settings do you have here?


You can set which channels controls the trainer.

PhracturedBlue wrote: Model specific:
I expected that mixing could be generalized rather than needing special code for helis vs planes. so we could define a generic mixing capability that could handle collective, ailerons, etc. I'm not sure I understand the need for pitch curves. If the mixing capabilities include curves, then I don't really need to predefine specific sets. So this stuff may not actually be model specific, but instead mixer settngs would go into their own section.


The mixing (as far as the standard program mix goes) is very much alike for helis and planes, but for planes it is a bit more complicated. All the other mixes are the comfortable/lazy/stupid ones (choose as you wish ;) ).
But the users are used to them...
I think most of the users couldn't do a proper program mix.

PhracturedBlue wrote: Channel data:
What does 'trim value' mean? You mean what value it should start up as? Yes we need that
Limited mode seems to mean that the trim only applies over part of the range. so at full thrown, the trim doesn't apply. We could probably do that by setting a trim max/min limit


I think trims are mostly for helis (+quads) hovering. I correct the mid sticks so without any input it can hover in place. They complement the mechanical setup as a fine tune setting. They retain their values between flights, that's why they are model specific settings.

PhracturedBlue wrote: Forget about the 'expo' part of the curves. we need to be able to define curves for high vs low rates. I was thinking that having a set of curves for high and low rates would give full control, and not require any additional 'expo' settings. With curves, I don't really need max/min channel values, since the curves will define this for us. If we define 100% as the 'real' maximum value, then low rate curves would just peak out at 75%


It's a long story, and it is like the question of mixes: all the min/max + expo values can be simulated with a multi point exponential curve, but it is much more complicated.
I wish my model configurator can draw curved lines, but as I don't know the algorytm they used, it only draws straight lines. It would be good for practicing with these settings, because it is much simpler and quicker to use, than the tranmitter.
But until that, you might want to flash it back to the original fw and play with that a bit...

Please Log in or Create an account to join the conversation.

More
09 May 2012 20:26 #254 by PhracturedBlue
Replied by PhracturedBlue on topic Re: Model data

FDR wrote:

PhracturedBlue wrote: Protocol is radio-protocol. so it'll be devo, dsm2, flysky, frysky, etc. It has nothing to do with number of channels.


Not really. It would be great if we could support the old Walkera protocols. The whole old Walkera userbase is obset about the DEVOs are not backward compatible.
Those protocols of 24xx, 26xx and 28xx transmitters are bound to be 4, 6 and 8 channel. Yes it is obsolete, but a lot of helis out there use these protocols. Some RCGroups users have 20-30 of them...

I think we're talking past each other here.it doesn't matter if we are emulating 24xx, 26xx, Devo, DSM2. Each of those are (probably) a different protocol, and the maximum # of channels supported by the protocol is fixed. So protocol will just be one of: devo 24xx, 26xx, etc. The 'number of channels' field represents the number of channels used by the model. It obviously can not be larger than the number of channels supported by the protocol, but it very well can be less.

FDR wrote:

PhracturedBlue wrote: Transmitter power: Why would thissetting be per-model? Wouldn't this be a transmitter config vs a model config?


It is model based, because one doesn't need the whole 100mW power for an indoor micro heli, while it definitely needed for large airplanes. The full power drains power faster and cause unwanted radiation indoors...

Fair enough, but it probably belongs in a 'radio' or 'protocol' specific section (still part of the model data). Not all radios have control over the Tx power. I guess it'll depend on how many radio/protocolo specific settings there are as to whether we need different handlers, or just ignore unneeded values.

FDR wrote: Fixed ID in Walkera word means no auto binding, i.e. faster bind process. You can set the fixed id value from 1 to 999999 (it default some value unique for the transmitter). The transmitter sends that id to the receiver, which memorize it, and can only cleared by plugging a "bind plug" (should be called unbind plug) into the receiver. One can assign different id for all of his models, avoiding to control it with the wrong model selected, which can be catastrophic.

Thanks, that makes sense

FDR wrote: Stick position switch/channel value switch:
Timers/Alarms:

Thanks, that makes sense.

FDR wrote: The mixing (as far as the standard program mix goes) is very much alike for helis and planes, but for planes it is a bit more complicated. All the other mixes are the comfortable/lazy/stupid ones (choose as you wish ;) ).
But the users are used to them...
I think most of the users couldn't do a proper program mix.

Remember, we are talking only about the data format here. How the information is displayed to the user is not necessary the same. It will be much easier programatically to convert user input into a curve, and use a single translation function. I honestly don't know enough about the types of mixing we need to be able to specify requirements for it, but I'd hope the same applies (we give the user a friendly interface, but store the data in a standard way

FDR wrote: But until that, you might want to flash it back to the original fw and play with that a bit...

The problem for me is that I don't have any models that actually can bind to my Devo8. So yes I can play with the settings, but I can't easily see how they translate into real-world use.

Please Log in or Create an account to join the conversation.

More
09 May 2012 20:58 #255 by FDR
Replied by FDR on topic Re: Model data

PhracturedBlue wrote: The problem for me is that I don't have any models that actually can bind to my Devo8. So yes I can play with the settings, but I can't easily see how they translate into real-world use.


I see, but at least you can see on the graphs what it will do.
A more scenic way is to go into the monitor mode and watch what the output channels do depending on some mixes and/or expos. Not too scientific, but illuminating...

The whole thing can be quite complex, since everything depends on flight mode, on the applied mixes, which for example can only affect in some part of the transfer function, or even activating on a value like an agent Smith from the Matrix... ;)

But other then expo curves you can visit my model configurator too, to dive into the deeps of all the settings.

Otherwise I agree, that most of the mixes can be stored in an universial form, but is it worth it? However I would do that in case of model data conversions if there is not direct subtitution for a mix setting.

Please Log in or Create an account to join the conversation.

More
09 May 2012 22:53 #256 by MatCat
Replied by MatCat on topic Re: Model data
I have a pretty good understanding of the devo's functioning, I do some pretty advanced stuff on my FPV plane.

Technically I see no reason we cannot have unlimited mixes possible, as far as data storage it could just be a list, reguardless of it being binary, readable text format, whatever.

Please Log in or Create an account to join the conversation.

More
13 May 2012 03:54 #279 by PhracturedBlue
Replied by PhracturedBlue on topic Re: Model data
I installed ER9x on my Flysky 9x (it turns out that a old Mouse PS/2 connector fits perfectly into the antenna hole, so I have a nice plug for connecting the programmer port now). Having played with it a little, and getting it setup to fly my V911:
a) I haven't yet found an equation based expo, but haven't looked too hard
b) They use 5 or 9 point piecewise-linear curves
c) They define curves separately from the channels (so you define a curve and then assign it to a channel). I'm not convinced of this approach. How often would you want multiple channels to have an identical curve?
d) The interface is not very user-friendly at all. Figuring out how to assign channels and set channel-reverse isn't where I'd look for it. I was constantly referring to the manual.
In short, I don't think it would be a good idea to take the design interface from this project.

Please Log in or Create an account to join the conversation.

More
14 May 2012 16:10 #295 by FDR
Replied by FDR on topic Re: Model data
I have started to discover the airplane settings.
So far known: 762/912 :)

What a mess is there! :sick:

Please Log in or Create an account to join the conversation.

More
15 May 2012 19:57 #300 by FDR
Replied by FDR on topic Re: Model data
I've got all the model data! :woohoo:
OK, except one byte, and also guessed quite a few from the pattern... :lol:

Please Log in or Create an account to join the conversation.

More
22 May 2012 19:54 #343 by PhracturedBlue
Replied by PhracturedBlue on topic Re: Model data
I've update the article on model data with the results of implementing the mixer. It will be an interesting task to try to map models from the Walkera format to the mixer-based system. We'll probably want some sort of program that can do that to make it easy to move existing models. I'm not yet sure it can be automated though.

Please Log in or Create an account to join the conversation.

Time to create page: 0.058 seconds
Powered by Kunena Forum