copterrichie wrote:Please, EOSBanbi, may I ask for the addition MP_GPS_TIME to the protocol or to expansion the MSP_SET_RAW_GPS to include the GPS Time? Reason being, the Raspberry Pi does not have a realtime clock as well as many OSDs. I can set the time zone in my application.
Thank you.
It's not only the question of the protocol. GPS time does not used and not decoded.
Hi Folks ! Here is something for XMAS ! MultiWii 2.3 navi beta4 and WinGUI 2.3pre7
NOTE !!!! Save your settings, because there are changes in the eeprom structure, so your settings will reset to default....
Changes : MultiWii Moving all GPS related settings to EEPROM, and make them updatable via GUI. Fixing GPS lead filter (should not be used in bearing calculation) Minor changes in distance calculations Added header byte to naviSim protocol, to prevent misaligned packets Removed GPSfromOSD - use NaviSim instead.
WinGUI Added NAV related settings to the FC tuning panel. WP_radius setting now honored in the mission map drawings wp-radius and max_wp_number is saved to gui settings after first connect or any changes Added spoken notifications Remove telemetry link quality indicator use 3dr rssi instead Reworked waypoint markers
I also uploaded a MultiWiiNaviSim program. It is the GPS simulator what I'm using for testing during development. When enabled in config.h, the multiwii code sends the lat and lon banking information to the gps simulator and it translates it to movement, then sends back the updated gps coordinates in a standard NMEA packet. (No altitude and heading simulation!)
Hello! I tried to load the firmware radio ~ hm_trp.ihx on the two radio modules 3dr but I do not understand how you must do. I might have a little help? thanks
Hello! I tried to load the firmware radio ~ hm_trp.ihx on the two radio modules 3dr but I do not understand how do it. Where the files should be placed? I might have a little help? thanks
Perry wrote:Hello! I tried to load the firmware radio ~ hm_trp.ihx on the two radio modules 3dr but I do not understand how do it. Where the files should be placed? I might have a little help? thanks
Perry
Hi perry, you should use newest 3dr radio software, then you choose "upload custom fimware" then select hm_trp.ihx from EOS
Perry wrote:Hello! I tried to load the firmware radio ~ hm_trp.ihx on the two radio modules 3dr but I do not understand how do it. Where the files should be placed? I might have a little help? thanks
Perry
Hi perry, you should use newest 3dr radio software, then you choose "upload custom fimware" then select hm_trp.ihx from EOS
My MultiWii_2.3-navi-b4-xmas-fix doesnt work with WinGUI_2.3pre7(b4)-xmas. Neither USB nor with BT. Old version of GUI works fine with b4-xmas. Am i doing smth wrong?
dm571 wrote:My MultiWii_2.3-navi-b4-xmas-fix doesnt work with WinGUI_2.3pre7(b4)-xmas. Neither USB nor with BT. Old version of GUI works fine with b4-xmas. Am i doing smth wrong?
did you changed the Serial speed back to 115200 in config.h ? I Think i left It at 57600
Yeah, there was 57600 and both ver GUI didnt work. I changed to 115200 and old version works fine. But x-mas still reports an error. P.S. Sorry for my English..
dm571 wrote:Yeah, there was 57600 and both ver GUI didnt work. I changed to 115200 and old version works fine. But x-mas still reports an error. P.S. Sorry for my English..
I can look into it in this evening. Please send me your config.h and state what kind of board are you using.
dm571 wrote:Yeah, there was 57600 and both ver GUI didnt work. I changed to 115200 and old version works fine. But x-mas still reports an error. P.S. Sorry for my English..
I can look into it in this evening. Please send me your config.h and state what kind of board are you using.
Ok, I found it. It's a logic error in displaying RTH altitude. It will be fixed in the next release, meanwhile please set an exact RTH altitude (larger than 5 meters) in config.h then clear the EEPROM and upload sketch again.
I tested the Nav Beta too today ( Xmas release ) Works fine so far. Only thing is if you use a larger distance between 2 ponits it overshots very much. I try to reduce max navigation speed 150 cm/s.
Tested it with the EZ-Gui Beta and all works fine. Only when trying the POI function the copter makes crazy stuff
I tested the Nav Beta too today ( Xmas release ) Works fine so far. Only thing is if you use a larger distance between 2 ponits it overshots very much. I try to reduce max navigation speed 150 cm/s.
Tested it with the EZ-Gui Beta and all works fine. Only when trying the POI function the copter makes crazy stuff
Norbert
First please try with WinGUI since this is the currect dev environment, I cannot guaranty working of any functions with EZ-GUI. It you experience the same behavior with WinGUI then please report it as a bug
for overshoot, enable GPS lead filter and slow naw.
Rcg4scuba wrote:Hello, I hope this is the place to ask this; I cannot launch WinGui 1.04 or 2.1 an error pops up-
Invalid Data Options files contains invalid data around Line:7 Unable to continue! I am running Win7 64bit
Thanks for your assistance- before posting here, I have looked/searched through this forum and others for an answer with no success.
I have checked/installed the pre-requisites listed (.Net, etc)
Again- thank you. RG
Actually this is a wrong forum... But, redownload the wingui version and extract with WinRAR or winZip. It should work. Check optionsconfig.xml file for errors.
If you want use WinGUI on the field without internet connection, you can cache satellite map images for a given region. To do that, zoom out to show your planned flight zone, then with ALT+left click mark the area you want to cache, then click on the FETCH MAP button. The satellite images for all zoom level are cached to the disk and available offline.
EOSBandi wrote:If you want use WinGUI on the field without internet connection, you can cache satellite map images for a given region. To do that, zoom out to show your planned flight zone, then with ALT+left click mark the area you want to cache, then click on the FETCH MAP button. The satellite images for all zoom level are cached to the disk and available offline.
Perfect! Thank you very much! Going to test again tomorow and then post my experience here.
Hi EOS, i have a patch submission i want to give to you, it adds the gps time into the MSP, can you add it in a future MW release ?
currently it just grabs the time you already read out of the ublox protocol, but im guessing you would/could also add the time if using mtk and nmea or binary as well.
also i wasnt sure which part of the MSP to add it, as the GPS_RAW bit is full
Works fine with WinGui so far only POI Problem is the same as with EZ-Gui :
When I set a POI and the a circle arround ( in my setup today 25m circle 16WP and 1 for direction ) the copter starts to fly to first WP and then does strange things. The Copter flies big circles and it looks like he can´t find a waypoint. Nothing else happens. After 2 Minutes crazy flying I canceld the Mission
Works fine with WinGui so far only POI Problem is the same as with EZ-Gui :
When I set a POI and the a circle arround ( in my setup today 25m circle 16WP and 1 for direction ) the copter starts to fly to first WP and then does strange things. The Copter flies big circles and it looks like he can´t find a waypoint. Nothing else happens. After 2 Minutes crazy flying I canceld the Mission
Is there a mistake in the code maybe?
I will post the Video later!
Norbert
Hi, please send the mission file to me for testing....
Ohh, I tested it... if your waypoints are closer to each other than the wp_radius then it will not work..... get a larger circle or less wp.... or decrease the wp_radius....
copterrichie wrote:Please, EOSBanbi, may I ask for the addition MP_GPS_TIME to the protocol or to expansion the MSP_SET_RAW_GPS to include the GPS Time? Reason being, the Raspberry Pi does not have a realtime clock as well as many OSDs. I can set the time zone in my application.
Thank you.
It's not only the question of the protocol. GPS time does not used and not decoded.
it does not necessarily need to be decoded or used by MW, just a common format agreed apon, that could be as it is in the ublox millisecond of week format, in that case it can simply be added to the MSP
copterrichie wrote:Please, EOSBanbi, may I ask for the addition MP_GPS_TIME to the protocol or to expansion the MSP_SET_RAW_GPS to include the GPS Time? Reason being, the Raspberry Pi does not have a realtime clock as well as many OSDs. I can set the time zone in my application.
Thank you.
It's not only the question of the protocol. GPS time does not used and not decoded.
it does not necessarily need to be decoded or used by MW, just a common format agreed apon, that could be as it is in the ublox millisecond of week format, in that case it can simply be added to the MSP
Thanks. I appreciate your efforts particularly as you are busy with the gps nav work. I would not have bothered you except it seems you are likely the one heading this area of development in mw project.
haydent wrote:Thanks. I appreciate your efforts particularly as you are busy with the gps nav work. I would not have bothered you except it seems you are likely the one heading this area of development in mw project.
I just flashed your version successfully and will test it as soon as I get the entire copter reassembled after some changes.. But what came to my mind during flashing is how to handle the loss of signal in waypoint mode.. I believe there may be many users that might use waypoints that are out of the RC range for whatever reasons (far away, buildings, hills, canyons...). Right now we assume for failsafe that there is a real failure and it is probably safer to just go down slowly and shut off engines.. which is not my favorite solution but plausible. However... in case of waypoint navigation it might be more dangerous and very annoying (besides the costs for spare parts and time to find the copter )to use the standard failsafe. Therefore id suggest a "ignore all singal losses as long as in mission mode" option or a RTH failsafe. I couldnt find anthing about this topic yet but think its important.. Are there plans yet ?
possible failsafe events: loss of RC control low battery copter too far from home copter is too high
Current failsafe implementation is a joke. All it is doing is a semi controlled crash. What I think is : selectable options how to handle failsafe situation: in mission mode then continue hold position and altitude; hold position, land and disarm; RTH at current altitude; RTH at given altitude; when @ home : hold pos; hold pos+descent to given altitude; hold pos and land+disarm
Another failsafe scenario. Copter moving away from desired position, not closer. ie. due to high wind, poorly or incorrectly defined MAG, etc, craft should land + disarm or something other than flying further away.
go to designated waypoint at current altitude go to designated waypoint at given altitude
just brainstorming ...
Another failsafe scenario. Copter moving away from desired position, not closer. ie. due to high wind, poorly or incorrectly defined MAG, etc, craft should land + disarm or something other than flying further away.
yes abort flight option, as i have had a fly away in wind too
haydent wrote:go to designated waypoint at current altitude go to designated waypoint at given altitude
just brainstorming ...
Another failsafe scenario. Copter moving away from desired position, not closer. ie. due to high wind, poorly or incorrectly defined MAG, etc, craft should land + disarm or something other than flying further away.
yes abort flight option, as i have had a fly away in wind too
I does not like to copy arduplane/copter functions, but they have things called rally points. These points are defined independently from the mission. And during the mission, in case of failsafe the closest rally point is selected to go to instead of home.
I'm going thru the requirements for failsafe functions... it seems it need full autonomy, which means that under certain circumstances the navigation engine must ignore stick movements and override rcOptions. It is quite frightening to me... what safeguards do you recommend to make it safe ?
Without any type of obstacle avoidance mechanism, the safest in my opinion, go to a safe predetermined altitude then return to home. Anything else, it is just too much of risk.
What situation requires to ignore stick inputs? Personally I think you are right the be frightened, in my opinion sticks should never be ignored under any circumstances.
felixrising wrote:What situation requires to ignore stick inputs? Personally I think you are right the be frightened, in my opinion sticks should never be ignored under any circumstances.
felixrising wrote:What situation requires to ignore stick inputs? Personally I think you are right the be frightened, in my opinion sticks should never be ignored under any circumstances.
+1
but when "Stop Mission" is still avaiible, it's ok
felixrising wrote:What situation requires to ignore stick inputs? Personally I think you are right the be frightened, in my opinion sticks should never be ignored under any circumstances.
+1
but when "Stop Mission" is still avaiible, it's ok
in common cases the throttle input must be ingnored (In baro mode....), but nav should takeover control of baro mode so it will takeover throttle input. When initiating RTH for failsafe caused by hitting fence distance, you also should ignore stick input. Since you are handling a failsafe caused by wrong stick inputs..... Switching off from nav/gps mode will always returns control to you..... If a nav/gps mode is initiated automatically (failsafe) a quick switch to poshold and back will also returns control....
some time (often ) when I navigate through mission map I get this error message, not sure if this a bug or not, just close and reopen the WinGUI
Hi Imen, Please define what do you mean navigate through ? What keys and/or mouse movements are you using. What is the exact version of the WinGUI ? Thanks, EOS
I just zooming both in and out and sometimes pan the map, like I said, not every zoom or pan event give error message. I use the newest one b4
thanks
Good catch... when you have waypoints on the map and you zoom out to a certain level, then the drawing of wp radius circles fails.... fixed now, fix will be included in the upcoming release. Thank you for your help ! Regards, EOS
yesyesyes... ....you're bringing me back to MW for my FPV-Copter, I bought an NAZA after NHadrian left MW and I saw no development on RTH Failsafe here, I was sad about this.