MultiWii OSD - MWOSD

Leo · Post by **Leo** » Wed Jun 24, 2015 6:32 pm

schnupperm wrote:
shikra wrote:I can only test in windows unfortunately - tried 32 and 64 bit.

ok, I can confirm that it's only linux related. Tried with my old XP and it worked at 115200 baud. 4 times faster than under linux, so the linux font uploader uses 38400 baud. No idea why...

I just tried uploading the slim font at 115200 baud on my Win 7 64 without success.

The GUI itself works fine.

I don't know what is going on.

schnupperm · Post by **schnupperm** » Wed Jun 24, 2015 10:16 pm

shikra wrote:@Schnupperm – updated main trunk:

“Default” (current standard at vanilla gui install)
“Default large” – yours

cool

shikra wrote:“Default bold” – current 1.4 large. Maybe more towards more black background / clear contrast. I have found this of some benefit on mini quad fast flying in noisey environment. Brain interprets data that bit faster / easier. Great in conjunction with simple screen 0 say volts + timer.

Yes. That was exactly the reason for which I first changed only the digits in the default font to a large size.

shikra wrote:For AHI pitch / roll –Must admit I’m not getting need for roll as never experienced need for this!! Are cameras not fitted level – or plane not trimmed?
I find horizon varies so much + plane moves around so much it’s a bit unnecessary.

When you said plane you are right: when flying FPV with my new plane I think I don't need the AHI because the real horizon is visible almost all the time. In fact most of the time I had no OSD installed at all. But for copters I have 2.5 reasons:
1. Camera with no gimbal stabilisation: When flying FF or for any other reason the real horizon is not on your monitor, I find it helpful when the AHI corresponds to the real pitch and roll angles.(And it looks so cool, when the AHI follows exactly the real horizon when visible;-)
2. Camera whith gimbal stabilisation: I know that I'm not supposed to fly FPV with a cam on a gimbal... but in that case a "real" AHI helps a lot.
2.5: Even in a real plane the AHI matches the real horizon.... ;-)

shikra wrote:Also note that although we can tune the horizon bar – it not possible with center hair or AHI sidebar centers – can only be moved a whole character up/down.

That's no problem: You can pitch the camera for fine tuning.

shikra wrote:Drift angle - same issues – any implementation needs to have minimal memeory overhead – and for lesser used functionality, must be completely excluded via define a standard. Also font space is at a premium – especially for planned future work accounting for almost all of it.
Maybe we can make existing heading arrow code? Use a second arrow with single char to side indicating it is HV Heading vector or something?

I reused the heading arrow. So I have two arrows on my screen, but I know which is which...(because I'm the one who placed them ;-)

ArrogantDuck · Post by **ArrogantDuck** » Tue Jun 30, 2015 12:59 pm

Follow-up:
Since KVOSD was working, I knew that MWOSD ought to work for me.

To that end I set out on the task of figuring this out.

Got it!

Dunno which it was but I changed the following for the icon: compatibility mode of XP, pack 3, and to always run as administrator.
I now have a running MWOSD R1.4 gui running.

Cool. Knew I had to get this working as I have a micro Mini to work with for my next craft.

Done.

Leo · Post by **Leo** » Sun Jul 05, 2015 9:56 am

shikra,

I downloaded 1.5-dev 2 days ago.

This morning at 29°C (it is really hot here lately!) I flew two lipos.

On the first flight GPS distance and the "arrow" was working correctly:

I then changed to my second lipo without changing anything else.

Distance was no longer working and the arrow was pointing in the opposite direction:

Can you fix this and let me know here when it is fixed so I can download the updated version.

Thanks,

Leo

rubadub · Post by **rubadub** » Mon Jul 06, 2015 9:49 am

how far off are vario & pitch/roll rates? I really need these...

shikra · Post by **shikra** » Mon Jul 06, 2015 12:12 pm

@ LEO – am not aware of any direction issue switch arrow indictor. The code is actually very simple – it takes what angle the MultiWii sends and crates pointer from that.

One your photos there is a difference, although look like at same place – distance from home is zero on one and 33m on the other. When close to zero, the direction indicator is not good. Pretty useless.

Home position set OK in same place ?

shikra · Post by **shikra** » Mon Jul 06, 2015 12:16 pm

@rubadub - few weeks away

Leo · Post by **Leo** » Mon Jul 06, 2015 12:18 pm

The latest version has that error. I have not had it before with other versions that I'm aware of.

I have full videos of both flights if you need them for proof.

izeman · Post by **izeman** » Mon Jul 06, 2015 3:39 pm

i got mwosd 1.4.1 with a flip32+ and cleanflight 1.9.0 working. all is setup to show FC values (voltage, current, rssi ...)
all seems fine so far, but CURRENT displayed is only a tenth of the real value. so unarmed at the desk it takes 1A and OSD shows 0.1A.
props mounted and full throttle is 55A and OSD shows 5.5A. of course mAh counted are wrong by the factor 10 as well.
where would i change that?

Leo · Post by **Leo** » Mon Jul 06, 2015 4:56 pm

shikra wrote:@ LEO – am not aware of any direction issue switch arrow indictor. The code is actually very simple – it takes what angle the MultiWii sends and crates pointer from that.

One your photos there is a difference, although look like at same place – distance from home is zero on one and 33m on the other. When close to zero, the direction indicator is not good. Pretty useless.

Home position set OK in same place ?

Here a very short low res video to show the problem:
(Left is working, right is not working)
http://www.leo.nutz.de/videos/forums/MWOSD_direction_issue_switch_arrow.m2ts

Maybe you have an idea?

izeman · Post by **izeman** » Mon Jul 06, 2015 5:28 pm

izeman wrote:i got mwosd 1.4.1 with a flip32+ and cleanflight 1.9.0 working. all is setup to show FC values (voltage, current, rssi ...)
all seems fine so far, but CURRENT displayed is only a tenth of the real value. so unarmed at the desk it takes 1A and OSD shows 0.1A.
props mounted and full throttle is 55A and OSD shows 5.5A. of course mAh counted are wrong by the factor 10 as well.
where would i change that?

am i on the right track?

Code: Select all

#ifdef AMPERAGECORRECT
    MWAmperage = MWAmperage * 10;
#endif

izeman · Post by **izeman** » Mon Jul 06, 2015 5:42 pm

yes. that solved it.
now there is still the issue that i got ghost pictures. be seen with this blinking gps symbol.
i already set #define WHITEBRIGHTNESS 0x11 but it didn't get any better.
this is the video:

shikra · Post by **shikra** » Tue Jul 07, 2015 8:43 am

@izeman - pretty sure that ghosting is a monitor issue. I see it on my cheap one too. Not on good one...

shikra · Post by **shikra** » Tue Jul 07, 2015 8:46 am

@izeman - for current sensor issue I think in cleanflight there is a setting to do with multiwii current. Probably need to check/uncheck - or use the corrector as you indicated above. It may be that over tiem cleanflight has changed and this needs to be enabled by default now.

Could you left me know what the setting in cleanflight configurator is when your reading was incorrect?

shikra · Post by **shikra** » Tue Jul 07, 2015 8:51 am

OK - can see the issue.

At arm, sats were 3 - so its the multiwii controller is unable to set home correctly.

If you see the distance = 0 all the time - all the OSD does is display what is received. There is no processing / little code for that. So either it's not receiving updates, or its because home not set. And as everything else is OK and sats =3 at arm I would bet on home not set!

I think there is s setting you can enable to prevent arm without sats...
Hope that helps..

Leo wrote:
shikra wrote:@ LEO – am not aware of any direction issue switch arrow indictor. The code is actually very simple – it takes what angle the MultiWii sends and crates pointer from that.

One your photos there is a difference, although look like at same place – distance from home is zero on one and 33m on the other. When close to zero, the direction indicator is not good. Pretty useless.

Home position set OK in same place ?

Here a very short low res video to show the problem:
(Left is working, right is not working)
http://www.leo.nutz.de/videos/forums/MWOSD_direction_issue_switch_arrow.m2ts

Maybe you have an idea?

Leo · Post by **Leo** » Tue Jul 07, 2015 9:01 am

OK, I will look at that and see if I can confirm. Thanks!

shikra wrote:OK - can see the issue.

At arm, sats were 3 - so its the multiwii controller is unable to set home correctly.

If you see the distance = 0 all the time - all the OSD does is display what is received. There is no processing / little code for that. So either it's not receiving updates, or its because home not set. And as everything else is OK and sats =3 at arm I would bet on home not set!

I think there is s setting you can enable to prevent arm without sats...
Hope that helps..

...

izeman · Post by **izeman** » Tue Jul 07, 2015 9:34 am

shikra wrote:@izeman - pretty sure that ghosting is a monitor issue. I see it on my cheap one too. Not on good one...

it's a dominator v2. i can't compare with other goggles and hope this is no hardware issue.

edit: i already set brightness and contrast to min/max (all combinations) but this doesn't solve the problem.

izeman · Post by **izeman** » Tue Jul 07, 2015 9:42 am

shikra wrote:@izeman - for current sensor issue I think in cleanflight there is a setting to do with multiwii current. Probably need to check/uncheck - or use the corrector as you indicated above. It may be that over time cleanflight has changed and this needs to be enabled by default now.

Could you left me know what the setting in cleanflight configurator is when your reading was incorrect?

in mwosd-gui the setting was to use FC current. i don't have a current sensor connected to the minimosd.
as you have made so many different defines (3) for cleanflight versions, maybe you have to add the define AMPERAGECORRECT in case cleanflight 1.9.0 is set? for me it works.

shikra · Post by **shikra** » Tue Jul 07, 2015 12:51 pm

I think I see this in my goggles too. Don't notice it in flight though.

izeman wrote:
shikra wrote:@izeman - pretty sure that ghosting is a monitor issue. I see it on my cheap one too. Not on good one...

it's a dominator v2. i can't compare with other goggles and hope this is no hardware issue.
edit: i already set brightness and contrast to min/max (all combinations) but this doesn't solve the problem.

shikra · Post by **shikra** » Tue Jul 07, 2015 1:10 pm

izeman wrote:
shikra wrote:@izeman - for current sensor issue I think in cleanflight there is a setting to do with multiwii current. Probably need to check/uncheck - or use the corrector as you indicated above. It may be that over time cleanflight has changed and this needs to be enabled by default now.

Could you left me know what the setting in cleanflight configurator is when your reading was incorrect?

in mwosd-gui the setting was to use FC current. i don't have a current sensor connected to the minimosd.
as you have made so many different defines (3) for cleanflight versions, maybe you have to add the define AMPERAGECORRECT in case cleanflight 1.9.0 is set? for me it works.

Had a quick look and it seems this is default setting in CF. Was advised previously it wasn't I'll change to include defines...

Leo · Post by **Leo** » Tue Jul 07, 2015 8:05 pm

Well, all I had to do is look at the beginning of the video. I always wait for at least 7 stats before I arm.

In the video you can see I arm with 9 stats:

http://www.leo.nutz.de/videos/forums/MWOSD_direction_issue_switch_arrow_1.m2ts (100MB)

Any other ideas?

Leo wrote:OK, I will look at that and see if I can confirm. Thanks!

shikra wrote:OK - can see the issue.

At arm, sats were 3 - so its the multiwii controller is unable to set home correctly.

If you see the distance = 0 all the time - all the OSD does is display what is received. There is no processing / little code for that. So either it's not receiving updates, or its because home not set. And as everything else is OK and sats =3 at arm I would bet on home not set!

I think there is s setting you can enable to prevent arm without sats...
Hope that helps..

...

shikra · Post by **shikra** » Wed Jul 08, 2015 9:47 am

Ah yes - its clearly 9.
In the other file it looks like a 3 to me! Maybe bits lost in lower resolution?

In that case I can only think of one possibly cause.

I notice on the screen you were in flight summary mode, then armed when in that rather than exiting first .
Possibly it still thinks its in the menu (where it doesn't request unnecessary values like distance to home, etc. )

I'll try to replicate when back tomorrow.
If this is what I suspect then its unplanned scenario and needs to be fixed. And has probably been like it since day 1 ....

Leo · Post by **Leo** » Fri Jul 10, 2015 1:05 pm

Lemme know when it's fixed

shikra · Post by **shikra** » Fri Jul 10, 2015 4:09 pm

I couldn't replicate - but this is possibly down to how the serial simulator functions.

The code appears to create the scenario as your video shows.

Fix included in latest dev test release here ...
https://github.com/ShikOfTheRa/scarab-osd/releases

Leo · Post by **Leo** » Fri Jul 10, 2015 5:54 pm

Well, I just came back from two lipo flights and I didn't have the problem. Will keep it under observation

However, I can no longer click on anything in the GUI.

shikra · Post by **shikra** » Tue Jul 14, 2015 1:59 pm

Haven't seen that with the GUI -
Maybe try the latest GUI from the link above? Or even an earlier 1.4.1 release. I think they are compatible.
Nothing changed that should impact that though, but its the version I am using every day.

Leo · Post by **Leo** » Tue Jul 14, 2015 4:27 pm

GUI.....

DEV 1.4.2 works with exe.
DEV 1.5.0 works with the processing editor. No compiled .exe available (You had this version type declared for a short time)
DEV 1.4.2.2 will not work with your compiled .exe. It works with the processing editor.
DEV 1.4.2.4 will not work with your compiled .exe. It works with the processing editor.

Leo · Post by **Leo** » Thu Jul 16, 2015 8:34 pm

Two more lipo flights tonight and the distance indicator/arrow is now working correctly when going into exit/arming state (FW 1.4.2.4).

shikra · Post by **shikra** » Thu Jul 16, 2015 11:17 pm

Thanks Leo.
Thats odd on the GUI! What OS/java version are you using? maybe see if I can try out in work..
I updated my Java and maybe its done something in the compiled released. Doesn't sound like code if yours is working in compiler.

Leo · Post by **Leo** » Fri Jul 17, 2015 6:29 am

It's definitely your compiled version not working. If I use your source and compile the code myself the GUI works.

I'm using Win 7 and Java 8.31.

Leo · Post by **Leo** » Fri Jul 17, 2015 4:06 pm

I am still unable to upload fonts to the device (v1.4.2.5).

Leo · Post by **Leo** » Sun Jul 19, 2015 8:35 am

More problems with 1.4.2.5

Although I have 11 satellites they and arrow / distance are not showing up in this state:

When I switch to arm they show up:

shikra · Post by **shikra** » Mon Jul 20, 2015 3:42 pm

Yes, confirmed this is bug just introduced in previous. Thanks for highlighting. Fixed on Github and ,waiting for testing:
“Although I have 11 satellites they and arrow / distance are not showing up in this state”

I can’t replicate this one:
“I can no longer click on anything in the GUI”
I think I might revert back to 32 bit java to produce executables.
(Although I would say try both 32 bit and 64 bit – usually if one has issues, the other one often works)

I can’t replicate this one:
“I am still unable to upload fonts to the device”
Have another report of similar so open to there being an issue, but need to replicate the issue before I can resolve.
What happens – doe sit count up and not update?

csurf · Post by **csurf** » Mon Jul 20, 2015 5:18 pm

shikra wrote:@Rubadud
Vario rate – yep its on the roadmap. Quite likely for next release.

Pitch / Roll angles – is quite easy and I think not much memory.
Probably in conjunction with schnupperm’s comments above. Disabled by default.
Most likely not for next release.

I require this as well.
are you accepting PR's for patches? I might be able to come up with something simple.

Leo · Post by **Leo** » Mon Jul 20, 2015 5:52 pm

shikra wrote:Yes, confirmed this is bug just introduced in previous. Thanks for highlighting. Fixed on Github and ,waiting for testing:
“Although I have 11 satellites they and arrow / distance are not showing up in this state”

OK, will test asap.

shikra wrote:I can’t replicate this one:
“I can no longer click on anything in the GUI”
I think I might revert back to 32 bit java to produce executables.
(Although I would say try both 32 bit and 64 bit – usually if one has issues, the other one often works)

I can click on the items when no connection was made to the OSD. As soon as I have a green connection all seems OK. But the buttons will not react to any mouse commands.
This happens with 32bit. I can't run 64bit because your "MW_OSD_GUI.bat" file doesn't run the GUI.

shikra wrote:I can’t replicate this one:
“I am still unable to upload fonts to the device”
Have another report of similar so open to there being an issue, but need to replicate the issue before I can resolve.
What happens – doe sit count up and not update?

I select the font, then upload it. The programs counts up to 256, everything looks OK. However the old font on the OSD still remain. I am running on 115200 baud.

rubadub · Post by **rubadub** » Wed Jul 22, 2015 7:20 am

I just downloaded the repo zip and it appears to be broken. I can't change any of the PID/rate values for MW2.3. Is this a known issue? What do I need to change to fix it?

shikra · Post by **shikra** » Wed Jul 22, 2015 9:38 am

@rubadub - this is quite possible as many changes in that area.... Baseflight and Cleanflight latest versions tested and confirmed.
I haven't been able to test multiwii yet. - should be in next couple of days.

shikra · Post by **shikra** » Wed Jul 22, 2015 9:42 am

@leo

for the gui - I have still not got a clue why !!
But it sounds like soem things can be clicked when connected - like font button?

I'm going to change my java version and recompile to see if that works better for you.

Leo · Post by **Leo** » Wed Jul 22, 2015 9:49 am

shikra wrote:@leo

for the gui - I have still not got a clue why !!
But it sounds like soem things can be clicked when connected - like font button?

I'm going to change my java version and recompile to see if that works better for you.

No, nothing is clickable as soon as a connection with the OSD is established.

shikra · Post by **shikra** » Wed Jul 22, 2015 5:08 pm

I have no idea if this works, but I have re-installed 32 bit java on my pc and rebuilt the gui applications. This is what was on there recently and could have had an impact in some way.
You are welcome to try the GUI from this. Need to try both 32 and 64 bit.

https://github.com/ShikOfTheRa/scarab-o ... g/v1.4.2.7

Leo · Post by **Leo** » Wed Jul 22, 2015 5:20 pm

shikra wrote:I have no idea if this works, but I have re-installed 32 bit java on my pc and rebuilt the gui applications. This is what was on there recently and could have had an impact in some way.
You are welcome to try the GUI from this. Need to try both 32 and 64 bit.

https://github.com/ShikOfTheRa/scarab-o ... g/v1.4.2.7

No joy, same problem. Both don't work.

If I compile the source code to make exe, both 32bit and 64bit work.

csurf · Post by **csurf** » Wed Jul 22, 2015 5:48 pm

@Leo, is your computer cpu hitting 100%?
If so, then maybe that's your problem.

I think someone else mentioned that the java app will completely load the processor, and on a slow computer, it will freeze and not respond. I've had it happen to me as well. You need a relatively fast computer with a lot of resources to run it successfully.

The java/processing app really really sucks, I absolutely hate it.
The GUI should really be moved to some other platform.
Maybe the existing app could at least be re-organized in order to lighten the processing load. Perhaps it could be turned into a multi-window or multi-tab setup, instead of having a million graphical buttons and settings on a single window frame.

Leo · Post by **Leo** » Wed Jul 22, 2015 5:51 pm

No, my CPU hovers at 12% when the program is running.

I'm sure it's on your side mate, sorry.

Here are the ones I compiled: http://www.leo.nutz.de/temp/MW_OSD_GUI_1.4.2.7.zip

shikra · Post by **shikra** » Thu Jul 23, 2015 11:21 am

csurf wrote:@Leo, is your computer cpu hitting 100%?
The java/processing app really really sucks, I absolutely hate it.
The GUI should really be moved to some other platform.
Maybe the existing app could at least be re-organized in order to lighten the processing load. Perhaps it could be turned into a multi-window or multi-tab setup, instead of having a million graphical buttons and settings on a single window frame.

I hate it too. probably more than you

May re-organize to tabs at some point.
Still hoping someone will build it in Chrome...

Note, can change the screen update frame rate by editing gui.cfg in data folder. This might make it more responsive.

shikra · Post by **shikra** » Thu Jul 23, 2015 11:23 am

@ leo - I really don't have a clue on your issue...

shikra · Post by **shikra** » Thu Jul 23, 2015 11:30 am

@csurf / rubadub:

This is added in latest test release ( I still haven't been able to test multuiwii 2.4 save yet:
OSD - ability to display pitch and roll angles. Relocatable via layout editor.

https://github.com/ShikOfTheRa/scarab-osd/releases

Leo · Post by **Leo** » Thu Jul 23, 2015 11:33 am

shikra wrote:@ leo - I really don't have a clue on your issue...

No problem. I'll compile the source myself... no big deal

When I compile the code myself I haven't hardly any lag in the GUI and my CPU is bored. It doesn't matter on which computer the GUI runs on.

I love your OSD so you don't have to worry about me

oh, one other thing. Please activate your warning level to "default" in the Arduino compiler. There are some fundamental warnings in the code that should be taken care of e.g. struct... .

shikra · Post by **shikra** » Thu Jul 23, 2015 3:16 pm

Yeah thanks Leo.

And I'll add that to the list. I looked at them before there are a lot that should be addressed. ALthough many are not applicable in context.
Think I'll start working on those next actually.

Leo · Post by **Leo** » Thu Jul 23, 2015 3:41 pm

I keep bringing you bad news, now for some good news....

I just tried 1.4.2.8 on my laptop with Win 8.1. Your exe32 runs perfectly without any lag! I tried my exe32 as well and it works also.

Oh my, now for the bad news.... again, font upload still doesn't work :cry:

shikra · Post by **shikra** » Thu Jul 23, 2015 4:51 pm

Well thats great on teh GUI - although I have no idea why!! I have changed to Java32. maybe a pc reboot on my part or something has amended it in some way. Haven't heard of these issues elsewhere though.
Anyway - all good on the GUI.

For font - Still working fine here. Just tried swapping again.
I am thinking of maybe creating an arduino uploader sketch with font built in. Remove PC for equation.

I did have issues with original KVOSD in early days. In those cases, I loaded minimosd onto the osd, used their uploader with the kvosd fontfile, then reloaded kvosd !! Might be worth atry if desperate!