Direction to home


Hello,

Several days ago my OSD arrived ad I had a little bit time to test.

My main problem currently is, that the direction to home is not shown correctly.

As I want to use this copter for long range FPV the direction to home is in parallel to the consumed mAh the most important information on the screen.

I tried already to adapt the SRx parameter on my pixhawk as I know from my MinimOSD but it seens this didn´t helped.

Can somebody confirm this problem?

With kind regards,
Joerg
Has invited:

MPC561

Favor from: Tom


Thanks Tom,

In addition I would suggest to change the code in this way:

if(osd_got_home == 0 && osd_fix_type > 2 && motor_armed == 1)
{
osd_home_lat = osd_lat;
osd_home_lon = osd_lon;
osd_got_home = 1;
}

Reason:
The APM/Pix set is own homepoint when the copter is armed. To have no deviation here between the APM/Pix strategy I would suggest to do it in the same way.

Another argument. I know Pilots which Power their copter already when they arrive at their parking place and the walk several hundreds of meters to their flying place (intention is to get already a Satfix while they are walking). in this case the homepoint would also be too far away from the startpoint.

Greets,
Joerg

JohnG

Favor from: Creotom


The last couple of times I used it, it worked fine. I allowed it additional time to acquire a strong GPS fix before arming. I don't know if that made a difference.
I have no sense as to whether this is just a problem for me (ie I have done something wrong) or whether it is still a common issue.
So feedback from other users would be really nice.
The problem is quite obvious if you have it. It doesn't affect the Return to Launch function or other waypoints, just the home direction on the OSD.
I really prefer this OSD to the Minim OSD which looks really cheap and clunky by comparison.

Tom - PlayUAV

Favor from:


Hi Joerg,

Thanks for your feedback. I retested the home and waypoint direction. It is true that the current firmware direction display is wrong. I will fix this problem ASAP.

As to "current consumed in mAh", though I also consider it very useful information, we cannot attain it because the current APM firmware doesn't support this function. Please refer to the following link for details:

https://github.com/PlayUAV/PlayuavOSD/pull/13

Best,
Tom

MPC561

Favor from:


Hi Tom,

I added already a comment at github. I´m wondering as this function is available in Extra OSD for the old MinimOSD hardware. After I checked out the old firmware I found in the mavlink libary following structure:

define MAVLINK_MESSAGE_INFO_SYS_STATUS { \

"SYS_STATUS", \
13, \
{ { "onboard_control_sensors_present", "0xx", MAVLINK_TYPE_UINT32_T, 0, 0, offsetof(mavlink_sys_status_t, onboard_control_sensors_present) }, \
{ "onboard_control_sensors_enabled", "0xx", MAVLINK_TYPE_UINT32_T, 0, 4, offsetof(mavlink_sys_status_t, onboard_control_sensors_enabled) }, \
{ "onboard_control_sensors_health", "0xx", MAVLINK_TYPE_UINT32_T, 0, 8, offsetof(mavlink_sys_status_t, onboard_control_sensors_health) }, \
{ "load", NULL, MAVLINK_TYPE_UINT16_T, 0, 12, offsetof(mavlink_sys_status_t, load) }, \
{ "voltage_battery", NULL, MAVLINK_TYPE_UINT16_T, 0, 14, offsetof(mavlink_sys_status_t, voltage_battery) }, \
**{ "current_battery", NULL, MAVLINK_TYPE_INT16_T, 0, 16, offsetof(mavlink_sys_status_t, current_battery) }, **
{ "drop_rate_comm", NULL, MAVLINK_TYPE_UINT16_T, 0, 18, offsetof(mavlink_sys_status_t, drop_rate_comm) }, \
{ "errors_comm", NULL, MAVLINK_TYPE_UINT16_T, 0, 20, offsetof(mavlink_sys_status_t, errors_comm) }, \
{ "errors_count1", NULL, MAVLINK_TYPE_UINT16_T, 0, 22, offsetof(mavlink_sys_status_t, errors_count1) }, \
{ "errors_count2", NULL, MAVLINK_TYPE_UINT16_T, 0, 24, offsetof(mavlink_sys_status_t, errors_count2) }, \
{ "errors_count3", NULL, MAVLINK_TYPE_UINT16_T, 0, 26, offsetof(mavlink_sys_status_t, errors_count3) }, \
{ "errors_count4", NULL, MAVLINK_TYPE_UINT16_T, 0, 28, offsetof(mavlink_sys_status_t, errors_count4) }, \
{ "battery_remaining", NULL, MAVLINK_TYPE_INT8_T, 0, 30, offsetof(mavlink_sys_status_t, battery_remaining) }, \
} \

So maybe you can take again a look. And if I´m wrong forgive me as I´m not so familiar with coding.

Greets,
Joerg

MPC561

Favor from:


"current_battery", NULL, MAVLINK_TYPE_INT16_T, 0, 16, offsetof(mavlink_sys_status_t, current_battery) },

Tom - PlayUAV

Favor from:


Hi Joerg,

The "current_battery" in MAVLINK_MESSAGE_INFO_SYS_STATUS means the momentary value of the current flow, which is already displayed by PlayuavOSD, i.e. the "BatteryCurrent" item with unit A.

I understand what you really want is the consumed mAh info, which is an accumulated value. There is actually such information in MAVLINK, but unfortunately ardupilot doesn't support it. Good news is that the developers of ardupilot are considering to add this function, see https://github.com/diydrones/ardupilot/issues/1434

I have read your submission at github. It is true that we can get the value through formula computing. But I think before the APM developers adding this feature to the firmware, it is worth a try to see if we can solve the problem with simulate computing.

Best,
Tom

Tom - PlayUAV

Favor from:


Hi Joerg,

The home and waypoint direction issue has been fixed. I have tested on HITL with pixhawk and X-Plan. I recommend that you use the map-like orientation as shown below:

osd.jpg


MPHITL.jpg


The pictures are map-style(North: up, South: down, West: left, East: right).The arrow stands for the UAV heading, "H"stands for home, and the number stands for the current way-point. So from the picture above we can see that the UAV is heading northeast toward waypoint 2 while home is located at northwest.
And the pictures below tell us that the UAV is flying toward waypoint 3. If you want to return to home, you need only adjust the head and aim it at H and fly forward. You can also judge if you are flying at the right direction by checking the distance(keeps decreasing).

osd2.jpg


HITL2.jpg


You can update this firmware using the config tool. Please let us know if it works all right.

Best,
Tom

MPC561

Favor from:


Will do the update this evening and test it tomorrow.

Thanks Tom, you are very reactive. :-)

Greets,
Joerg

MPC561

Favor from:


Hi Tom,

I tried it this evening.

Test scenario:
Test 1:
waited for 7 satellites until I armed and started:
I did a flight with my copter to a point approx. 2km away from my starting point. Then I wanted to fly home based on the Map/circle. As I know the area/region I was able to get my copter in the right home direction. The arrow did not show to the "H" in the map. There was a deviation approx 40 degree.

Second Test:
1km distance flight. At 1km distance I put the copter in the direction the minimap showed as home direction with a daviation of approx 5 degree left of my starting point.
Then I flight in this direction. So that the copter passed me right of my position/starting point. When he passed me the "H" in the minimap moved and pointed in the right direction (means my position).

So my conclusion. On short range the direction is shown correctly but on higher distances there seem to be a increasing deviation.

Maybe float calculations in with high values? Float looses accurracy as more as the values are away from zero. Or graphic problems?

In the GUI I see also the "H" not only in the map, I see it also in the compass. But in reality there is no H there. Maybe such a presentation of the "H" would be more accurate?

Greets,
Joerg

MPC561

Favor from:


One question in addition.

Are there several configuration which need to be done in Missionplaner? Need the SRx parameter to be adapted? Maybe the home posistion is simply not actualised?

Tom - PlayUAV

Favor from:


Hi Joerg,

I re-checked the algorithm of the direction calculation, but saw no problem. Here is a python script which can easily verify the algorithm. When we set the way-points using MissionPlanner, we can get an azimuthal angle(AZ) at the way-points list, specifically, the AZ of WP#1 is the bearing of WP#1 relative to the home. So when we put the GPS coordinates of home and WP#1 into the python script, it will show us an angle which should be equal to the AZ in MP plus 180 degree, because we need the bearing of home relative to the WP#1.

Theoretically, if the GPS coordinates are correct, the calculated direction should be accurate, not being influenced by the distance between two points. Nevertheless if the weather permits, I will do a real flight.

FYI, the new firmware has been released, please see: http://en.playuav.com/article/2

Regards,
Tom

MPC561

Favor from:


Hi Tom,

tested a bit at home. Powered the copter, had after several minutes a satfix with 6 Satellites. Copter showed a distance from home immedialtely after the fix with 23m. Then I armed the copter. No new homepoint was set in my opinion! Normally with 6 sats your HDOP should be lower then 5m.

So maybe something with the set of the homepoint does not work perfectly or me has a GPS problem, but this is inplausible as I flow today a mission with a length of approx. 2 km and all waypoints were covered perfectly.

See here:
http://www.droneshare.com/mission/135619

Tomorrow I will make a test if the waypoints are shown correctly. From the today mission I had in my mind that they worked, but I´m not 100% sure.

Hope your weather will be good,
Greets,
Joerg

Tom - PlayUAV

Favor from:


Hi Joerg,

Apparently the problem is not in the algorithm. It is more like to be caused by the way we define the location of Home. Currently when GPS is locked at a 2D position, we take the GPS coordinates as the location of home. Code as shown below:

the head of the function hud_draw_CWH in file osdproc.c
osd_fix_type - GPS lock 0-1=no fix, 2=2D, 3=3D
if(osd_got_home == 0 && osd_fix_type > 2){
      osd_home_lat = osd_lat;
      osd_home_lon = osd_lon;
      osd_got_home = 1;
}


In most cases this method works but under certain circumstances, e.g., when a GPS is just started and not steady yet, the information it gives cannot be accurate. I think we can try adding filtering and more judging conditions.

For now I have compiled a test firmware which will take GPS coordinates only when it is 3D locked(osd_fix_type > 3). It should improve the situation, but I am not sure how useful it can be.

Best,
Tom

MPC561

Favor from:


Hi Tom,

flashed 2h ago the Test SW. The direction is still not shown correctly.

More and More I believe that it is only a visualisation/display Issue because the distance to home is shown, in my opinion, correctly.

Greets,
Joerg

Tom - PlayUAV

Favor from:


Hi Joerg, I am just back from the test flight. You are right, there is something wrong with the home direction. The east-west direction is correct, but the south-north direction is contrary. I will check the code carefully and do more tests.

Best,
Tom

Tom - PlayUAV

Favor from:


Yes Joerg, it is good idea to set homepoint when armed. Would you like to submit a Pull Request at github?

Cheers,
Tom

MPC561

Favor from:


Beg your pardon Tom,

I´m not a real SW guy. Be able to read easy C-Code and know that Github is a kind of Version management, but don´t know what to do there.

Greets,
Joerg

Tom - PlayUAV

Favor from:


Hi Joerg,

No need to worry:) I will add your code to the firmware and do the test. I still don't get what is wrong with the home direction, will look into it tomorrow.

Best,
Tom

Tom - PlayUAV

Favor from:


Hi Joerg,

The home direction issue has been fixed. And I have added a condition to set home-point when armed. You can update the firmware using the Config Tool.

It is a low-level bug. The var osd_home_bearing is degree which I used it in trigonometric function.

Best,
Tom

MPC561

Favor from:


Hi Tom,

2h ago I did the update via config tool. The direction to the waypoints is working perfectly, but the direction to home is still not working. It is frozen in the nord position of the circle.

Greets,
Joerg

Tom - PlayUAV

Favor from:


Hi Joerg,

1 hour ago I tested my copter in radius 0-300m for about 10 mins. It worked well. Hope it is really fixed this time:-). Please tell me how it goes with your test.

Cheers,
Tom

MPC561

Favor from:


Hi Tom,
Still not working for me. Also not in short range.

Maybe somebody else then me should test in addition as maybe me is the problem.

I flashed it yesterday from OSD-Configtool and tested it today as it rained yesterday.

Greets,
Joerg

Tom - PlayUAV

Favor from:


Hi Joerg,

This really sounds confusing. Could you give me more information about your flight? I suggest you arm the UAV until the GPS satellites reach above 7 and HDOP drops down to 2.0. The OSD will take current GPS as home location.

Regards,
Tom

MPC561

Favor from:


Hi Tom,

Exactly,
this time I had at arming 10 satellites.

The arming Position was this one:

GPS: 49.127467, 12.183017

After Start I moved the copter in this direction to approx this point:
GPS: 49.128847, 12.186067

At the last point I started to turn my copter slowly to my home position but the "H" was not shown correctly when I directly looked via FPS to the ARM/START direction.

Greets,
Joerg

Tom - PlayUAV

Favor from:


Hi Joerg,

I applied your GPS to my python script which uses the same algorithm as the OSD firmware. Suppose the UAV is at the origin coordinates(0,0) and the circle radius is 20, the home coordinate will be (-16.45, 11.37). The first line of output is the AZ of home relative to UAV.

pyresult.jpg


The OSD should display as below, meaning that Home is in the southwest relative to UAV. Is this how your OSD displays?

sim1.jpg


Regards,
Tom

MPC561

Favor from:


Hi Tom,

It seems that I need really to beg your pardon.

Today I tested again (on another place):
- Waited for 8 Sats
- moved the copter to the SOUTEAST and turned him in startpint direction --> the arrow pointed perfectly to H
- moved the copter to the SOUTHWEST and turned him in startpint direction --> the arrow pointed perfectly to H
- moved the copter to the NORTHWEST and turned him in startpint direction --> the arrow pointed perfectly to H
- moved the copter to the NORTHEAST and turned him in startpint direction --> the arrow pointed perfectly to H

So I don´t know what happened last time when I tested, maybe there were not 10 sats when I armed, maybe in reality there were only 0. The test was fast as it´s rainy in germany and I didn´t want to risk my copter.

Attached the pictures from todays test:
1. Before takeoff with 8 Sats
The other 3 are from 3 different directions to the homepoint (the car where the 3 roady met).

IMG_20150820_094149.jpg


IMG_20150820_094333.jpg


IMG_20150820_094238.jpg


IMG_20150820_094508.jpg


Again,
beg your pardon.

Greets,
Joerg

Tom - PlayUAV

Favor from:


Hi Joerg,

Great! I am really happy to hear that the problem has been solved. And there is no need to apologize at all, because I should thank you for helping me improve the OSD. I also want to thank you for spending so much time doing the test.

I assume the problem of yesterday might be caused by GPS drift. Anyway, we should keep an eye on this issue and see if it could be improved in the future.

FYI, I have added channel 9-16 for switch video and panel.

Best regards,
Tom

MPC561

Favor from:


Hi Tom,
At the moment I´m still on Arducopter 3.2.1, so I can´t use this feature as It was implemented with Arducopter 3.3rc1 (iirc) and, to be honest, I need first to check if my FRSKY L9R receiver is able to give more then 8 channels via SBUS to the Pix. Currently I use Channel 6 for Video switching and Ch8 for Panel Switch. I will surely test this when Arducopter 3.3 is finally released.

But another question, would it be good to start a kind of brainstorming thread to collect ideas for additional features? I Have at least one very interestig, something what I have until know not seen in any OSD but what should be possible to realize withe this hardware?

Greets,
Joerg

Tom - PlayUAV

Favor from:


Hi Joerg,

Thanks for your advice. It is a brilliant idea. I have made a post here:http://en.playuav.com/article/3

Please write your ideas on future features in the post. We look forward to hearing more suggestions from you.

Many thanks,
Tom

3dsky - Flying with the best

Favor from:


I have encounter only one situation when after arming with a hdop of 0.9 and 11 sats, the home was somehow reversed 180 degree, meaning the arrow pointed home direction with its back. Something like home is in front of aircraft and osd shows 'H>' after passing home and flying away from it arrow changed to 'H<' Landed, reboot and everything was back to normal.

JohnG

Favor from:


Took the PlayUAV OSD on its first flight today.
Love it!
The only glitch was with the Home Direction where North and South seem to be inverted.
I have the latest firmware.
I see others encountered this problem last year. Has it been resolved?
Thanks very much.
John

JohnG

Favor from:


ADDENDUM:
The North-South inversion seems to have corrected itself.
Don't know what to make of that but apparently OK now.
John

gnrc

Favor from:


That would be good because a couple people are reporting what seems to be intermittent issues,
but it could just be, that the radar image is not as easy to read as a simple arrow pointing at home.

JohnG

Favor from:


The inversion was real. In fact I recorded it on video.
On the video for example the plane taxis in a southward direction toward Home but the H is located at the top (north) of the map.
Curiously despite the fact that the arrow is pointing south away from the H in the north, the distance to Home correctly reduces to zero as the plane taxis south.
I will be taking the plane out again tomorrow so I will see what happens.
John

JohnG

Favor from:


Seems to have fixed itself.
All good.
John G.

JohnG

Favor from:


Took the plane out again with the PlayUAV OSD today.
Home is misbehaving again. Now the Home direction is correct but the displayed distance to Home grossly underestimates the true distance.
So when Home is about 1km away, the OSD indicates about 120m.
So near yet so far.....

gnrc

Favor from:


Working on it, if you can build the config tool yourself (and are using linux) or running os x - use the latest osd and config tool and enable the gps home lat and longitude and please do record your feed.
If it misbehaves again please do post (or send me a link to a private video) so I can take a look.
Currently the weather around here is unflyable or I don't have time so any help in finding the problem is hugely appreciated.

JohnG

Favor from:


Thank you gnrc.

JohnG

Favor from:


PS I have to say yet again that I like this product very much so I hope you can iron out the little glitches.

gnrc

Favor from:


Well since I now have one of those osds in prety much everything I fly (except mini quads), so do I ;)

Patryck

Favor from:


Hi, Guys!

Firstly I would like say, this OSD is a great product. I am still testing, if it to work safely, I will to buy more units.

Yesterday, I had an issue with home point too and the plane flied to 15KM, during go back to the home, half of way the home point changed the position in the screen. I continued following the home point when I saw increasing the home distance, then I used the RTH key and plane changed the course and flied in direfent path.

Can anybody knows the issue? I have saw many persons talking about this issue with home point. So thanks to RTH feature in the Pixhawk flight controller.

Regards, Thank you PlayUav.

JohnG

Favor from:


Hi
I continue to experiencing problems with the North-South orientation of the Home direction which I have illustrated in the attached images.
Each image is taken as my plane lands on an airstrip in a westerly direction.
The setup area is on the left (South) and should be Home.
The two flights are separated by just a few minutes after a change of battery.
In the first flight the Home icon indicates incorrectly that the Home position is located to the North of the airstrip (93m from the plane)
In the second flight the Home icon correctly indicates that the Home position is located to the South of the airstrip (33m from the plane).
Any advice accepted with gratitude.
Kind regards
John

JohnG

Favor from:

gnrc

Favor from:


Thanks for the picture, I will take a look and hopefully do some testing myself soon too.
What would be helpful if you could use the new config tool etc and enable the home gps coordinates too

JohnG

Favor from:


OK thanks.
I'll endeavor to do that in the next few days..
John

gnrc

Favor from:


Small update: if you fly fixed wing you can set use_compass to 0 in arduplane.
Reports so far are good. It seems to be related to the magnetometer, still trying to figure it out.

JohnG

Favor from:


I'm afraid setting use_compass to 0 made no difference for me. North and South are still inverted on the map.
Also I haven't been able to enable the home GPS coordinates for testing as you have suggested. Is there a "new config tool" I should be using? Sorry I didn't really understand what I was supposed to do.

JohnG

Favor from:


By the way, I should mention that my external GPS and compass setup is facing backwards (180 degree rotation). Perhaps that is relevant and I should have mentioned it sooner..
John

gnrc

Favor from:


Interesting point, if I get some time I will give that a try, might explain it though.
Also I converted the config tool to a chrome extension since it is easier to maintain/upgrade.
It can be found here https://chrome.google.com/webs ... r%3D1

Creotom

Favor from:


Has this home direction been resolved yet?
I just ordered this OSD and I'm not sure if I should risk installing it if the guidance is not correct.

Creotom

Favor from:


Thanks!
When you say "The problem is quite obvious if you have it" I am reassured to give this a go.
My real worry is that I could be half way into a mission and suddenly have to deal with wonky directions.

JohnG

Favor from:


Hi Creatom

I would be very interested to hear how you go.

Maybe my setup is wonky because no-one else seems to be complaining about it any more and the last couple of times when I gave it extra time to get a good GPS fix, the direction was fine.

gnrc

Favor from:


We just merged the fix into master.
TheRealG tested it quite extensively but please don't rely on it a 100% on the first couple flights, just in case we did get it wrong (does not seem that way)
Please remember to calibrate your compass if you use it!

see https://github.com/TobiasBales/PlayuavOSD for the download link

Solhead - Spanish

Favor from:


Hello,

I'm having the same problem with my OSD , she tells me all values ​​perfectly values ​​, less GPS, heading home and GPS status.

If I disconnect the PLAYUAV OSD and connect my old minimosd, the values ​​appear perfectly in the minimosd ... generic values and ​​all values ​​of GPS , heading home , coordinates, etc ...

This suggests to me that there is a problem in the PLAYUAV OSD , and there is only him related to the GPS . I use a Pixhawk and goes perfectly with the Minimosd , but not right PLAYUAV OSD GPS.

Can someone tell me Pixhawk settings and values ​​that takes in its Pixhawk ?

A greeting and I hope soon to solve the problem. a greeting

qczek - Hi, I'm interested in RC and emebeded software development :)

Favor from:


HI,
Yesterday i did first flight with playuav osd (latest firmware) and i can confirm, that direction to home issue is not fixed. Please see screenshot below taken during RTH.

wrong_home1.png


Maybe you use different/not updated gps coordinates in different firmware's routines?
On panel no 2 GPS coordinates are not initialized at all, maybe it's similar issue?

wrong_home2.png


Panel no 3 shows home and uav heading in correct way :)

wrong_home3.png


Regards
Krzysiek

StewLG

Favor from:


Krzysiek:

I'm so sorry this bug is still effecting you. I crashed a plane in part because of it, and I've been trying to fix it since.

Which exact version did you run? Was it the classic PlayUAV repo (https://github.com/PlayUAV/PlayuavOSD)? Tobias's new repo (https://github.com/TobiasBales/PlayuavOSD)? Something else?

Again, my apologies for this bug. It's bad and it needs fixing. We appreciate your help.

lexgerito

Favor from:


I'm not sure if its correct thread to ask, but still: I've got a problem of incorrect showing of distance to home - its almost doubled of real distance. For example - last flight - screenshot is in attachment. Total distance is just 1.83KM, and distance to home is 3.28KM. How is it possible? Tried with original firmware and Tobias one - same story.
When I look into Mission Planner - it shows correct distance (flying with Ultimate LRS, so I can see telemetry in Mission planner while flying).

StewLG

Favor from:


Lexgerito: It's not a bad place to ask, since you'll get a reply.

I have had problems with the distance in PlayUAV too, and that's why I re-wrote the relevant routines, thinking that might be the problem. It is currently poised to be merged into Tobias's fork, but if you are impatient you can try it now.

When testing these sorts of bugs, I encourage you to display the home position and the current position on screen. You erased what I assume is the current position, but having both on the screen lets you test distance calculation after the flight with a screen grab - see here for example.

Finally, while I do think my revised distance calculation is better than what was there, I am not sure the original routine explains the very large errors you and I both saw in distance. I have an idea I am working actively on right now, and I'll have that available for testing. In the meantime, the above binary is definitely worth a try, since the few people who have tried it have had no problems so far.

lexgerito

Favor from:


Thanks! I will definitely try that out! And will post some screen to make calculation visible.

StewLG

Favor from:


Lexgerito / Krzysiek / anyone else:

Here is an updated binary with some additional potential fixes. I would really like to know what people find, good or bad.

StewLG

Favor from:


The fixes I refer to above are now in the Tobias branch. The latest version from the PlayAUV configurator should give you these improvements.

I would love to hear from anyone who tries it.

StewLG

Favor from:


Also, there's now a fix for the strange line problem shown in Krzysiek's Panel 3 (big map) screenshot above.

https://github.com/TobiasBales/PlayuavOSD/pull/27

StewLG

Favor from:


We've been making steady progress on bugs, and things are looking better and better.

If anyone is out there, and would like to test a significant overhaul, please try this:

https://github.com/StewLG/catf ... 6.zip

JohnG

Favor from:


Hi StewLG
Thank you so much for trying to resolve the Home problem.
I took my plane out three times yesterday. The distance to Home was correct on all three and the direction on the compass/map was correct in two out of three.
But on the first flight of the day, the direction on the compass/map to Home was inverted by 180 degrees as on previous occasions. It was not obvious what I might have done differently on the first flight versus the other two. This is the same intermittent problem I have encountered from the beginning. I cannot recall if it is always the first flight of the day that has been the problem.
I am sorry I did not include the Home GPS coordinates on my OSD. I will set that up next time.
I am sure this is as frustrating for you as it is for me.
John

JohnG

Favor from:


PS This problem occurred using your overhaul.

JohnG

Favor from:


Sorry it's not a simple 180 degree inversion. It's North-South inversion.
Is it conceivable that this has something to do with the fact that I am in the Southern Hemisphere? (dumb question)
John

StewLG

Favor from:


John:

Thank you for test flying. I'm very sorry you are still having problems!

Just to be absolutely sure, you were running "ConcurrencyFixesBeta1"? Did you get a version splash screen confirming that?

I doubt it is a southern hemisphere problem. The direction algorithm should not be sensitive to that. But it's not a dumb question.

If you have the time and patience, here's what I suggest if you can fly again:
  • Get home position on screen in addition to current position
  • Put the compass angle on screen (the one where direction is displayed as a 0-360 number)
  • DVR your flights
  • Note which exact version you are running if it isn't in the DVR footage


I have been trying to get another version together, but it isn't quite there yet and it won't change anything I would expect to influence home direction. So, feel free to upgrade when we put out something new, but there's no reason to wait for it - "ConcurrencyFixesBeta1" has everything I would hope might fix the home direction bug.

Again, my deepest sympathies. If you keep testing, we'll keep trying to fix it.

StewLG

Favor from:


And of course, please share the DVR footage of the flight, privately if necessary.

StewLG

Favor from:


This is a new test version with some hard-wired home direction debugging information that will appear below the home arrow:

https://github.com/StewLG/catf ... 6.zip

If anyone is flying, please use this version, have home position and current position also visible on your screen, and DVR your results. This should help us narrow down the cause of the failure.

My humble apologies for the many problems here.

JohnG

Favor from:


Thank you StewLG

I plan to set aside some time this weekend to do as you suggest because I really think this is a good product with this one apparently minor flaw.

I don't recall seeing the version splash "ConcurrencyFixesBeta1" when I believe I installed your overhaul. But I will install your new test version tonight and see what happens.

I tested the device again yesterday and the home coordinates would not display. I will try again tonight after installing your new test version.

When I tested the device yesterday the home position would appear correctly on the map/compass most of the time but on a couple of occasions appeared north of the correct location and then drifted. The problem appeared not to occur if I waited a few minutes after multiple satellites were acquired before arming the Pixhawk.

John

StewLG

Favor from:


John:

Thank you for your continued willingness to help test. The team does not think the home arrow is a minor flaw, however - it might be the single most important variable shown on screen, after battery voltage.

First, let me stress again that DVR footage can be enormously helpful to us. When I'm testing I regularly DVR what I have, then review the footage, cueing about to check things repeatedly.

When you say it failed to show home location ("home coordinates would not display"), do you mean it was all zeros? Did you have GPS lock of any kind? If you can make this happen again and DVR it, that would be very helpful so I can be sure I understand you.

In your final paragraph it sounds like you have armed before a solid position fix, and that this position fix might be wrong. But then you say the position drifted, and I'm confused. Did the home location as shown on the PlayUAVOSD change numerically? Or are you talking about the map display?

One thing that could use improvement in PlayUAVOSD is how home location is set. While making it correspond to the arm location is generally synonymous with the actual ArduPilot home location, I think we can do better and actually have it use the ArduPilot home location - at least when we can get it. Your problems might be improved if this were tightened up.

Regardless, I want to understand your difficulties. DVR footage is great, and don't omit a flight log (.bin) if you have it.

JohnG

Favor from:


I have loaded your latest test version successfully tonight.

The Home GPS location now appears for the first time on the OSD as intended. I could not make it appear at all before, only the current location.

When I spoke of "drift" of the home location before I meant that the "H" moved around the radar and the distance to Home increased even though the plane was still. As previously stated I could not see the Home GPS coordinates.
I agree that it sounds like the GPS had not fixed a position but 11 satellites were tracked and the Pixhawk armed happily.

Anyway It's dark here now, but testing the device in my garden tonight it seems to work well with the H correctly positioned on the radar and the Home coordinates correct and static.

I understand that it is difficult to describe this in words so I will definitely collect video over the weekend under varying conditions and send it to you if it glitches.

It is conceivable that I did not correctly load your latest version previously so maybe it will work without a problem. I will communicate with you whatever the outcome.

Thank you one more time for your help in resolving this.

StewLG

Favor from:


I don't want to jump to any conclusions, but if you are really seeing the numerical home coordinates displayed for the first time, that could indicate you were running an older version of the firmware. It's just this sort of confusion that made me put in an explicit version splash screen so it would be unambiguous which version you were running.

Just in case you don't know, or for anyone else, the configurator utility to be used with the Tobias firmware (and my test firmwares) is here:

https://github.com/TobiasBales ... rator

If you aren't seeing the version splash screen on boot, make sure the relevant time interval is set correctly in the configurator. Go to General (tab) > Firmware (panel) > "Milliseconds to show version dialog on startup". I've set it as high as 10,000 (10 seconds) to be sure I could see it while my VTX settled down when first powered on.

Let us know how it goes with your testing. The whole team is concerned about your issues, and we've been discussing them actively.

JohnG

Favor from:


Eureka!

I tested the device in the park today and it functioned without any error.
I will play with it some more over the weekend but it would appear that the previous problem with the home direction has been fixed.
This is an outstanding device!

Now it would appear as you suggested that my previous problem pertained to the firmware version I had installed although it wasn't obvious to me.
The version I have installed now is the "new test version with some hard-wired home direction debugging information that will appear below the home arrow" that was posted here yesterday.

I haven't been able to see the splash screen yet but I will worki on it tonight following the advice you have given above.

StewLG

Favor from:


I would be really glad to find out you were simply running an older version.

There are things we can/should do to make the configurator aware of which version of firmware it is talking to that would probably help with your confusion - I expect it is a common problem. It's not my top priority, but it is my second-to-top priority.

Again, be sure "Milliseconds to show version dialog on startup" is set to something high enough that you can see it. Read the settings from your PlayUAVOSD, change the value, then save again. I wonder if it isn't set to 0 right now, meaning it won't be shown. Let us know - it would be a problem, albeit minor, if you could not get the version dialog to show, and one I'd want to fix.

JohnG

Favor from:


Thanks very much.
It clearly changed when I installed your latest test version because the home coordinates appeared for the first time.
I'm pretty confident that you've solved the problem. Well done!!

It wasn't obvious that I had not successfully installed the previous update. I'm embarrassed to say also that I cannot work out how to get the "Milliseconds to show version dialog on startup" in the Firmware panel under the General tab. I spent quite some time on this last night and eventually gave up...

StewLG

Favor from:


JohnG: You are totally right it turns out! The control I expected to be there has not be released to the Chrome web store. It has been pushed into our source control, but Tobias hasn't produced a build for it.

When it does get updated, you should see "config tool version 0.10.0" in grey on the lower right. The version in the Chrome store is still 0.9.0.

I am usually running a local dev version so I did not realize Tobias had not pushed a new version.

StewLG

Favor from:


Until it gets updated there will be two time intervals you can't adjust, so if the "Milliseconds to show version dialog on startup" is stuck at zero you won't see the version splash dialog until you can get at that value using 0.10.0. Otherwise the firmware and the configurator should work fine though, despite the slight mismatch.

StewLG

Favor from:


In the latest version of the PlayUAV Configurator and firmware, the home arrow debugging information is now optional and configurable, defaulting to off for the moment.

At the moment we have no confirmed sightings of the home arrow bug, but should you believe you encounter it again, please take the following steps:
  • Be sure you are running the latest PlayUAV configurator (search in the Chrome store for "playuav configurator")
  • Download and install the latest firmware using the PlayUAV Configurator
  • Enable a flight panel with the following:
    • Home GPS position
    • Current GPS position
    • Home arrow
    • - Home arrow debugging information


DVR the resulting flight, hopefully including the boot of the firmware including the version splash screen, if possible.

Also helpful would be a .BIN flight log.

peterg

Favor from:


I'm using the PlayUAV OSD since quite some time and really would love it if there were two software glitches fixed...

The most serious issue is the home direction indicator. It is completely inaccurate and thus useless. I'm using here the MiniAPM autopilot. GPS, compass and RTL is working fine therefore it must be a problem within the PlayUAV OSD. The home direction indicator is essential for FPV. If your OSD doesn't show you the home direction then you need another OSD.

The other problem that bothers me is the camera switch. As you can see in this video I have two FPV cameras on my TBS Caipirinha. The main front cam and the rear cam. PlayUAV allows you to switch between these two cams which is a great functionality! But: After a few minutes of flight the camera switch stops working. Now if you get stuck in the rear cam you're fucked. Ok, you're not if your RTL is working and you still can land "line-of-sight".

I also noticed that the RSSI reading freezes as soon as the cam switch stops working.

My latest test video can be seen here:
https://www.youtube.com/watch?v=uQ0hMfftbcs

I hope these issues can be fixed. Otherwise I'm seeing myself going back to MinimOSD.

peterg

Favor from:


I noticed another interesting effect regarding the non-functionality of the video switch: Whenever I switch off and on the radio (the RC is TBS Crossfire PPM-Sum) to test the RTL behavior then the video / panel switch and RSSI reading is not working any more. It's like the channels 5,6,8 which I'm using for these are ignored by the OSD. When I unplug and re-pug the OSD it works again.

StewLG

Favor from:


peterg:

Response #1 - Home arrow

I'm seriously sorry the PlayUAV direction problem is still giving you problems. I've worked many hours on this and believe it to be working.

I wonder if you aren't running an older version of the PlayUAV firmware? I've done my best to publicize this, but perhaps I need to repeat it: A team of developers including myself has forked the original PlayUAV code and has been continuing development for the past few months. We've definitely made some improvements.

Here's a summary of what's going on, with some relevant links:

http://en.playuav.com/question/43

To make this perfectly clear:
  • If you are not running the Chrome configurator app to configure and update PlayUAV, you are running an old version.
  • If you do not see a version number splash panel on the OSD when you start up, you are running an old version.


All the recent reports of problems with home direction have been proven out to be the fault of old versions of PlayUAV. If you are running an old version, please update and try again. To repeat my directions above, please do the following if you want to provide FPV footage:

Be sure you are running the latest PlayUAV configurator (search in the Chrome store for "playuav configurator")
Download and install the latest firmware using the PlayUAV Configurator
Enable a flight panel with the following:
Home GPS position
Current GPS position
Home arrow
Home arrow debugging information

DVR the resulting flight, hopefully including the boot of the firmware including the version splash screen, if possible.

Also helpful would be a .BIN flight log.

If you don't want to put your GPS coordinates in public flight footage we can work out a private location to upload the footage for review. To check the home arrow problem we really do need all the above.

That said, I strongly believe your problem is due to old firmware. I just want to be complete with my directions to save time should you encounter more problems.

StewLG

Favor from:


peterg:

Response #2 - Switching issues

There are some switching specifc bugs we absolutely did fix in the current version versus older ones. I've also done a general pass on prospective concurrency issues, and believe that may help.

That said, it will not shock me to find we still have switching issues in the code. I have encountered just the issues you did with the display locking in flight, but I have not reproduced it on the ground in the debugger. I surely can, it just hasn't happened yet. So, please fly carefully where the camera switching is concerned. There have been a lot of bugs to fix and I've been trying to prioritize.

Last, I don't fully understand your complaint about the switches not working in failsafe (radio off). I would expect nothing to work if the radio is off. Maybe we need to take this part of your question offline?

I will also try to post a note on your flight footage to get your attention.

To reply to a question, please Login or registered