Hello all, since I lost the opportunity to suggest new features in 2.0.38, I though I would open a new list for the next revision.
I have flown recent 2.0.39 code and I can say the improvements are great!
1. Vertical acceleration compensation for tilt/roll. This is my personal experience of course, but it seems that when in forward flight and descending, the copter tries to level itself. I have to give full forward to get the copter move. Anybody experiencing this??
2.I would like to have ALT_HOLD separate from LOITER. do for example have LOITER for vertical shoots and LOITER + ALT_HOLD for panoramas.
3. I think we all should have the ability to program flight modes on separate reciever channels mainly because not all people have the ability to mix 6 (or more) modes between two channels and because it would give the ability to separate special features like ALT_HOLD and LOITER
4. I would like the ability to change DCM parameters on the planner as an advanced feature (MK has this... :-) ) so it would easy to fine tune those parameters with telemetry. This is an advanced feature, not neede for the most, but still a good option).
Anybody agree? Any other suggestions.
Jason and all, again, thanks for your wonderful work.
Cheers,
Emile
Replies
I'd like to comment the second point. It needs to be splitted in two parts, logical point of vue and hardware implementation.
I think like you that mode selection should be enhanced.
A) Fisrt, logically speaking, i think that mode changes should be organized differently.
Actually, we have many modes. This is not good for user selection. Confusing and difficult to implement seen from the transmitter / receiver side.
I would propose a different approach here :
- a base mode selector, three position :
- Manual
- Auto
- RTL
The purpose of this selector is to fastly change the main mode.
- options selectors (two positions)
- alt hold
- horizontal hold
- heading hold
- throttle control
- acro PID
- circle
...
The purpose of those optionnal mode selectors with two way switches, is to have a full set of options, clearly identified on the transmitter and easy to remember.
So when we switch to "Manual" base mode, we switch the to the Manual flight mode + optional options.
This way of changing modes could be implemented in the APM software using a #Define for a new mode selection process.
B) Hardware implementation :
Actually the process of mode switching is done using a single PWM channel, and simply switching modes with spot PWM values.
This is quite efficient when a small number of modes is necessary, but as soon as the number of modes and options rise to something more than a few, it becomes unusable or unreliable.
The problem is that with a couple base modes, and a couple options, we can easily end up with as many as 12 or 24 needed positions.
More, seen from the transmitter side, this is not easy to implement. The best way i've found to clearly organize modes changes is to use flight modes and flight modes priorities on the transmitter with a Gyro channel to control the mode channel. But clearly, this is not something simple to do for most users, and it needs a high end transmitter.
Using more than one PWM channel is not easy or desirable. RC Channels are needed for other tasks : cam control, failsafe control for backup receivers, accessories, camera shooter, flight recovery...
So i think a new way of transmitting modes is needed. We have two options :
- The best one : use an advanced and open radio system, like the Jeti one, and use this to send digital mode changes to the APM through the receiver serial telemetry link.
The inconvenient of this, it that it needs specific development for each brand of RC hardware, and there is actually only a couple RC hardware on the market able to do this. Obviously Jeti is certainly the only one with enough opening and reasonable cost.
- The DIY one : use a normal PWM channel, but use it with a simple digital code. Implementing a fast but error prone protocol, it should be possible to control say a three position witch, and seven two positions switches. This would not be as fast as a PWM channel, but it should be possible to make a mode change inside a 250 ms time frame, with error control. I think it is more important for mode change to have a reliable error control, than switching very fastly.
This would allow to use a three position switch for main mode selection, and seven remaining switches for mode options, lights...
Now seen from the hardware implementation side :
- Model side :It would need a modification to the APM firmware, so that it can decode the PWM channel pseudo digital code.
- Transmitter side : it would need a small board with a 8 bits AVR and an analog switch network chip (to switches resistors), so that we can emulate the digital code through a transmitter proportional PWM channel.
Clearly the cost of this board would be quite low.
Then a small external module with 8 switches could be fixed to the transmitter and connected to this AVR board.
Are you refering to the MK mixer setup???
1. what do you mean? more stick authority on descening? hard to implement... but a good idea
2. is already there
3. agreed
4. no.. MK doesn't has this ;) these parameters depend on the hardware (sensors used, etc) which is always the same, so you don't need to change these parameters