GPS NAV

HeliHaven · Post by **HeliHaven** » Fri Jul 25, 2014 1:36 pm

Hi,
Many thanks indeed for that. I had not realised there was an updated WinGui Version 2.3.5160.23771 - I was using Version 2.3.5127.41688 and was thinking it could be updated by way of the r100 file release. So used to updating things manually! Anyways, now I know where to get the latest version from - many thanks again. Just need to set up my GPS fully now and try a small mission around my local footbal pitches! Great fun!

DorsetFlyer · Post by **DorsetFlyer** » Wed Jul 30, 2014 1:48 pm

I could do with some help physically connecting the Ublox NEO-6M GPS module to the Crius AIO board. The Ublox has a 4-pin Molex the other end of which terminates in a 5-pin Molex. As I am powering the board from an ESC, I understand that I need to connect the Ublox Tx and Rx to Serial 2 Rx and Tx, but the 5V and Ground to the I2C port. I don’t suppose you can buy a suitable adaptor, so it looks as if I need to make one up. I would appreciate some advice how to do this.

stronnag · Post by **stronnag** » Wed Jul 30, 2014 5:10 pm

I did as you've worked out. Took the 5v from the I2C (or maybe Vcc as I power my board from 5v --- don't do this is powering via Lipo), RX/TX (and perhaps ground) from the serial port. It's a bit messy, particularly if you're using multiple serial devices (GPS, 3DR or BT, Spek Sat etc), but it works fine. I recall I cut the supplied cables and made up some connectors compatible with those on the devices I wanted to attach for the GPS and 3DR.

o_lampe · Post by **o_lampe** » Thu Jul 31, 2014 8:02 am

DorsetFlyer wrote:I could do with some help physically connecting the Ublox NEO-6M GPS module to the Crius AIO board. The Ublox has a 4-pin Molex the other end of which terminates in a 5-pin Molex. As I am powering the board from an ESC, I understand that I need to connect the Ublox Tx and Rx to Serial 2 Rx and Tx, but the 5V and Ground to the I2C port. I don’t suppose you can buy a suitable adaptor, so it looks as if I need to make one up. I would appreciate some advice how to do this.

I tried it without soldering. Just removed 5V and GND from the connector and replugged them in another 4 pin connector I had as spare. Secure both connectors with a glob of hotglue, after you tested the function.

DorsetFlyer · Post by **DorsetFlyer** » Thu Jul 31, 2014 3:21 pm

GPS Wires.jpg: (42.87 KiB) Not downloaded yet

Thanks for the advice chaps. Once I’d worked out that you had to lift the tab to remove the pins it was straight forward. I took the four pins out of the 5-pin plug, split it to get two 2-pin plugs and pushed the pins back in the appropriate holes. They hold well and it all works.

brewski · Post by **brewski** » Thu Jul 31, 2014 9:46 pm

Hi DF,
Are you going to use the onboard Mag or an external Mag board. If former, twist up the DC leads to ESCs & mount FC as high as you can above distribution board.
Even with my Crius AIOP V2 20mm above dist board the compass shown in WinGUI would deviate by >30deg with props on & full throttle.
On Crius AIOP V2 which I see you have it is very easy to disconnect onboard Mag, just cut links on J2 & J3.
You then modify the MW 2.3 Navi b7 def.h (not config.h).
Under #if defined Crius_aiop_pro_V2_v1 uncomment (//) out line-
#define MPU6050 _12C _AUX_MASTER //MAG
Save & then upload to your FC.

I mounted ext Mag board on CF square tube out front of quad & now have no deviation.

DorsetFlyer · Post by **DorsetFlyer** » Fri Aug 01, 2014 9:08 am

Hi brewski, thanks for the advice.

I am using the onboard magnetometer and I have laid out the leads symmetrically and twisted each pair. The flight controller is 60 mm above the distribution board. I tested with a compass sitting on the FC and could not discern any deflection at normal current. I have only made one short flight with the Crius AIO but with HORIZON + MAG the heading was held well.

I tried out HORIZON + BARO and did not get the vertical fly away that I had with the Hobby King MultiWii Pro but although it held the height quite well for some time it then descended slowly to the ground. I did have foam on the barometer and I had enabled NAV_TAKEOVER_BARO and IGNORE_THROTTLE. But this was only a quick test so I won’t read too much into it. Waiting for better weather to get some more flying in and try out the GPS.

brewski · Post by **brewski** » Fri Aug 01, 2014 9:16 pm

Hi DF,

Glad you finally have a reliable FC.
Re the slow downward drift in Pos Hold. If you observe the Alt reading in MW Config Or EZ-GUI after plugging in Lipo you will notice that reading will drift from initial zero to approx. + 1.5 m in 5 minutes with barometric pressure stable. I now allow 5 minutes warmup before flying which also ensures that GPS has max # of sats.

DorsetFlyer · Post by **DorsetFlyer** » Sat Aug 02, 2014 8:43 am

Thanks brewski. It's absolutely pouring with rain here after a (for us) hot dry spell. Looks as if I shall be grounded for a bit. DF

Georges41 · Post by **Georges41** » Sun Aug 03, 2014 9:42 pm

Hi ALL,

Please help me to solve this bug!
I mounted a CRIUS_AIO_PRO_V1 board and tested it with the MultiWii 2.3 classic software. The Quad is flying OK. I use a SPEKTRUM DX7 and an ORANGE RX.
With the same hardware I downloaded the MultiWii 2.3-navi-B7. Unfortunately in this last case the Quad did not see any signal from the ORANGE RX.

Yours, Georges

brewski · Post by **brewski** » Sun Aug 03, 2014 11:42 pm

Are you using individual outputs from RX or PPM Sum? If latter you need to define it in Special Receiver Types as shown below.

**************************************************************************************/
/******** special receiver types ********************/
/**************************************************************************************/

/**************************** PPM Sum Reciver ***********************************/
/* The following lines apply only for specific receiver with only one PPM sum signal, on digital PIN 2
Select the right line depending on your radio brand. Feel free to modify the order in your PPM order is different */
//#define SERIAL_SUM_PPM PITCH,YAW,THROTTLE,ROLL,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For Graupner/Spektrum
//#define SERIAL_SUM_PPM ROLL,PITCH,THROTTLE,YAW,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For Robe/Hitec/Futaba
//#define SERIAL_SUM_PPM ROLL,PITCH,YAW,THROTTLE,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For Multiplex
//#define SERIAL_SUM_PPM PITCH,ROLL,THROTTLE,YAW,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For some Hitec/Sanwa/Others

// Uncommenting following line allow to connect PPM_SUM receiver to standard THROTTLE PIN on MEGA boards (eg. A8 in CRIUS AIO)
//#define PPM_ON_THROTTLE

/********************** Spektrum Satellite Reciver *******************************/
/* The following lines apply only for Spektrum Satellite Receiver
Spektrum Satellites are 3V devices. DO NOT connect to 5V!
For MEGA boards, attach sat grey wire to RX1, pin 19. Sat black wire to ground. Sat orange wire to Mega board's 3.3V (or any other 3V to 3.3V source).
For PROMINI, attach sat grey to RX0. Attach sat black to ground. */
//#define SPEKTRUM 1024
//#define SPEKTRUM 2048
//#define RX_SERIAL_PORT 1 // Forced to 0 on Pro Mini and single serial boards; Set to your choice of 0, 1, or 2 on any Mega based board (defaults to 1 on Mega).
//**************************
// Defines that allow a "Bind" of a Spektrum or Compatible Remote Receiver (aka Satellite) via Configuration GUI.
// Bind mode will be same as declared above, if your TX is capable.
// Ground, Power, and Signal must come from three adjacent pins.
// By default, these are Ground=4, Power=5, Signal=6. These pins are in a row on most MultiWii shield boards. Pins can be overriden below.
// Normally use 3.3V regulator is needed on the power pin!! If your satellite hangs during bind (blinks, but won't complete bind with a solid light), go direct 5V on all pins.
//**************************
// For Pro Mini, the connector for the Satellite that resides on the FTDI can be unplugged and moved to these three adjacent pins.
//#define SPEK_BIND //Un-Comment for Spektrum Satellie Bind Support. Code is ~420 bytes smaller without it.
//#define SPEK_BIND_GROUND 4
//#define SPEK_BIND_POWER 5
//#define SPEK_BIND_DATA 6

/******************************* SBUS RECIVER ************************************/
/* The following line apply only for Futaba S-Bus Receiver on MEGA boards at RX1 only (Serial 1) or PROMICRO boards.
You have to invert the S-Bus-Serial Signal e.g. with a Hex-Inverter like IC SN74 LS 04 */
//#define SBUS
//#define RX_SERIAL_PORT 3
//#define SBUS_MID_OFFSET 988 //SBUS Mid-Point at 1500

/*************************************************************************************************/

Georges41 · Post by **Georges41** » Mon Aug 04, 2014 6:01 pm

Thanks fr the reply brewski. I use individual outputs from the RX. Mean time I tryed with a new config.h from a friend and the Quad starts to receive signals from the TX. Unfortunately, as long that I ARM the Quad it starts a Bep-Bep-Beep signal. This one continues even after the disarming the Quad.
By keeping the Quad fixed to the table, when I arm and start it, there is a quite large instability between the 2 and 4 motors.

Front
1 and 2
Back
4 and 3
Questions: Which is the cause of the Bep-Bep-Beep signal?
Is it normal to see this instability?
Yours,
Georges

brewski · Post by **brewski** » Tue Aug 05, 2014 9:00 am

Is the beeping coming from motors? If so this means either ESCs are receiving no signal or ESCs are way out of cal. Motor speeds will initially go to max & then decrease if quad is not flying. This is normal PID control. If speeds are jumping erratically on MW Config then vibration is cause, so balance props (and motors if possible) & set gyro/ACC filter to 42Hz.
Read the Beginners Guide and follow every step & you should get it sorted.
As this is not related to GPS Nav & OT if you require further assistance you should post in relevant part of forum.

FrankenberryPi · Post by **FrankenberryPi** » Fri Aug 08, 2014 3:47 pm

This software is an awesome addition to MultiWii. Thanks to everyone who's contributed. I was wondering what people's experience has been getting this to work with the Witespy PRO Ez3.0 Blacked MAG Editon boards using a remote compass.

I've got one along with a uBlox 6M gps/compass combo board from witespy. I have the GPS plugged into serial2 and the magnetometer plugged into the 3.3v I2C port. The magentometer doesn't seem to be working. I thought it was giving some values at one point, but since I ran through a calibration it just returns zero values in the sensor graph. The changes I've made in the config.h file are:

Code: Select all

#define FREEIMUv043  // uncommented
//#define GY_86  // commented out
#define SERIAL0_COM_SPEED 115200  //changed from 57600
#define SERIAL1_COM_SPEED 115200  //changed from 57600

I thought about fiddling with the I2C_Speed variable, but the working non-navigation version of 2.3 that I've got seems to work fine with 400kHz.

brewski · Post by **brewski** » Fri Aug 08, 2014 8:43 pm

It is recommended not to set GPS to 115200 baud as this introduces inaccuracy. Recommended speed is 38,400 & is what many modules are already set to.
You can change speed in UCentre.
Are you sure your FC outputs 3.3 on I2C port? Most ext Mags have onboard 3.3V regulator so require 5V & some have jumper to select either voltage. Check specs on module & measure voltage output on I2C port on your FC.
To get ext Mag to be recognised you need to change a setting in def.h of your sketch. The example below is for Crius AIOP V2. If you have this board you just cut tracks J2 & J3 on pads near Mag chip to disable it. You might have to cut SDA & SCL lines from Mag chip if they are not brought out on pads.
Modifiy the MW 2.3 Navi b7 def.h (not config.h).
Under #if defined Crius_aiop_pro_V2_v1 uncomment (//) out line-
#define MPU6050 _12C _AUX_MASTER //MAG
Save & then upload to your FC.

Connect the ext Mag board to the I2C port ensuring that you have connected as follows provided your Mag board has on board 3.3 regulator-
Gnd- Black
+5(VCC)- Red
SDA- Yellow
SCL - Green

mike105105 · Post by **mike105105** » Sat Aug 09, 2014 2:42 am

FrankenberryPi wrote:This software is an awesome addition to MultiWii. Thanks to everyone who's contributed. I was wondering what people's experience has been getting this to work with the Witespy PRO Ez3.0 Blacked MAG Editon boards using a remote compass.

I've got one along with a uBlox 6M gps/compass combo board from witespy. I have the GPS plugged into serial2 and the magnetometer plugged into the 3.3v I2C port. The magentometer doesn't seem to be working. I thought it was giving some values at one point, but since I ran through a calibration it just returns zero values in the sensor graph. The changes I've made in the config.h file are:
Code: Select all
#define FREEIMUv043  // uncommented
//#define GY_86  // commented out
#define SERIAL0_COM_SPEED 115200  //changed from 57600
#define SERIAL1_COM_SPEED 115200  //changed from 57600
I thought about fiddling with the I2C_Speed variable, but the working non-navigation version of 2.3 that I've got seems to work fine with 400kHz.

You need to comment out a line in def.h for the black w/external compass

#if defined(FREEIMUv043) || defined(MICROWII) <----Make sure you select the right section in def.h
#define MPU6050
#define HMC5883
#define MS561101BA
#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = -X; accADC[PITCH] = -Y; accADC[YAW] = Z;}
#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = Y; gyroADC[PITCH] = -X; gyroADC[YAW] = -Z;}
#define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = X; magADC[PITCH] = Y; magADC[YAW] = -Z;}
//#define MPU6050_I2C_AUX_MASTER // MAG connected to the AUX I2C bus of MPU6050 <------Comment out this line like this
#undef INTERNAL_I2C_PULLUPS
#endif

Most of the labels on this are correct so make sure everything matches.

Mike

FrankenberryPi · Post by **FrankenberryPi** » Sat Aug 09, 2014 6:03 am

Thanks Mike and brewski, you guys were right. I missed that I had to comment out the #define MPU6050_I2C_AUX_MASTER line in the def.h file. I did that and it's working now!

brewski, the uBlox board that I bought from Witespy came pre-programmed at 115200 baud. I was starting to wonder if that was too high, but it seems to be working so I'm going to leave it for now. If I have any more problems I'll probably bring it down and see what happens.

Thanks again, you guys are awesome!

EDIT:
The mag does turn out to need 5V, but it gets it from the serial connector that the GPS is plugged into. It's kinda handy having the GPS and external mag on the same board, but it does make things a little more confusing.

Plüschi · Post by **Plüschi** » Sat Aug 09, 2014 6:47 am

Be aware this board might have the same problem as its previous version, high drop 5V and 3.3V regulators. Measure if the cpu is getting its full 5V and the sensors are getting full 3.3V. Cpu at 4.1V and sensors at 3.0V is dangerous, there will be cpu brownouts, and sensors will have high noise.

brewski · Post by **brewski** » Sat Aug 09, 2014 7:12 am

FrankenberryPi wrote:Thanks Mike and brewski, you guys were right. I missed that I had to comment out the #define MPU6050_I2C_AUX_MASTER line in the def.h file. I did that and it's working now!

brewski, the uBlox board that I bought from Witespy came pre-programmed at 115200 baud. I was starting to wonder if that was too high, but it seems to be working so I'm going to leave it for now. If I have any more problems I'll probably bring it down and see what happens.

Thanks again, you guys are awesome!

EDIT:
The mag does turn out to need 5V, but it gets it from the serial connector that the GPS is plugged into. It's kinda handy having the GPS and external mag on the same board, but it does make things a little more confusing.

Great! I just checked my sketch & it was under GPS where I set 38,400. As you can see from sketch there is a 2% error at 115200 which will certainly affect your GPS accuracy. With Pos Hold my quad will hold within approx. 1.5m with 8 or> sats which I consider excellent.

/* GPS using a SERIAL port
if enabled, define here the Arduino Serial port number and the UART speed
note: only the RX PIN is used in case of NMEA mode, the GPS is not configured by multiwii
in NMEA mode the GPS must be configured to output GGA and RMC NMEA sentences (which is generally the default conf for most GPS devices)
at least 5Hz update rate. uncomment the first line to select the GPS serial port of the arduino */

#define GPS_SERIAL 2 // should be 2 for flyduino v2. It's the serial port number on arduino MEGA
//#define GPS_PROMINI_SERIAL // Will Autosense if GPS is connected when ardu boots.

// avoid using 115200 baud because with 16MHz arduino the 115200 baudrate have more than 2% speed error (57600 have 0.8% error)
#define GPS_BAUD 38400

Also under I2C sensors I uncommented out #define HMC5883. Not really sure if this was necessary but didn't hurt.

NNagib · Post by **NNagib** » Sat Aug 09, 2014 5:52 pm

Hi, I use this code on HK red board with mtk gps. It works, but I have a lot of problems to control the altitude. Eosbandi said that the copter doesn't respect waypoint's altitude, right? My copter goes very high (80+ meters) although specified altitudes are 10 meters. I use ezgui to set missions via bt and for logging. What can I do to control the altitude during the mission? Tnx

stronnag · Post by **stronnag** » Sat Aug 09, 2014 7:02 pm

In my experience, way point altitude is respected. mwptools, HK mega2560 for what's it worth.

DorsetFlyer · Post by **DorsetFlyer** » Sat Aug 09, 2014 7:57 pm

Hi NNagib, this sounds horribly like the trouble I was having with this board. I swapped it for a Hobby King Crius AIO look-alike using the same firmware and I don’t seem to have the same problem with that. I find it hard to believe that both your board and mine are faulty. I did notice that the z-accelerometer reads 256 on the red board but 512 on the Crius, so I wonder if the scaling is set incorrectly on the red board. As the altitude is controlled by the z-acceleration as well as the barometer, perhaps this is being sensed as only 0.5g so it appears to be falling when it is not.

NNagib · Post by **NNagib** » Sat Aug 09, 2014 9:20 pm

Barometer on this board is old gen, but it works. Strange thing is that the FC knows that altitude is wrong (I have a log file) and mission planner code ignores that. Yes, z-acceleration is 255, but I think that is normal for this board, isn't it?

NNagib · Post by **NNagib** » Sun Aug 10, 2014 9:21 am

Anybody with red board from HK? Do you have correct altitude in flight? Help, please

visper · Post by **visper** » Sun Aug 10, 2014 4:42 pm

I use Crius AIOP, I have no problem with the height of waypoints. GPS NAV works excellently.

Arakon · Post by **Arakon** » Sun Aug 10, 2014 7:30 pm

I noticed some issues with nav beta 7 and a crius aio pro 1.1, external mag, neo-6m GPS.
Even with 8 satellites, when using mission mode (drawing waypoints with multiwii ez gui) or RTH, the copter will often either overshoot badly (I almost always have to abort RTH because it would just fly past me otherwise) or go off at wrong angles.. i.e. if I draw a line to follow a path in the field (WP1-2), then fly 90° from that to the right (WP2-3), it will often fly off slightly in the wrong direction (i.e. at an angle along the path) and then lose direction even worse when heading to the second waypoint. Position Hold on the other hand seems to be quite accurate.
The mag is not getting disturbed (visible on the OSD) and is calibrated right, direction matches that of my cellphone (for verification) within 2-3°.
Any hints on how to improve accuracy?

stronnag · Post by **stronnag** » Sun Aug 10, 2014 7:55 pm

Arakon wrote:I noticed some issues with nav beta 7 and a crius aio pro 1.1, external mag, neo-6m GPS.
Even with 8 satellites, when using mission mode (drawing waypoints with multiwii ez gui) or RTH, the copter will often either overshoot badly (I almost always have to abort RTH because it would just fly past me otherwise) or go off at wrong angles.. i.e. if I draw a line to follow a path in the field (WP1-2), then fly 90° from that to the right (WP2-3), it will often fly off slightly in the wrong direction (i.e. at an angle along the path) and then lose direction even worse when heading to the second waypoint. Position Hold on the other hand seems to be quite accurate.
The mag is not getting disturbed (visible on the OSD) and is calibrated right, direction matches that of my cellphone (for verification) within 2-3°.
Any hints on how to improve accuracy?

My experience has been uniformly positive, at least within the accuracy one might expect from consumer GPS, e.g. http://www.multiwii.com/forum/viewtopic.php?f=8&t=3989&start=500#p51553 and http://www.multiwii.com/forum/viewtopic.php?f=8&t=3989&start=600#p53258; I certainly don't expect sub-metre accuracy. The FC is the HobbyKing AIOP 1.1 clone, and the firmware is the last since EOSBandi sadly went silent (so probably beta7). It seems to take a slightly "parabolic" start to each leg, but within expected GPS accuracy, and always corrects. I find RTH pretty good too, again within consumer GPS expectations. It may overshoot by one or two metres, but not much more.

If your experience is significantly worst than the two linked screen shots, a graphic log trace would help illustrate the problem.

NNagib · Post by **NNagib** » Sun Aug 10, 2014 8:24 pm

from the first page, @Eosbandi:

"The first and most widely used command is a waypoint command. This tells the copter to go to a specified location and altitude. The next step is executed once the copter reached the desired position. The copter will not wait for reaching the desired altitude, it will continue the mission once the waypoint is reached."

This is the problem, maybe. Can we force the copter to reach the desired altitude at all waypoints? By analyzing the log files, I can not find anything wrong. GPS data, baro, mag etc. seem to be correct.

Arakon · Post by **Arakon** » Sun Aug 10, 2014 8:40 pm

stronnag wrote:
Arakon wrote:I noticed some issues with nav beta 7 and a crius aio pro 1.1, external mag, neo-6m GPS.
Even with 8 satellites, when using mission mode (drawing waypoints with multiwii ez gui) or RTH, the copter will often either overshoot badly (I almost always have to abort RTH because it would just fly past me otherwise) or go off at wrong angles.. i.e. if I draw a line to follow a path in the field (WP1-2), then fly 90° from that to the right (WP2-3), it will often fly off slightly in the wrong direction (i.e. at an angle along the path) and then lose direction even worse when heading to the second waypoint. Position Hold on the other hand seems to be quite accurate.
The mag is not getting disturbed (visible on the OSD) and is calibrated right, direction matches that of my cellphone (for verification) within 2-3°.
Any hints on how to improve accuracy?

My experience has been uniformly positive, at least within the accuracy one might expect from consumer GPS, e.g. http://www.multiwii.com/forum/viewtopic.php?f=8&t=3989&start=500#p51553 and http://www.multiwii.com/forum/viewtopic.php?f=8&t=3989&start=600#p53258; I certainly don't expect sub-metre accuracy. The FC is the HobbyKing AIOP 1.1 clone, and the firmware is the last since EOSBandi sadly went silent (so probably beta7). It seems to take a slightly "parabolic" start to each leg, but within expected GPS accuracy, and always corrects. I find RTH pretty good too, again within consumer GPS expectations. It may overshoot by one or two metres, but not much more.

If your experience is significantly worst than the two linked screen shots, a graphic log trace would help illustrate the problem.

I have no way to get a log. I am fully aware of the limitations of the GPS, but I am talking 20-30 meters off the mark or worse.
Example: I had programmed a course that was 100 meters north, from there 50 meters east, 30 meters south, position hold infinite.
What it did:
100 meters slightly northwest, 30 meters sharply southeast, back north, wait 5 seconds, return to first waypoint, and then it looked like it tried to perform the same mission again.. i.e. it looped the mission despite the mission ending in an infinite pos hold.

-ralf- · Post by **-ralf-** » Sun Aug 10, 2014 9:32 pm

Arakon,

maybe your EEPROM is corrupt. Please clear EEPROM and try again.

brewski · Post by **brewski** » Mon Aug 11, 2014 2:47 am

Ensure that you set 4096 for EEProm Clear in Arduino for Atmega 2560 as it has 4K EEProm. What model UBlox 6m are you using & what baud rate is it set to?
I am running Crius AIOP V2 which should be functionally similar to your V1.1 & getting very accurate GPS performance. My Neo-6m is running at 38,400 & 5Hz which give the best accuracy .
Not sure if V1.1 has series reverse protection diode in incoming 5V line as does V2. If it does & you are feeding 5V either from ESC bec or ext UBec then 2560 will be running on 4.5V or less which is dangerously close to minimum figure running at 16Mhz. This can result in poor performance as well as random resets. You can either bridge diode with jumper wire or better still leave diode in circuit & use 5.5V UBec.

scrat · Post by **scrat** » Mon Aug 11, 2014 9:16 am

Where is EOSbandi?

NNagib · Post by **NNagib** » Mon Aug 11, 2014 9:40 am

Clearing ALL 4k of EEPROM helps, thanks!
I will test some missions, and I will post results.
How often do you clear the EEPROM? Do you upload the entire code (sketch) afterwards?

DorsetFlyer · Post by **DorsetFlyer** » Mon Aug 11, 2014 11:08 am

I’ve given up on the HK red board. I couldn’t solve the problem with the altitude control and now it won’t even connect to the GUI or Arduino program. Keeps telling me I’m using the wrong port although I am not. Resetting doesn't help. I’m sending it back in the hope of a refund.

brewski · Post by **brewski** » Mon Aug 11, 2014 12:53 pm

scrat wrote:Where is EOSbandi?

Maybe developing APM?

brewski · Post by **brewski** » Mon Aug 11, 2014 1:04 pm

DorsetFlyer wrote:I’ve given up on the HK red board. I couldn’t solve the problem with the altitude control and now it won’t even connect to the GUI or Arduino program. Keeps telling me I’m using the wrong port although I am not. Resetting doesn't help. I’m sending it back in the hope of a refund.

Hi DF,

A mate of mine bought same HK MW Pro board with MTK GPS & we spent several days trying to get it to connect & program it. We never succeeded to get it stable in any flight mode. I saw on RC Groups that there is a known (by HK) design issue with this board which is why it was being sold at discount price so they could clear stock.
He sent it back & got a full refund & bought a genuine Crius AIOP V2 as I have & no more problems + only $20 more.

brewski · Post by **brewski** » Mon Aug 11, 2014 1:09 pm

NNagib wrote:Clearing ALL 4k of EEPROM helps, thanks!
I will test some missions, and I will post results.
How often do you clear the EEPROM? Do you upload the entire code (sketch) afterwards?

I clear EEProm every time I upload just to ensure there is no corruption. Takes 10 seconds for peace of mind

Yes. You must upload your modified (or otherwise) sketch afterwards as EEPRom Clear wipes data that writes to this memory.

Arakon · Post by **Arakon** » Mon Aug 11, 2014 6:08 pm

-ralf- wrote:Arakon,

maybe your EEPROM is corrupt. Please clear EEPROM and try again.

Did that just now, will try once it stops storming here.

Edit: Is there any way to save the mag and acc calibration values to PC? ACC calibration is done quickly, but mag usually takes me 2-3 tries and isn't exactly easy with tall landing legs, gimbal and props in the way.

brewski · Post by **brewski** » Tue Aug 12, 2014 12:15 am

You can save your settings using WinGUI or EZ-GUI but to best of my knowledge there is no way to save calibration data for Mag or ACC.

ezio · Post by **ezio** » Tue Aug 12, 2014 12:36 am

Not possible

NNagib · Post by **NNagib** » Tue Aug 12, 2014 1:25 pm

@ezio, I use full version of ez-gui and log converter. These are wonderful apps, indeed. I have a question for you:
is there a simple way to load a .mission file in google earth? I create .kml file manually sometimes, but that's boring.
I would like to compare mission and logged flight path in google earth. Tnx

NNagib · Post by **NNagib** » Tue Aug 12, 2014 1:30 pm

I performed a short test flight, with 150m path, 5-9m altitude. Here is the result:

Max deviation from the mission path was about 3m. About the same deviation is logged for altitude values.
I think this is not bad. At least, it's much better then my previous attempts.

Hypermobile · Post by **Hypermobile** » Tue Aug 12, 2014 8:24 pm

@EZIO, i also use the GPS logging one and a While.

Finally found Free software to Overlay GPS data onto Video (Garmin Verb).
But if i use a Wingui File > and export it to *.GPX

I get an error ..."no timestamps available".
Is that something you can provide in the Logfile?

Would be nice: Garmin Verb is in some ways better then Dashware (not free)

ezio · Post by **ezio** » Tue Aug 12, 2014 8:39 pm

NNagib wrote:@ezio, I use full version of ez-gui and log converter. These are wonderful apps, indeed. I have a question for you:
is there a simple way to load a .mission file in google earth? I create .kml file manually sometimes, but that's boring.
I would like to compare mission and logged flight path in google earth. Tnx

I'm thinking about this for a while now. I will add it.

Plüschi · Post by **Plüschi** » Tue Aug 12, 2014 9:12 pm

DorsetFlyer wrote:I’ve given up on the HK red board. now it won’t even connect to the GUI or Arduino program

brewski wrote:HK MW Pro board with MTK GPS & we spent several days trying to get it to connect & program it.

You DID short the "program enable" jumper did you? I bet you did not. RTFM

Imho this board has some problems, but refuse to program aint one of them.

stronnag · Post by **stronnag** » Tue Aug 12, 2014 10:47 pm

ezio wrote:
NNagib wrote:@ezio, I use full version of ez-gui and log converter. These are wonderful apps, indeed. I have a question for you:
is there a simple way to load a .mission file in google earth? I create .kml file manually sometimes, but that's boring.
I would like to compare mission and logged flight path in google earth. Tnx

I'm thinking about this for a while now. I will add it.

mwptools has a ruby script to do this (and mission => gpx).

brewski · Post by **brewski** » Tue Aug 12, 2014 11:39 pm

Plüschi wrote:
DorsetFlyer wrote:I’ve given up on the HK red board. now it won’t even connect to the GUI or Arduino program

brewski wrote:HK MW Pro board with MTK GPS & we spent several days trying to get it to connect & program it.

You DID short the "program enable" jumper did you? I bet you did not. RTFM

Imho this board has some problems, but refuse to program aint one of them.

Missed that one. Didn't realise there was a programming jumper & his board came with no docs & the stuff under Files on HK not very helpful. Board came loaded with V2.2 & even with MWGUI 2.2 it was all over the place with sensor readings.
My friend now has Crius AIOP V2 & all is good.

ezio · Post by **ezio** » Wed Aug 13, 2014 3:05 am

stronnag wrote:
ezio wrote:
NNagib wrote:@ezio, I use full version of ez-gui and log converter. These are wonderful apps, indeed. I have a question for you:
is there a simple way to load a .mission file in google earth? I create .kml file manually sometimes, but that's boring.
I would like to compare mission and logged flight path in google earth. Tnx

I'm thinking about this for a while now. I will add it.

mwptools has a ruby script to do this (and mission => gpx).

I have added it too to the logs converter

DorsetFlyer · Post by **DorsetFlyer** » Wed Aug 13, 2014 8:43 am

Thanks Pluschi. I had not noticed this jumper and I did not short it, but I had been able to program the board without difficulty until recently. It seemed to fly well except for an issue with the altitude control. Then for no obvious reason it just would not connect to my PC. It’s on the way back to Hobby King now so it will be interesting to see what they have to say.

NNagib · Post by **NNagib** » Wed Aug 13, 2014 11:20 am

@stronnag, I use suse linux 12.3 64-bit and I could not compile mwptools, the error message is:
mwp.vala:292.48-292.71: error: The name `is_iconified' does not exist in the context of `Gdl.DockItem'
if(dockitem[4].is_closed() && !dockitem[4].is_iconified())
Compilation failed: 15 error(s), 0 warning(s)
make: *** [mwpu] Error 1
---------
Ruby script doesn't work either. It looks like it can't parse input xml file. Problem is probably with nokogiri, it says:
WARNING: Nokogiri was built against LibXML version 2.8.0, but has dynamically loaded 2.9.0

I didn't have much time to investigate further, but thank you, anyway.