MultiWii OSD - MWOSD

[Gartenflieger]

Hi all,

coming from KV OSD 2.2, I intended to switch over to MWOSD R1.
However, the OSD failed to overlay anything at all. All I saw was the camera video.
When the camera accidentally switched itself off, I found out that the MWOSD overlay is actually displayed, but only as long as the input signal is off.
Any ideas how to fix this?
I have not changed anything in the donwloaded R1 config.h .
Hardware is a MinimOSD board with the ananlog pins broke out to the side of the board. (Don't remember the vendor)

Regards
Christoph

[shikra]

Usually that's when camera doesn't match the pal/ NTSC settings. Suggest change pal/NTSC, save and reboot

[subaru4wd]

I put together a video after my last PWM RSSI bench test. This is just some boring OSD video, recorded as I take my Transmitter for a walk to the park and through the woods.

Keep the annotations enabled or else you wont really know whats going on.

[Gartenflieger]

Usually that's when camera doesn't match the pal/ NTSC settings. Suggest change pal/NTSC, save and reboot

Yeah, that was it. After repeated CHANGE, WRITE, RESTART, RESET, LOAD cycles in varying order finally it is working now.
Thanks for the hint. did a test flight and everything looks real good.

Regards,
Christoph

[shikra]

@subaru - that was pretty cool for a boring vid. The pwm RSSI looks like its working pretty good. It looks like at times when the RSSI drops down below 80% there are little glitches where it drops right down. I'm guessing its the RSSI value itself as it's fine when up near 100%. Intersting.

@gartenflieger - thats great. Note the reset loads defaults. Think I'll rename it in the gui - I've clicked on it a few times by accident instead of restart

[subaru4wd]

@subaru - that was pretty cool for a boring vid. The pwm RSSI looks like its working pretty good. It looks like at times when the RSSI drops down below 80% there are little glitches where it drops right down. I'm guessing its the RSSI value itself as it's fine when up near 100%. Intersting.

Thanks. the purpose of this test was to make sure RSSI dropped off gradually as I got farther away, and as more and more obsticals came between the TX & RX. Also I wanted to test to make sure it failsafed when reaching 0% RSSI and not somewhere unexpected.

I would have to say that it passed all tests with flying colors. I have a DTF 4ch Receiver with 0v-3.3v analog RSSI out, and I will probably perform an identical bench test to compare results.

One thing I was going to ask, is there a way we can put the "Map Mode" on the OSD switch? Or to be quite honest, i would like to have the GPS map visible with the OSD switch off, and have the option to hide it with the OSD switch enabled.

[shikra]

@Pluschi / ABL
PM sent with large font file for testing.

@Subaru - yep, think thats a pass!
I would expect the analog RSSI will be much smoother.
For OSD switch, you read my mind - for next release is my plan to turn it into a multi toggle switch - can change between say map mode/normal HUD/minimal screen/clear screen. It will cycle between ones you enable. So could be all or stay on same screen. Will that work?

[shikra]

ROADMAP.

Guys, am considering features for next release. her eis what is on the agenda - please advise anything extra would like to see.

Changelog since R1 i.e. DONE (may not be available on repository / packaged yet

+ Filter changed to 8 point ring + optional 2nd stage expo filter
+ All sensors now filtered - Battery / Video / Current / RSSI PWM RSSI
+ MWII sensor data remains as from FC
+ Vid voltage divider moved to "approx" same as main voltage
+ Vidvoltage added to OSD menu - with visual display
+ Zero amps adjust added to OSD menu
+ RSSI adjust max + min added to OSD menu
+ Amps and volts in the OSD menu now in Human readable form
+ Heading correction option for to support Baseflight & others added to config.h
file
+ Added the plane support changes into a #define for config.h
+ Freed up memory for future additions
+ added ability to hide ARMED/DISARMED status via config.H if required
+ added fastpixel support - *may* improve display for hi-res cameras 650tvl+
bugfix: compass heading reversed in baseflight mode
bugfix: now able to disable mode icon if required
bugfix: MWII RSSI bug fixed
bugfix: incorrect anal pin handling


Under review for next release:

Callsign
- Permananet / timed display
- Choose location
- GUI to support
- Provide location
Current sensor via Mutltiwii
Add "Disarmed" enable / disable option to GUI
Migrate OSD switch to toggle switch - flip between sceen layouts
Alarms for distance / Altitude / Speed / mah / Current
Descrition chracter font for for heading / angle to home
Double resolution for MAP mode
Additional MAP mode
Multiple HUD choices
- different layouts
- different sidebars
- different default positions and items enabled / disabled
Display anal / PWM sensors on GUI - via MW OSD protocol
Improve PWM RSSI filtering for extreme values. Recheck or constrain value
Migrate relevant items from config.h to GUI
OSD Menu
- re-add timezone correction into menu
- review and add additional features wher epossible

Review alternative look / feel
- Sensor indicator ICONS
- Sat icon
- Center crosshair
- BAT icon
- ARROW icon
- Throttle ICON /
- Longer VARIO option
- Revised startup display
- Add clear AUTOPILOT / PILOT ASSIST type text message
- LARGE FONT

Code quality
- Tidy up float calcs
- Generally review and improve code quality
- Reduce memory for future functionality

[kataventos]

For OSD switch, you read my mind - for next release is my plan to turn it into a multi toggle switch - can change between say map mode/normal HUD/minimal screen/clear screen. It will cycle between ones you enable. So could be all or stay on same screen. Will that work?

Yep it works because we have already done it for the new HUD...

[bicycle]

For OSD switch, you read my mind - for next release is my plan to turn it into a multi toggle switch - can change between say map mode/normal HUD/minimal screen/clear screen. It will cycle between ones you enable. So could be all or stay on same screen. Will that work?

Yep it works because we have already done it for the new HUD...

and Rangevideo did it for RVOSD six years ago, but that's also useless closed source so who cares?

[kataventos]

ROADMAP.

Guys, am considering features for next release. her eis what is on the agenda - please advise anything extra would like to see.

Changelog since R1 i.e. DONE (may not be available on repository / packaged yet

+ Filter changed to 8 point ring + optional 2nd stage expo filter
+ All sensors now filtered - Battery / Video / Current / RSSI PWM RSSI
+ MWII sensor data remains as from FC
+ Vid voltage divider moved to "approx" same as main voltage
+ Vidvoltage added to OSD menu - with visual display
+ Zero amps adjust added to OSD menu
+ RSSI adjust max + min added to OSD menu
+ Amps and volts in the OSD menu now in Human readable form
+ Heading correction option for to support Baseflight & others added to config.h
file
+ Added the plane support changes into a #define for config.h
+ Freed up memory for future additions
+ added ability to hide ARMED/DISARMED status via config.H if required
+ added fastpixel support - *may* improve display for hi-res cameras 650tvl+
bugfix: compass heading reversed in baseflight mode
bugfix: now able to disable mode icon if required
bugfix: MWII RSSI bug fixed
bugfix: incorrect anal pin handling


Under review for next release:

Callsign
- Permananet / timed display
- Choose location
- GUI to support
- Provide location
Current sensor via Mutltiwii
Add "Disarmed" enable / disable option to GUI
Migrate OSD switch to toggle switch - flip between sceen layouts
Alarms for distance / Altitude / Speed / mah / Current
Descrition chracter font for for heading / angle to home
Double resolution for MAP mode
Additional MAP mode
Multiple HUD choices
- different layouts
- different sidebars
- different default positions and items enabled / disabled
Display anal / PWM sensors on GUI - via MW OSD protocol
Improve PWM RSSI filtering for extreme values. Recheck or constrain value
Migrate relevant items from config.h to GUI
OSD Menu
- re-add timezone correction into menu
- review and add additional features wher epossible

Review alternative look / feel
- Sensor indicator ICONS
- Sat icon
- Center crosshair
- BAT icon
- ARROW icon
- Throttle ICON /
- Longer VARIO option
- Revised startup display
- Add clear AUTOPILOT / PILOT ASSIST type text message
- LARGE FONT

Code quality
- Tidy up float calcs
- Generally review and improve code quality
- Reduce memory for future functionality

Humm many options already committed on the repo for 2.3 dev... are you sneaking them out?? How nice !

[kipkool]

ROADMAP.

Humm many options already committed on the repo for 2.3 dev... are you sneaking them out?? How nice !

Humm, seems you take time to understand some basic principles:

from your google page:
This Open Source Project use´s GNU GPL v3 License and you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or any later version.

[hinkel]

Hi Shikra !

I hope you will not erase BOXNAMES in serial.ino like it is erase in KV OSD ( I use it for Harakiri ) !

Regards
hinkel

[kataventos]

( I use it for Harakiri ) !

Humm... OK noted for the closed source HUD

Mean time no more problems with it, GUI was coded to handle BOXIDS only.

[shikra]

@kv - i didn't know 2.3 was out yet?? I will take a look. I missed that.
Please take it the right way if any new features make it - personally I would take it as a compliment if any of my contributions to open source were reused. I'll say now - I have been looking at HUD vids lately and one is similar to one of layouts you posted on a vid a while back - I do like that and will be one of the options...

@hinkel - boxnames is staying - its available in config.h only though as I think little demand

[kataventos]

@kv - i didn't know 2.3 was out yet?? I will take a look. I missed that.
Please take it the right way if any new features make it - personally I would take it as a compliment if any of my contributions to open source were reused. I'll say now - I have been looking at HUD vids lately and one is similar to one of layouts you posted on a vid a while back - I do like that and will be one of the options

Funny stuff.. the commit was made yesterday but no package yet... Of course, be my guest. Just do not forget the right credits as you have been forgetting since the beginning! That´s why the source will be closed soon.

- Developments will continue underground and as I said before, distributed in .HEX, freely for who wants to use it while flying Multiwii.
- Honestly don´t give a damn if we have one or one million guys using our work, we always have done it for the fun

Remember to PUT THE KV TEAM DEVELOPERS BACK ON MAIN SKETCH on next dev HONORING OUR WORK and we are all good, all this shit was unnecessary if you have given the correct credits.

Maybe you get it this way... we will be talking differently in future

[bicycle]

isn't it like, right there? at the top of mw_osd.ino?

This work is based on the following open source work :-
Rushduino http://code.google.com/p/rushduino-osd/
Rush OSD Development https://code.google.com/p/rush-osd-development/
Minim OSD https://code.google.com/p/arducam-osd/wiki/minimosd

Its base is taken from "Rush OSD Development" R370

[subaru4wd]

@kv - i didn't know 2.3 was out yet?? I will take a look. I missed that.
Please take it the right way if any new features make it - personally I would take it as a compliment if any of my contributions to open source were reused. I'll say now - I have been looking at HUD vids lately and one is similar to one of layouts you posted on a vid a while back - I do like that and will be one of the options

Funny stuff.. the commit was made yesterday but no package yet... Of course, be my guest. Just do not forget the right credits as you have been forgetting since the beginning! That´s why the source will be closed soon.

- Developments will continue underground and as I said before, distributed in .HEX, freely for who wants to use it while flying Multiwii.
- Honestly don´t give a damn if we have one or one million guys using our work, we always have done it for the fun

Remember to PUT THE KV TEAM DEVELOPERS BACK ON MAIN SKETCH on next dev HONORING OUR WORK and we are all good, all this shit was unnecessary if you have given the correct credits.

Maybe you get it this way... we will be talking differently in future

Kataventos, this thread is for the further development of this OSD Firmware, MW OSD. Your ranting in this thread is absolutely no help to the developers or the end users, and is only a platform for you to emit your jealous rage. You could possibly create your own thread, or maybe just PM shikra privately to discuss these manners.

There are people here who are actually making progress and could not be any happier with the work that Shikra has put into this code. Quit trying to muddy up his thread.

isn't it like, right there? at the top of mw_osd.ino?

This work is based on the following open source work :-
Rushduino http://code.google.com/p/rushduino-osd/
Rush OSD Development https://code.google.com/p/rush-osd-development/
Minim OSD https://code.google.com/p/arducam-osd/wiki/minimosd

Its base is taken from "Rush OSD Development" R370

Yes, it is RIGHT There. Its even in the very first paragraph of this thread. And when I did a google search for "Rush OSD Development" look at what the first search result was: https://code.google.com/p/rush-osd-development/

[subaru4wd]

@Subaru - yep, think thats a pass!
I would expect the analog RSSI will be much smoother.
For OSD switch, you read my mind - for next release is my plan to turn it into a multi toggle switch - can change between say map mode/normal HUD/minimal screen/clear screen. It will cycle between ones you enable. So could be all or stay on same screen. Will that work?

I think the multi-toggle switch is a good idea, however I only need 2 screens. One screen would be full of flight data, including the GPS map mode. The 2nd screen would be very minimal with only critical information.

[msev]

I'd rather go with shikra's idea for more layouts,...but then again, maybe this could be definable? (number&which "layouts" would be present)

[kataventos]

Like the PWM RSSI...

-Ohhh Shikra thanks for this it works nicely and smooth... you are the man

What they didn´t knew is that it was permanently fixed by us and used by you even before we packaged it for 2.3 dev due to our available time to properly test it in the air. The same with current sensing... (visible by commits date)

You did not based your work in R370... you continue to base your camouflaged work on latest developments of KVTeam...

... no more sneaking under the hood

The radar was the only real development you have made so far, congratulations! does it really work?

now... 21 hours after the commit for 2.3 dev you have a new road map including new Icons, two char maps, alarms for volume flights and stuff... how convenient

Take a look, it´s public:

[subaru4wd]

I'd rather go with shikra's idea for more layouts,...but then again, maybe this could be definable? (number&which "layouts" would be present)

I know a lot of people who would love to have multiple screens. I encourage Shikra to implement it. Its just that I will only need to configure two screens. I would not mind toggling between them... i have been looking for a use for my Momentary switch

[ABL]

kataventos: i really don't get your point. You do not release your work in public (instead, keep working copy in your PC). In the same time others start to develop alternative firmware (call it 'fork', call it 'derived work'), because you're not fixing old bugs (yes, they exists, that stupid scrolling 'DISARMED' was only fixed here, together with few other bugs - feel free to deny everything) and release it in open source.
Looks like everything is ok - code is open, people are using firmware, others are contributing, everyone is happy... Except you.
For some reason you think that your code is your own and others can't do modifications?
Please, do not waste your time in this thread. So far, i had only bad experience communicating with you (denying trivial things, refusing to accept that your code isn't perfect, trying to create problems out of nothing, creating "long names" out of nicknames... Really looks like you're 12y old kid), let others fix issues which you deny and keep this topic clean, without all that "legal" stuff.

@shikra: uploading now, will try to test tomorrow in air, but probably can't (already late), so full report with "bold fonts" will be tomorrow if weather permits.

[Gartenflieger]

I suggest to just ignore all the ranting and it will stop by itself.

[bicycle]

i didnt even know there was a difference between rush-osd and kvteam-osd, if there is a difference, it is not obvious

[HFMan]

kaventos,

We all appreciate the work you and your team have done to this point- but we languished for months waiting for some simple bug fixes- I myself was thrilled to see another branch taken over by shikra to start working these simple fixes. From a users perspective, it seemed KVOSD was dead. No response to issues, no input or posts- it was just dead. It seems to me that as soon as you realized that Shikra picked up the code and actually started fixing things and improving things- that's when you got your panties in a bind.

FYI- in the source for MW_OSD:

Code: Select all

Credits.txt
==========
Major code contributors:
Jean Gabriel Maurice
Itai Nahshon
Carlo Nebuloni
Ross Power
Liam O´Brien
Andi Sch
Kataventos
Alex Dubus (GUI framework)
Gary Moscardini
Hayden Thring

Suggestions for improvement / identifying bugs 
PatrikE
Okan Vitaliy
VVK
Bicycle
Deet

MW_OSD.ino
============
/*
MultiWii NG OSD ...

 This program is free software: you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
 the Free Software Foundation, either version 3 of the License, or
 any later version. see http://www.gnu.org/licenses/

This work is based on the following open source work :-
 Rushduino                 http://code.google.com/p/rushduino-osd/
 Rush OSD Development      https://code.google.com/p/rush-osd-development/
 Minim OSD                 https://code.google.com/p/arducam-osd/wiki/minimosd

 Its base is taken from "Rush OSD Development" R370

 All credit and full acknowledgement to the incredible work and hours from the many developers, contributors and testers that have helped along the way.
 Jean Gabriel Maurice. He started the revolution. He was the first....
 
*/

So it seems to me that shikra has fully retained all credits for the work from which his development begins. In exactly the spirit as outlined in your own description. What's the problem?

[shikra]

jeez, have a life and a night out and it goes a bit crazy in here.

@kv - you need to stop smoking that stuff. Its making you paranoid. I'm not going to respond to your comments and get dragged into your self obsessed little world. This is a hobby and supposed to be fun - with all the bad things going on in the world and how people suffer in pain I think you need to take a good long look at what really matters......

@everyone else - just ignore him. If it carries on I'll get his bad posts deleted.

[shikra]

@subaru4wd / msev

About OSD switch / HUD layouts - this is what I was thinking - to make it clearer...

When the state of osd switch changes, the displayed screens cycles through a list of options:
- Normal HUD
- Map mode
- Minimal layout

But you can choose to have say only two - Normal HUD / minimal layout - as it is today (this would be default).

Havent really given it any more thought than that yet. Will probably tie it in with doubling the resolution of the map mode

[kataventos]

@everyone else - just ignore him. If it carries on I'll get his bad posts deleted.

Bad posts?

[Muddiman]

Shikra,
How about adding current used on the flight summary screen.
Keep up the great work.

[kataventos]

kaventos,

We all appreciate the work you and your team have done to this point- but we languished for months waiting for some simple bug fixes- I myself was thrilled to see another branch taken over by shikra to start working these simple fixes. From a users perspective, it seemed KVOSD was dead. No response to issues, no input or posts- it was just dead. It seems to me that as soon as you realized that Shikra picked up the code and actually started fixing things and improving things- that's when you got your panties in a bind.

Yep you are right I must say... professional work, the new HUD code and other new projects for my free time made me stop hearing you guys completely and stop with developments for the community for long time, I am sorry for that.

After all was nice that to be heard and have active development going.

Ranting stopped "developing" also

Have fun and don´t forget to fly hard but safe.

Cheers,
-KV

[shikra]

@Muddiman - yes. Thanks for reminding - Now on the list...

[ABL]

I tried new OSD fonts...
Had two almost identical copters (PZ0420 cams, naze32 on pocket rocket frame, both with 5x3" props, one on 6" arms with SS 2300kV, another with SS 2500kV on 5" arms), one with "thin" fonts, another with "thick" fonts.

Well, mixed feelings ;-)
Bold fonts are better visible. Much better, readable. But they're boring, it's the same font i had for years on other OSD.
"Thin" fonts are "something new" but probably not visible on low-res displays.

For me - probably best choice would be "thin fonts" + "fat AHI", but this won't work for everyone. Why not include both sets into next release?
Also, there are hornet fonts from disq, we can just remake new "mixed" font - slightly thicker, but not "old boring" style.
I will try to wire DVR to my goggles (use it only with GS) and record video with both fonts in action.

[Plüschi]

Some (i hope constructive) remarks:

- You use the arduino serial library with blocking send. The mwii code uses non-blocking send. BUT since there are only 5 bytes sent per message i guess this doesent matter at all.
- There should be a scaling for the horizon bar depending on the optic of the camera. The horizon bar should exactly mimic the real horizon. I guess there is enough time to do a float thingy here.
- The GUI is very slow and sometimes unresponsive. No idea why.

And now a (i think new) idea:

The thing with video tx/rx is they have a very limited range compared to usual RC equipment. My 5.8g fatshark (100mw) worst case (misaligned antenna) goes a whole 50m before loosing video. The frsky RC goes 1000m + in same conditions. But how am i going to fly the plane back without the OSD info on the screen? I dont know direction to home or altitude.

Instead of attaching the OSD between camera and videotransmitter, why not between video-receiver and display? When video drops out, we get a blank screen, BUT still with OSD info on it. So i can safely fly my plane home. What i need on the OSD is direction to home, distance, altitude, and the horizon bar. To make this work, i must use the FC to write telemetry data to the frsky receiver, and the OSD to read this data directly from the frsky transmitter.

I am working on a very simple (uncluttered) version of mwiiosd, only horizonbar, dir_to_home, Dist_to_home and altitude (and BIG chars). I will try to attach this to frsky telemetry protocol later.

[ABL]

Plüschi: look here:
https://github.com/KipK/Ghettostation/wiki/6%29-GhettoProxy
Already done... And KipK is on IRC too, so you can ask questions directly.

Agree about sometimes unresponsive menu. But you're using it rarely, so very minor bug.
I can't get RSSI working (yet), allways get near-max values (246 - but not 255), FrSky + small filter, voltage changes when i measure with multimeter. The same with 1.1 and 5V vref. I will check this later, maybe something wrong with pin assignment...

[msev]

I have an idea for a feature, its a bit unique but anyway what-the-hell if I mention it... Having a secondary arrow pointing to "waypoints" (gps.coords) which one would input in the configurator software to the osd.. this would help with orientation during flying...For example C4S osd has this feature...Its a bit of a crazy feature request but anyway, worth a try

[LVNeptune]

Interesting idea. In what scenario would this be useful? I can't think of a situation where I would need to know my home point + a waypoint unless I am doing autonomous flying and just want to see heading but it would never be the same thing twice. Just interested to see a useful purpose for this.

[subaru4wd]

Maybe have it set in the code, that when you flip the switch for autonomous navigation, your home arrow now points to the next waypoint instead of home?

[msev]

@Neptune and subaru:

Basically the use case is for example if one wants to visit multiple sites of interest during one trip (like a lake and a specific mountain) and not using an autopilot that does waypoints (for example baseflight & its forks don't support those silly things)...And wheres the fun in watching a plane/copter flying itself whereever u want...It would ease the navigation in that case.

It would be more generic, could be used with a more diverse range with stabilization hardware (multiwii 2.3 without eosbandi's changes, naze32 etc.) if it would be set-up that way, so that one would just input coordinates of points of interest on the ground then cycle through them in the air, probably could be another useful use of a switch.

Anyway, just an idea...and here is a demo of it in C4S osd:https://www.youtube.com/watch?v=C7qznIyP-fI

[subaru4wd]

I like that idea.

It would be great for multirotor racing too. You can program the "gates" as waypoints and the arrow would lead you to the nearest one!

[subaru4wd]

Shikra,
I was setting up the OSD switch screen, and noticed a couple things.

-Vid voltage always shows no matter what my config.h is set to. If I enable it in the GUI, it shows on both screens.
-When enabling the Home Arrow for the OSD SW, it moves it the arrow to the bottom of the screen. But only with the OSD SW on, with it off my Home Arrow returns back to the top where it belongs.

Also it would be nice to move some of the screen items around. Are there any plans on a quick and easy way to arrange items?

[shikra]

@ ABL
I get what you are saying.... So far I have had comments for text being too small to read and / or the AHI and other lines too thik
I'd be more than happy to bundle in any font maps that people do themselves, but would mean someone owning each and keeping it up to date. Likely to be quite a few changes in that in next month so once that's done will open up the doors for anyone to add their own in to be distributed - or some font repository. Would be cool to have lots of choice, but I'll probably only keep default + one large font one up to date.

In your case as its only ahi suggest use the built in font editor and double the thickness. Save and reload.

@ Plüschi
Wasn't aware of the blocking. Probably not a big issue as you say - maybe keep this as a low priority todo. Also note that if using PWM RSSI and the VSYNC update option, current design has "do nothing whilst wait" code. Its not ideal or optimal, but I think its good enough for human eye...

@msev/subaru4wd/lvneptune
re 2nd GPS - note that the OSD has no GPS calculation code within - it purely takes the position and puts it up as text on the display. i.e. to support request, would have to add full GPS code within. Probably not the room for this currently.
Not on my agenda at the moment, but hold the thought... because I think in the future it would be good to provide support for direct connection of GPS to OSD to create a cheap standalone OSD for airplane users.
Now if data could be provided via MSP from MultiWii, then that's a different matter... it then becomes very easy.

@Subaru
Those were by design - mainly as it was from my original desire! Also main voltage and timer permanently displayed.
I'll add the options in to disable all on minimal . Shoudl have done it before really
For the home arrow moving, I did this for the minimal layoutt - and have volts/timer and arrow all on same line. Nice and neat.

Its easy to change - find these and make second one same as first in screenlayout.ini :
POS(LINE02+22+TOPSHIFT, 0, OSDOFF03), // GPS_directionToHomePosition
POS(LINE13+20, 2, OSDOFF03), // GPS_directionToHomePositionBottom
At moment you can relayout positions - but only by editing the code. It is not nice and easy to change like kvteam stick wiggle method.
Its a wishlist item - I'll see if can make it simpler and easier within config.h as an interim. Longer term, would like to do via the GUI

[msev]

Dunno what you mean with "2nd GPS"... ...We just mean that there would be some coordinates stored in eeprom before flight and a secondary arrow would point to them. Its the same principle you use for your arrow pointing at home..

[PatrikE]

The easiest way to to fix Direction arrow is in MWiii code.
If You're in a GPS mode

Code: Select all

if (f.GPS_HOLD_MODE || f.GPS_HOME_MODE)(
 GPS_directionToHome = target_bearing; 
)

In Gps.cpp Search for

Code: Select all

if (f.GPS_HOLD_MODE || f.GPS_HOME_MODE)

Place the target direction in the if.
I used it during Testing nav code for planes.

[shikra]

My bad - I mean to say 2nd arrow
As no GPS code in OSD, this would need to be handled via multiwii in some way as Patrik advises. Maybe this will be something that comes with new multiwii waypoint type features?

Dunno what you mean with "2nd GPS"... ...We just mean that there would be some coordinates stored in eeprom before flight and a secondary arrow would point to them. Its the same principle you use for your arrow pointing at home..

[subaru4wd]

@Subaru
Those were by design - mainly as it was from my original desire! Also main voltage and timer permanently displayed.
I'll add the options in to disable all on minimal . Shoudl have done it before really
For the home arrow moving, I did this for the minimal layoutt - and have volts/timer and arrow all on same line. Nice and neat.

Its easy to change - find these and make second one same as first in screenlayout.ini :
POS(LINE02+22+TOPSHIFT, 0, OSDOFF03), // GPS_directionToHomePosition
POS(LINE13+20, 2, OSDOFF03), // GPS_directionToHomePositionBottom
At moment you can relayout positions - but only by editing the code. It is not nice and easy to change like kvteam stick wiggle method.
Its a wishlist item - I'll see if can make it simpler and easier within config.h as an interim. Longer term, would like to do via the GUI

Thanks for explaining all that to me. Makes sense. I don't think my video Voltage is all that critical so I would like to hide it. And I agree the Home Arrow on the bottom does make things cleaner, however my Feet from home is still in the top line, so it just tricks the eye.

I will poke around in screenlayout.ini and see what I can come up with. I agree that having it controlled by the GUI would be best. The stick method seems like it would take up valuable code space.

Have you used the Config Tool for the MinimOSD-extra project? https://code.google.com/p/minimosd-extr ... ing_Panels
The way it sets up the GUI is really very impressive, and you have a tab for each screen so you can really go crazy with the customization.

[shikra]

I think this would be the ultimate objective to manage screen layouts. For this I'll need someone with good java processing skills....
After next release main objective will be to implement the multiple HUD options - including custom one which will be the groundwork for the GUI

Have you used the Config Tool for the MinimOSD-extra project? https://code.google.com/p/minimosd-extr ... ing_Panels
The way it sets up the GUI is really very impressive, and you have a tab for each screen so you can really go crazy with the customization.

[shikra]

After some testers for the next release which is ready.
Please send me a PM with email if want to try it out.

Anyone with frsky and telemetry hub is especially welcome !

[herzjung]

Hi all,

I recognised that the softwarte power consuption calculation is based on the position of throttle - this results in a failure if you fly in altitude hold mode. Can this be changed in a way that the algorithim takes the values of the output of the flight controller?

A perfect thing to add would be a waypoint information for the MutliWii NAV software like for instance in the the MinimOSD-extra project.

Best regards an thanks to Shikra
Peter

[PatrikE]

I recognised that the softwarte power consuption calculation is based on the position of throttle - this results in a failure if you fly in altitude hold mode.

The same thing for FixedWing Nav.
The NavigationCode uses rcCommand[THROTTLE] and only reads rcData[THROTTLE].
It's ok as long as you fly manual when they are equal.

But rcCommand[] isn't sent via MSP Just RC_CHANS[].
Fact is in Mixers all models is controlled by rcCommand[THROTTLE] witch is actual Thro output.

Code: Select all

 #define PIDMIX(X,Y,Z) rcCommand[THROTTLE] + axisPID[ROLL]*X + axisPID[PITCH]*Y + YAW_DIRECTION * axisPID[YAW]*Z  

Patrik