Total energy calculation

[Jean-Luc Derouineau]

Hello,
I am new to this forum and I have been impressed by the amount of knowledge available.

I fly both RC and real glider and I am always looking for the best possible information concerning vertical speed and total energy in particular.

I looked into the forum (maybe not enough) but couldn't find information on total energy calculation derived from GPS/IMU for RC or even for real gliders.
Is this something some members have already looked at? If so, could you point me in the right direction?

Thanks for your comments.

JL

[Peter Hollands]

Hi Jean Luc and Welcome !

I can point you at the code that does the calculation of energy as speed. Others, that wrote the speed energy code, can comment further.

If SPEED_CONTROL is 1 in the options.h file, then the code calculates excess speed as effectively the height that the energy can be converted into. This variable is called "speed_height". This excess height is then used in both of the  height error calculations both to govern throttle and the pitch of the plane.

I personally do not use SPEED_CONTROL in my flights, so I cannot vouch for how well it works in practice. But I am sure others do use it. For  example, Kees must have used  this in his autonomous glider flights in the Netherlands.

Best wishes, Pete

--
--
---
You received this message because you are subscribed to the Google Groups "uavdevboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavdevboard...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/9809b5d0-7731-4c8f-a6d2-b01982571209n%40googlegroups.com.

[william premerlani]

Hi Jean Luc,

Attached is one of the founding papers on this subject. It calls the control energy control, but it is really a power control, since it works with the rate of change of energy.

The version of the control used in MatrixPilot is based on energy. The behavior of the two approaches is similar, but there are some subtle differences. Each approach has some advantages and disadvantages.

Best regards,

Bill

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/CAM%2BK-kMBf1SaofM%2BTXQdHLfKxpiiECxzT11-wNH57vvR8YbS4A%40mail.gmail.com.

[Jean-Luc Derouineau]

Thanks Bill for this interesting paper.
Control laws, similar to what is discussed in this paper, have been introduced in air transport FMS, especially with recent 4D trajectory, requiring thigh energy management.

Concerning use for gliders, the sensing part is what is of main interest.
I believe I have been reading, you once used a UDB to compare your wind estimation technique, to what was computed on a glider computer.

I was wondering if you also looked at vertical (earth frame) wind component to compare to the vario information in the glider.
Traditional total energy compensation probes are sensitive to wind variation on all axis (mainly x and z). Because it is almost impossible to use horizontal wind variation to gain energy, it is a nuisance.

If we could provide vertical wind and eliminate useless x and y components, this could be a real improvement to both RC and real glider pilots.

I am wondering if your wind estimation is precise enough (or could be made) to be used as a vertical speed variometer.
I am interested in purchasing a UDB to make some experiments if you believe it is a valid avenue.
Regards,

JL

[william premerlani]

Hi Jean-Luc,

As it stands, MatrixPilot generally provides an accurate estimate of lateral and vertical ground speeds. That is not hard to do because the source of that information is mainly GPS, accelerometers and gyros. It also provides estimates of airspeed and lateral and vertical wind speed. The accuracy of those calculations depend on whether the option to use an angle of attack model is employed.

Attached are plots of air speed and lateral and vertical components of ground and wind speed estimates from an actual flight. Data was taken on a fairly windy day. The angle of attack model was not used. Speeds are in meters per second. The X axis of the plots are sample number, there are 4 samples per second. The flight duration was about 8 minutes. There is also a plot of pitch in degrees and height in meters. Note that wind speed varies with location and time. Wind was generally greater at higher altitude. At some locations at lower altitude the wind was blocked by trees.

Also attached is the theory behind the angle of attack model. It has been implemented in MatrixPilot. The parameters for the model can be extracted from flight data in which a few specific maneuvers are performed.

The UDB can be purchased here.

If you want to make some experiments I will help you.

Best regards,

Bill

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/1ff0b5fe-f3f1-46c5-92aa-100ed86b8b87n%40googlegroups.com.

[william premerlani]

Hi Jean-Luc,

I have more comments to add to my last email.

Ignore the data after sample number 1587, the plane landed at that point.

After that the ground speed was zero and the airspeed was 5 meters per second. That value for airspeed is correct, it represents the difference between wind speed and ground speed estimates.

Best regards,

Bill

[Jean-Luc Derouineau]

Looking at ordering UDB and GPS, it seems UDB6mini  and uBlox M8  should provide best results.
Is this better or should I stick with UDB5 and EM-506?

[ben levitt]

Hi Jean-Luc,

I get best results from the uBlox M8.  But Bill gets great results from the EM506 in his area.  In my area, the EM506 works very well, but the uBlox M8 gives more accurate altitude readings.

The UDB5mini and UDB6mini give me very similar performance.  The 6 has slightly less gyro drift, which I only notice on the yaw axis since the other 2 are constantly corrected by gravity anyway.  That said, I've been able to get basically zero yaw drift after calibrating the UDB6mini, which is fun for autonomous takeoffs.

Also, I should disclose that I run the octopilot store, and sell the boards there.

Ben

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/1bdd7e54-3d1c-4e74-8135-1b59d009d1aen%40googlegroups.com.

[william premerlani]

Hi Ben,

How do you connect your ublox 8 to a UDBmini?

I find it convenient to plug an EM506 directly into a board with readily available cables.

With the ublox 8, I have to kludge up a connection.

Here is the ublox 8 that I use:

https://store.mrobotics.io/ProductDetails.asp?ProductCode=mro-gps003-mr

Here are the connectors that I use:

https://store.mrobotics.io/6-Pins-JST-GH-to-6-Separate-2-54mm-Females-p/mrc0202.htm?1=1&CartID=0

I end up with a veritable spider's web between ublox and the GPS pins.

Could you suggest a ublox and cable that would connect straight to the board?

Perhaps you could offer the cable at your store for a recommended 3rd party ublox?

Best regards,

Bill

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/CAHyr3YivhDAmnSDf_m7XgfTVnQhWykFj8Gnjp%3Db7mc%2Bt_PSS-Q%40mail.gmail.com.

[william premerlani]

Ben,

By the way, the ublox that you recommend on your octopilot website is no longer available. mrobotics is recommending this one in its place:

https://store.mrobotics.io/ProductDetails.asp?ProductCode=MRO10038

I note that most of the GPS units on the mrobotics website have the same connector. If you could find a way for customers to buy a cable ready made to connect the mrobotics GPS directly to UDBmini, I for one would buy a bunch of them and be eternally grateful.

Best regards,

Bill

On Mon, Oct 12, 2020 at 1:59 PM ben levitt <ben...@gmail.com> wrote:

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/CAHyr3YivhDAmnSDf_m7XgfTVnQhWykFj8Gnjp%3Db7mc%2Bt_PSS-Q%40mail.gmail.com.

[ben levitt]

Hi Bill,

I use this cable from mrobotics:

https://store.mrobotics.io/mRo-6-Pins-JST-GH-to-6-Pins-JST-SH-p/mrc0243.htm

and then use an exacto knife to pop out the terminated wires on one end to shuffle them around to match the pinouts.

Ben

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/CANxo1ZKTkMonu3LVcACgnuMh015x-z90gPjMeQ5%2Bm1_751kMDg%40mail.gmail.com.

[Jean-Luc Derouineau]

I started to look at the MatrixPilot on Github.
Lot of info to read...

The board has a lot of interfaces that I will not need and the software has also lots of features I will not use since I really want to focus on using the wind estimation.

I can probably get the data I need from SERIAL_UDB_EXTRA.

I looked at the wiki (https://github.com/MatrixPilot/MatrixPilot/wiki) but I am afraid a lot of links are broken (referring to gentlenav).

Is there a tuto or equivalent that could help get started? (I did forget to mention I am a noob, especially with Microchip's MPLA).

Regards,

JL

[william premerlani]

Jean-Luc,

You right, there are a lot of links broken and a lot of material you do not need.

I am willing to either guide you through and/or update the wiki.

However, if you could tell me a little bit more about what you want to do, it would limit the scope of what I need to do.

For starters, are you planning to control a model RC plane or are you going to bring the UDB along for a ride in a real glider as a variometer and/or vertical wind estimator?

Best regards,

Bill

[Jean-Luc Derouineau]

Bill,

The first goal would be to test on a real glider since it would be easier to install and perform tests/recordings.

When it works, it could be used on RC gliders as well.

The goal is to provide both real time horizontal (x/y terrestrial plane) and vertical (z terrestrial axis) wind indications. Vertical wind information is what Total Energy variometers try to measure.
Horizontal wind allows to optimize flight performance during transitions as well as anticipate for thermodynamic/wave conditions. Vertical wind could replace traditional TE vario during climb, without the secondary effect of TE probe due to horizontal wind gradient as well as load factor.

The first step would be to determine if UDB can compute wind with enough accuracy and precision to avoid use of air data sensors.

When this works, a second step would to propose an optimized flying pattern to the pilot to maximize climb performance.
This could be seen as a climb flight director which could be used by a pilot (real or RC) as well as an input to AP for RC.

I can install such a prototype on a 2 seater which is equipped with what is considered a good vario/computer (LX9050) that would be used as a reference.

A 2 seater has the advantage to let one person flying while the other focuses on the tests.

The goal would be to visualize UDB info in real time (to fly and compare to LX) as well as record the data to perform off line analysis. A small display attached to UDB or a BT connection on the datalink, connected to a smartphone, could be used for real time display.

JL

[william premerlani]

Hi Jean-Luc,

Thanks for your operational description, it helps a great deal.

Most of what we would need to do is straightforward and has been done before. Early in the development of MatrixPilot a friend of mine took me up in a two seat glider and the data we collected looked good.

There are two details I would like to think about a bit more:

1. GPS reception. What material is the glider made of? In particular I am thinking about GPS signal strength inside the glider. Fiberglass would be best. I am not sure about aluminum. In any case we would want to do some GPS ground testing from inside the glider. The test is simple enough: run UDB and GPS together and gather data. We know that the truth should be no motion, but GPS will declare otherwise. We will want to look at the reported location, velocity, HDOP and reported number of satellites in view.

2. A real time display. There are a few options, I would like to find one that does not require a lot of work.

The simplest and easiest to implement would be to connect servos to the UDB. I have done this sort of thing before, it is a way to get a visual indication. There are 8 pwm channels, so we could display up to 8 signals which we could select in software. The work on my end is trivial. On your end you would have to put some sort of indicators on servos and mount them.

You mentioned two other display options that I would want to get more detail on, they might require some work. One of them was a small display attached to UDB. Do you have any displays in mind? We have to consider the interface to UDBmini. It has I2C and SPI ports. We have written I2C and SPI drivers before for various peripherals. It is not hard to do, but it is not trivial. For this option, if you would point me to some displays that you like that have I2C or SPI interfaces, I would be willing to take a look.

You also mentioned a BT tap on the datalink. I assume that you are referring to the flight data that UDB sends to a data logger via a serial port. The part of it that I would not be much help with is getting the serial data to the BT. If we go that route I could tell you the format of the data stream and leave the rest up to you. Most likely you would have to build a board that would monitor the serial link and transfer selected data items to BT.

Best regards,

Bill

--
--
---
You received this message because you are subscribed to the Google Groups "uavdevboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavdevboard...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/bac18ed4-0be0-45fc-a2ae-793770c248ban%40googlegroups.com.

[ben levitt]

For viewing live data, at least while testing, one very easy option could be a small laptop or tablet running QGroundControl or a similar program, receiving mavlink data from the UDB, either over a UART-serial cable, or over bluetooth using something like this: https://www.instructables.com/Tutorial-Using-HC06-Bluetooth-to-Serial-Wireless-U-1/

Ben

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/CANxo1ZJgwM7mZEXBCSYN00H%3DK7CCo7R3itbtqoe%3D3sHwbdERqA%40mail.gmail.com.

[william premerlani]

Hi Ben,

Thanks a lot for the suggestion for data display. Good idea. You are much better at displays than I am. I recall the work that you did with on-screen display.

How about a heads up display on some sort of goggles? How hard would that be?

If you are willing to help out and take the data display part of it off my hands, I should be able to handle the rest of it without any trouble.

Best regards,

Bill 

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/CAHyr3YhOHkMWdPWks1bdA%3DYZjfubC4%3DGNHY%3DMogTbSseOmUy5g%40mail.gmail.com.

[Jean-Luc Derouineau]

1: GPS reception

Modern gliders are in carbon fiber.
If location of GPS is not critical (i.e. does not have to be close to CG) we can locate the GPS in the cockpit above the instrument panel which is usually where GPS antennas, for navigation and anti collision systems, are located.

If location is critical, then it would be necessary to create a fiberglass patch in the fuselage with GPS underneath. On certified gliders, this is not easy since it would have to be documented, to maintain airworthiness. An alternate solution could be to use flexible antenna like this one: https://www.molex.com/molex/search/deepSearch?pQuery=productseries%253A%2522206560%2522

If cockpit is OK, it might be easier to use a GPS with a long cable so that it can be installed away  from UDB.

2: Display

In all cases, it is necessary to record data from UDB and onboard variometer, in the same time frame, to be able to analyze data off line.
To indicate vertical wind from UDB, the idea of using a servo to drive a needle is interesting. It would look similar to old pneumatic variometer. Still wind information would require some sort of display.

If UDB is used just as a sensor board, then it should broadcast serial data to a display unit, either using existing data link or better a specific NMEA sentence like $LXWPW or $LK8EX1 since this could be used directly by applications like LK8000 or XCSoar. These applications are glider nav/flight computers which run on smartphones. They can use data from external sensors. A simple BT device like the HC05 or HC06 could be wired to the serial TX/RX pins of UDB and the smartphone would connect to UDB using BT.

Even better, WIFI could be used instead of BT, this would even allow to have multiple smartphones connected to the UDB to read the data link. One smartphone to display vario, wind, etc. and the other smartphone to record the data link. I am already working on an ESP32 board using Arduino to create a WIFI AP interface for smartphones. This allows to get serial data stream from anti collision equipment's  (i.e. FLARM) or radios. This could easily be connected to UDB serial port.

If UDB is used as a stand alone solution, then a small OLED or TFT display would have to be connected using I2C or SPI.

Because data stream is required in any case, starting with UDB as a stand alone sensor, streaming data is probably the way to go.
Adding to UDB a data link option that would broadcast NMEA sentences would be the ideal solution since existing application exist to display data in a relevant form.

I should be able to help, at least providing NMEA info and possibly contributing to the coding effort.

Other questions/comments:

- would UDB require changes to "optimize" wind estimation?
- It might be important to add low pass filters to horizontal wind as well as vertical wind info to be displayed. Probably 10s or more on horizontal wind and 0.5s to 2s to vertical wind (should be parameters)

[Jean-Luc Derouineau]

I was working on my message while you send yours.

Because the goal would be to eventually fly the glider using UDB sensor, I am not sure a laptop or tablet is the best way to go, even for testing. Cockpits are not that roomy for laptops and it would be important to make sure the indication to the pilot is straightforward and easy to interpret in real time.

When we demonstrate the usefulness of UDB to optimize glider climbing (e.g. maximizing total energy), then we can think about the best solution that could be "easily" duplicated by people interested in the design.

[william premerlani]

Jean-Luc,

Regarding display and data logging, I am hoping to hear from Ben Levitt. Ben is one of the co-founders of matrixpilot and is showing interest in this project. He is very talented and creative with displays. I think both you and he have some good ideas about display options, together I think the two of you will come up with a good approach. The only thing I will say about display and data logging is that in addition to whatever you and Ben can figure out, I suggest that we include two servo indicators in any case, it would be very easy to do. One will indicate the vertical speed of the aircraft, the other will indicate the vertical speed of the wind.

Regarding location of GPS and UDB:

UDB does not need to be at CG for wind estimation. I think that mounting UDB and GPS together in the cockpit will be fine, but it will be prudent to do some ground testing to compare GPS performance inside the cockpit with performance outside of the aircraft. The available cables to connect the GPS to the UDB are not very long, typically 15 cm. So GPS and UDB should be close together. The cable from UDB to display could be longer.

Regarding performance of the wind estimation algorithm and filtering:

Performance of lateral wind estimation is reasonably good without any changes or optimization. The way it works already has a low pass filter, we can set the time constant to whatever you want with only minor changes to the code.

Performance of vertical wind estimation can be improved by populating the parameters of an angle of attack model that is available as an option in matrixpilot. The parameters for the model can be extracted from flight data by running a flight analyzer tool developed by Peter Hollands that comes with matrixpilot. This procedure does not require any changes to the code, it simply requires a test flight in which the pilot deliberately varies airspeed. Vertical wind estimation also has a low pass filter, we can set the time constant.

Best regards,

Bill

On Tue, Oct 13, 2020 at 6:45 PM Jean-Luc Derouineau <jlde...@gmail.com> wrote:

1: GPS reception

Modern gliders are in carbon fiber.
If location of GPS is not critical (i.e. does not have to be close to CG) we can locate the GPS in the cockpit above the instrument panel which is usually where GPS antennas, for navigation and anti collision systems, are located.

If location is critical, then it would be necessary to create a fiberglass patch in the fuselage with GPS underneath. On certified gliders, this is not easy since it would have to be documented, to maintain airworthiness. An alternate solution could be to use flexible antenna like this one: https://www.molex.com/molex/search/deepSearch?pQuery=productseries%253A%2522206560%2522

If cockpit is OK, it might be easier to use a GPS with a long cable so that it can be installed away  from UDB.

2: Display

In all cases, it is necessary to record data from UDB and onboard variometer, in the same time frame, to be able to analyze data off line.
To indicate vertical wind from UDB, the idea of using a servo to drive a needle is interesting. It would look similar to old pneumatic variometer. Still wind information would require some sort of display.

If UDB is used just as a sensor board, then it should broadcast serial data to a display unit, either using existing data link or better a specific NMEA sentence like $LXWPW or $LK8EX1 since this could be used directly by applications like LK8000 or XCSoar. These applications are glider nav/flight computers which run on smartphones. They can use data from external sensors. A simple BT device like the HC05 or HC06 could be wired to the serial TX/RX pins of UDB and the smartphone would connect to UDB using BT.

Even better, WIFI could be used instead of BT, this would even allow to have multiple smartphones connected to the UDB to read the data link. One smartphone to display vario, wind, etc. and the other smartphone to record the data link. I am already working on an ESP32 board using Arduino to create a WIFI AP interface for smartphones. This allows to get serial data stream from anti collision equipment's  (i.e. FLARM) or radios. This could easily be connected to UDB serial port.

If UDB is used as a stand alone solution, then a small OLED or TFT display would have to be connected using I2C or SPI.

Because data stream is required in any case, starting with UDB as a stand alone sensor, streaming data is probably the way to go.
Adding to UDB a data link option that would broadcast NMEA sentences would be the ideal solution since existing application exist to display data in a relevant form.

I should be able to help, at least providing NMEA info and possibly contributing to the coding effort.

Other questions/comments:

- would UDB require changes to "optimize" wind estimation?
- It might be important to add low pass filters to horizontal wind as well as vertical wind info to be displayed. Probably 10s or more on horizontal wind and 0.5s to 2s to vertical wind (should be parameters)

ssion on the web, visit https://groups.google.com/d/msgid/uavdevboard/2797b1e4-47f8-4496-ba12-2cff26b38f2fn%40googlegroups.com.

[william premerlani]

Jean-Luc,

Here are my suggestions for proceeding:

1. Ben, you and I will settle on a design and on development steps. This email is a first draft of development steps.

2. Once we have a tentative design, Ben and I will acquire whatever additional hardware is needed and make a first pass at systems integration and ground testing.

3. We may wind up revising the design based on our observations.

4. We will give you a bill-of-material and suggested vendors and instructions on assembly and programming.

5. Once you have all the parts, you will put them together and figure out how you are going to mount them in the cockpit.

6. There is a process for measuring and programming the accelerometer offsets. I will guide you through it.

7. Do some initial ground testing. This does not need to be done in the cockpit.

8. Do a GPS ground test in the cockpit.

9. Do a first flight test. There are two goals: Make sure everything is working and gather flight data to populate the angle of attack model.

10. Revise the firmware with the angle of attack model.

11. Performance flight testing.

"Rinse and repeat".

Best regards,

Bill

On Mon, Oct 12, 2020 at 5:51 PM Jean-Luc Derouineau <jlde...@gmail.com> wrote:

I started to look at the MatrixPilot on Github.
Lot of info to read...

The board has a lot of interfaces that I will not need and the software has also lots of features I will not use since I really want to focus on using the wind estimation.

I can probably get the data I need from SERIAL_UDB_EXTRA.

I looked at the wiki (https://github.com/MatrixPilot/MatrixPilot/wiki) but I am afraid a lot of links are broken (referring to gentlenav).

Is there a tuto or equivalent that could help get started? (I did forget to mention I am a noob, especially with Microchip's MPLA).

Regards,

JL

he web, visit https://groups.google.com/d/msgid/uavdevboard/1b469ab3-3266-4b95-b3df-3a0717e995bfn%40googlegroups.com.

[Jean-Luc Derouineau]

Plans looks good to me.

I will try to feed discussion on prototype solution with a proposal.

FYI, I will use a Taurus, which is a self launch glider to perform the test.

JL

--

--
---
You received this message because you are subscribed to the Google Groups "uavdevboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavdevboard...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/CANxo1Z%2BWEB793e%3Dx-qxu%3DfZFVuLLumW5zMS3RPvXZJ-U0bFKCg%40mail.gmail.com.

[Jean-Luc Derouineau]

Bill and Ben,

Is there a simple way to exchange documents, like schematics, etc?

By the way, were are you located?
I am in France, in the Pyrenees.

JL

[Jean-Luc Derouineau]

Questions:

- By curiosity, have you ever considered using dual antenna GPS to get very accurate heading?

- Can you elaborate on the testing you would like to perform on GPS? As soon as we agree on GPS model to use, I can perform testing.

- Winter is probably a good time for calibration and some of the testing due to more stable air. For thermals (vertical wind), except for a few rare winter days, we will have to wait for spring (i.e. march/april)

JL

[william premerlani]

Jean Luc,

I have never considered using dual antenna GPS for airplanes in my hobby activities. WIth airplanes it is possible to get a heading that is accurate enough for most purposes without a pitot tube, magnetometer or dual GPS. I have used dual GPS for very accurate heading in my "day job".

Regarding the testing I would like to perform on GPS, I want to get an estimate of how good the signal is inside the cockpit.

So, what I am looking for is a static (not moving) ground test, inside and outside of the cockpit. Inside the cockpit the GPS should be located where we intend to mount it.

The information we need to do the comparison is already included in the flight data that is logged. In particular we will be looking at

latitude, longitude, altitude, number of satellites in view and horizontal dilution of precision.

For a static test, latitude, longitude and altitude reported by GPS should be constant, but they never are. Their standard deviation is a measure of the error.

The number of satellites in view and horizontal dilution of precision gives us some idea about the strength of the signal at the GPS location.

A large number of satellites and a small value for horizontal dilution of precision indicates a strong signal.

Ideally we will get the same values inside and outside of the cockpit. If so, that is great.

If the values are disappointing, we might want to do further testing at various locations in the cockpit.

Best regards,

Bill

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/591c4ee2-7bba-4483-83c5-07b07e5c6147n%40googlegroups.com.

[Jean-Luc Derouineau]

I was looking at GPS.

Seems Ublox is coming with a new chip which is going to end life of the M8.

Still, to perform performance tests, I can buy a unit that I can find in France:

https://store-drotek.com/876-DP0105.html

I suppose it can be connected to UDB.

Is this a good enough unit?

JL

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/CANxo1Z%2BT_RMYWCQOBprctwCWbqUU3FmEnj9x8B4RXjWGWYz4cw%40mail.gmail.com.

[ben levitt]

It should be ok, but you'll have to figure out the wiring situation.  the jst-gh is not the same as the plug on the UDB boards.

Ben

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/CAGsm8_gM7Uxss9-o%2Bxq0xLCVvvZOHEFgM-vZpbg-Vsq_uUR1Kg%40mail.gmail.com.

[william premerlani]

Jean-Luc,

If you use the GPS you suggested, you are going to have to cut off the connector that is there and figure out a way to connect things together. Offhand I do not see an easy way to do that. Here are some options:

1. Perform a splice between the wires of the GPS cable, and a 6 wire cable with a JST-SH connector.

2. Put a JST-SH connector on the end of the cable.

3. Put separate single pin connectors on each wire and connect to the separate pins on the UDB.

In any case, you are going to have to identify the signals in the cable. I was not able to find any documentation that spells that out. Before you go ahead and buy that GPS it would be best if you could get the documentation. There are 6 wires in the cable, they are probably power, ground, GPS_TX, GPS_RX and two wires that we will not need. You also need to check on the specs for power requirements.

Here is the GPS that I am using:

https://store.mrobotics.io/ProductDetails.asp?ProductCode=mro-gps003-mr

Ben is using a similar one from the same vendor.

There are two cables that can be used to connect to the UDB.

Here is the cable that I am using, it will connect the GPS to the separate pins on the UDB:

https://store.mrobotics.io/6-Pins-JST-GH-to-6-Separate-2-54mm-Females-p/mrc0202.htm?1=1&CartID=0

Here is the cable that Ben uses, it has a JST-SH connector that will connect directly to the UDB, but you will have to do a little bit of "surgery" to swap a few wires.

https://store.mrobotics.io/mRo-6-Pins-JST-GH-to-6-Pins-JST-SH-p/mrc0243.htm?1=1&CartID=0

Best regards,

Bill

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/CAGsm8_gM7Uxss9-o%2Bxq0xLCVvvZOHEFgM-vZpbg-Vsq_uUR1Kg%40mail.gmail.com.

[Jean-Luc Derouineau]

Bill and Ben,

I would rather order a Ublox M8N from a shop in France or EU, mainly because of shipping and return in case of problem.

I looked at the UBD schematic and serial data as well as PPS are connected to GPS. GPS RX TX  are available on both U9 GPS connector and independent pins but PPS is only available on U9.

If you connect the GPS to the separate pins, does it means serial GPS data is used but PPS is not used?

Can you confirm a Ublox M8n board which provides RX and TX is enough or, is PPS  important to get most accurate wind?

In any case, I can splice wires and connect to either pins or U9.

JL

[Jean-Luc Derouineau]

Additional question.
Most boards come with a mag sensor.

How is mag sensor interfaced to UDB? I2C?

JL

[william premerlani]

JL,

The mag sensor is an option that is really not needed with fixed wing aircraft, I do not recommend it. MatrixPilot will perform just fine without it, it is more trouble than it is worth.

Most mag sensors can be interfaced to UDB via I2C, but there are some hurdles to get over.

The two highest hurdles are related to the fact that there are many different mag sensors available, each with its own set of messages, registers, state diagram and coordinate system.

So, for any particular mag sensor you would need to get the documentation for that sensor and write a driver for it.

I suggest we start out without a mag sensor and see what happens.

Best regards,

Bill

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/356fbf1f-26ad-47b7-9180-749b6c95cb79n%40googlegroups.com.

[guy.franc...@gmail.com]

Salut Jean-Luc,

Don't worry about the GPS PPS pin, as Bill told you, we do not use it.

Bienvenue au club;)

gfm

[Jean-Luc Derouineau]

Thanks for the info et bonjour Guy.

So the only thing we need is a good GPS receiver (e.g. U-blox M8N) and wire the serial data, which can be done directly to the GPS RX and TX pins on the UDB board, without going through the 6 pins U9 connector.

Guy, are you located in France?
If yes do you have a good source for GPS in France or EU?

[guy.franc...@gmail.com]

Bonsoir Jean-Luc,

Yes, I am living in France, at Saint-Malo.

I learned and practiced the paragliding some years ago in the Pyrennées. What a beautifull country!

I started with two GPS puchased at Sparkfun. But these two did not have the performance I expected.

My project aims to guide a multicopter with a precision better than 0.1m.

For the vertical axis, I use a Lidar proximeter and this accuracy is achieved.

I am working now on the horizontal plane with a very expensive GPS solution, that I puchased in ArduSimple (from Barcelone), based on the ZED-F9P component, integrated on a Arduino like board for the Base and a small board, similar to the UDB5 mini, for the copter. I have great hope with them.

I believe that for your project the U-Blox M8N is convenient.

I suggest you connect it with a cable on U9, it is best and proper way to avoid too much wires.

When you will have chosen your GPS board, tell us the datasheet and we will find how to connect it to the UDB.

Best wishes,

gfm

[Jean-Luc Derouineau]

Thanks for the info Guy.
I am not concerned about connecting the GPS to the UDB.

I am more concerned about having the best GPS to get best results on wind calculation.

To be useful, the accuracy/precision needs to be 10cm/s or better for vertical wind. Horizontal wind can be an order of magnitude higher.

From what I could read, M8 should be OK and I am not sure M9 would add performance.
So unless you guys believe I should go to M9, I will order an M8 to get going with initial tests.

I will wait for you inputs.

Regards,

JL

[Jean-Luc Derouineau]

The main difference I could appreciate between M8 and M9 is the update rate, which is 5 Hz (GPS+Glonass) or 10 Hz (single constellation) for M8 while M9 is at 25 Hz.

[guy.franc...@gmail.com]

Bonsoir Jean-Luc,

The cost of both solutions are quite the same.

The main thing is to be able to receive as much satellites as possible, whatever the constellation.

A high data rate like 25 Hz could allow fast response. I think that one Hz (after data filtering to get vertical speed) is a minimum for a vario.

You could be interested by this board :

https://www.gnss.store/gnss-gps-modules/116-ublox-neo-m8n-gps-gnss-receiver-board-with-sma-for-uav-robots.html

• The USB connector is usefull to set the best configuration into the chip, so you have not to modify it through the UDB. 
• The USB is also usefull to test the GPS alone with U-Center on a deskstop PC or a portable Tablette (on board the glider?).
• The RX/TX are available on two pads, easy to connect to the UDB.
• A battery allows hot power, meaning quick fix, even indoor, during the development phase.
• The sma connector allows to connect an outboard antenna (placed where you want on the glider) and to choose what kind of antenna you need.

Kind regards,

gfm

[william premerlani]

Jean-Luc,

Guy's suggestion is a good one. If you buy this one, remember to select an antenna. I like the idea of the separate antenna, that is the configuration that I used when I started out this project using an RC truck.

Regarding update rate, 4 Hz is adequate for the MatrixPilot computations. The accelerometers and gyros are the primary sources for position estimation, the GPS information is used for drift compensation. There is very little drift in 1/4 of a second.

Best regards,

Bill

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/38508b7e-921d-433a-a5d0-6b2347e5cc67n%40googlegroups.com.

[Jean-Luc Derouineau]

Guy,

Thanks for the information. This allowed me to look further into M9 boards and found something similar (board and antenna) at a company which is not far from my place.

https://store-drotek.com/919-1025-dp0803-gnss-tiny-m9n.html#/106-case-with

https://store-drotek.com/909-u-blox-ann-mb-multi-band-antenna.html

https://raw.githubusercontent.com/drotek/drawing-pinouts/master/DP0102/DP0102%20GNSS.pdf

It has a USB connector and a JST-GH 6pins connector.

If this small board with the multi band U-blox antenna is OK ,  it is convenient for me due to proximity.

Indeed separate antenna helps optimize location of the antenna while keeping the electronics in a convenient area, probably behind the instrument panel.

Meanwhile, I have progressed with a data collection/ broadcast/ display prototype. It uses an ESP32 with a small TFT display. I can read serial data (TTL or RS232), display it (Vario and wind) and broadcast in WIFI for other onboard computers.

I need to order the UDB but meanwhile I would like to work on the telemetry decoding. From what I could find on Google docs (https://docs.google.com/document/pub?id=1bPovneDV1UXBBEQE6yC3Ms9CCI_wmecLGtVzUkJeoIw ), it seems the telemetry to use is  SERIAL_UDB_EXTRA and the data of interest is wvx0:wvy0:wvz0.
What is the format of the numerical value? (signed integer? float?).
Is there a way to get a dump of a telemetry stream so that I could use it to test my prototype?

Thanks,

JL

[Jean-Luc Derouineau]

I did forget to mention that I am considering having the GPS wired to my prototype and have the prototype send the GPS serial data to UDB.
This would allow me to directly broadcast GPS NMEA sentence to other onboard computers.
Also I don't remember I you confirmed that PPS signal is not used by UDB. Can you clarify?

Thanks a lot.

JL

[guy.franc...@gmail.com]

Jean-Luc,

The Droteck solution is great and convenient! I know Droteck, a serious company.

When I bougth my last GPS in ArduSimple store, it was delivered with the antenna you have selected. Unfortunately, this antenna is too heavy and has magnet socket which are not compatible with my small copter.

So I could send you this antenna, for a very good price!

In another project I worked with ESP12 and TFT display. It is a very versatile solution to visualize data and send them on Wifi, a lot of libraries are disponible on the Net!

Lot of gentlenav are using the second UART of the UDB to send data on a logging device.

Personally, I am using this UART with the Mavlink protocol, a standard telemetry protocol compatible with most of Ground Control System (GCS).

Even if I developped my own GCS, I use this protocol. I can send you typical dump data, but, perhaps, the other solution is more simple to integrate into your project. Bill and Ben could have a pertinent advice.

Could you give us a schema about the configuration you envisage on board : what kind of equipment do you connect together, what can of data are exchanged?

Aren't you a little worry to connect "amateur's" realisation with certificated avionic equipment on the glider...

Kind regards,

gfm

[Jean-Luc Derouineau]

Starting from the end.

As long as you don't change the configuration which has been used for certification, it is accepted to add devices which are not certified, as long as they don't affect the certified equipment's.

The electronic variometers and navigation computers, which are installed on gliders are not certified. UDB would be connected to a standalone variometer indication and would provide horizontal wind info the the navigation computer. None of that being certified or interfacing with certified equipment's.

I have no preference yet for data link protocols. I mentioned SERIAL_UDB_EXTRA because it is somewhat documented in UDB doc and seems simple. MAVLINK seems very comprehensive but maybe more complex to implement since I really only need wind on the 3 axis at a good update rate.

I will wait for Ben and Bill comments before deciding. In all cases I will appreciate help to access the info ( and possibly copies of some data streams ) to write and debug the decoding on the ESP32.

I am discovering ESP32 but it is a good and powerful platform. I wonder if it could eventually host the IMU/Wind algorithms solution but this should be discussed only after it is successful with a known sensor like UDB.

GPS:

- Antenna. Thanks a lot for the offer. Let me know how we can communicate to make this happen.

- GPS board. I will order the board from DROTEK.

- PPS. Can you confirm it is not required?

Best regards,

JL

[guy.franc...@gmail.com]

Bonjour Jean-Luc,

I confirm that UDB, nor our GPS, don't use or need connection on  PPS pin. PPS is, generally, a low 5V power to maintain the GPS in sleep mode.

PPS may also be the acronym for Pulse Per Second or Precise Positionning System. In any case, you could ignore this pin.

To communicate apart this blog we can exchange our email adress but I don't know how to get yours, I do not use any social network...

Perhaps Bill or Pete can have access to our email adress associated with our uavdevboard acount. In this case, one of the can send  you my email adress.

Best regards,

gfm

[Jean-Luc Derouineau]

Guy: sept huit trois deux trois deux trois trois quatre.

[Jean-Luc Derouineau]

Bill and team,

Maybe it is trivial and everybody knows how glider variometers work but, just in case, here is s short explanation on the current state of the art, the opportunities for improvement and the reason why your work might provide a path to a better instrument.

Traditionally, gliders have been using pneumatic variometers to measure the static pressure rate of change (vertical speed), to assess if the glider is gaining or losing altitude (potential energy)

Standard pneumatic vario are using air flow measurement. They are connected to a static probe on one end and to a capacity bottle on the other end. E.g. when the glider climbs, the pressure sensed is lower and the air flows from the bottle to the static probe. The reverse happens when the glider is descending.
Nowadays instruments are using sensitive pressure sensors, without capacity bottle, to directly measure the pressure rate of change.

Because modern gliders fly fast at high wing loading, they are very effective at transferring kinetic energy into potential energy. When a glider enters a climbing area, the pilot reduces speed fast to circle and gain altitude. During the fast speed reduction, the glider climbs because of the transfer of kinetic energy into potential energy. In the process, a vario connected to a standard static probe, will indicate a very high vertical speed, which is related to the transfer of the glider's energy and has nothing to do with the vertical speed of the air around the glider.

To resolve this problem, new static probes have been designed, to measure the static pressure in places where the pressure is an inverse function of glider's air speed (typically in the back of a tube in the air stream). These probes resolve the problem related to false vertical speed indication due to energy transfer (kinetic <-> potential). They are designed so that the pressure change due to speed variation is the opposite of the pressure change due to altitude change induced by speed variation. These probes are called total energy probes (TE).

A TE variometer doesn't indicate vertical speed. It shows the rate-of-change of the glider's total energy.  This is still state of the art today.

Because the TE variometer cannot discriminate between kinetic or potential energy change there are several problems with this solution. The major one being that, because of the significant horizontal wing gradients which happen in climbing areas ( horizontal gusts or wind shear in thermals ), glider's airspeed is changing without any altitude change, resulting in TE variometer false indication.

My hope is that, IMU/GPS wind estimation should provide the pilot with the vertical speed of the air mass surrounding the glider, without the artifacts associated to the other solutions.

By removing the estimated sink rate of the glider to the estimated vertical wind, the pilot should have good indication of the net vertical speed of the glider.

To be useful, accuracy and precision should be 0.1m/s or better and update rate at least 4-5 Hz.

Regards,

JL

[Robert DeHate]

Bill,

I have been working with the MatrixPilot on a UDB6mini.

I need to add an external high-G accelerometer and a pressure transducer.

I am investigating the DCI(Data Conversion Interface) module. Most of the documentation references audio.

But there is a small mention in the docs about A/D and D/A interface.

If it works as I suspect you write the I2C read word in byte 0 and tell it to go.

It runs without CPU interruption.

And when you get the DCI done message you just go read the 16bits of data.

This would also work great for a display because the DCI has 256 bytes of data.

You load it up with your data to display during the hearbeat and when the buffer is full just tell it to write to the display.

And if it works out I should be able to put the I2C address for my accelerometer in byte 0 and the address for my pressure sensor in byte 3.

When you tell it to go it will return with the read data in byte 1,2 and 4,5.

At least that is my hope.

I am going to make a board with only a 64pin u and I lose a few peripherals.

Regards,

Robert

On Tuesday, October 13, 2020 at 11:51:12 AM UTC-7 william premerlani wrote:

Hi Jean-Luc,

Thanks for your operational description, it helps a great deal.

Most of what we would need to do is straightforward and has been done before. Early in the development of MatrixPilot a friend of mine took me up in a two seat glider and the data we collected looked good.

There are two details I would like to think about a bit more:

1. GPS reception. What material is the glider made of? In particular I am thinking about GPS signal strength inside the glider. Fiberglass would be best. I am not sure about aluminum. In any case we would want to do some GPS ground testing from inside the glider. The test is simple enough: run UDB and GPS together and gather data. We know that the truth should be no motion, but GPS will declare otherwise. We will want to look at the reported location, velocity, HDOP and reported number of satellites in view.

2. A real time display. There are a few options, I would like to find one that does not require a lot of work.

The simplest and easiest to implement would be to connect servos to the UDB. I have done this sort of thing before, it is a way to get a visual indication. There are 8 pwm channels, so we could display up to 8 signals which we could select in software. The work on my end is trivial. On your end you would have to put some sort of indicators on servos and mount them.

You mentioned two other display options that I would want to get more detail on, they might require some work. One of them was a small display attached to UDB. Do you have any displays in mind? We have to consider the interface to UDBmini. It has I2C and SPI ports. We have written I2C and SPI drivers before for various peripherals. It is not hard to do, but it is not trivial. For this option, if you would point me to some displays that you like that have I2C or SPI interfaces, I would be willing to take a look.

You also mentioned a BT tap on the datalink. I assume that you are referring to the flight data that UDB sends to a data logger via a serial port. The part of it that I would not be much help with is getting the serial data to the BT. If we go that route I could tell you the format of the data stream and leave the rest up to you. Most likely you would have to build a board that would monitor the serial link and transfer selected data items to BT.

Best regards,

Bill

On Tue, Oct 13, 2020 at 8:37 AM Jean-Luc Derouineau <jlde...@gmail.com> wrote:

Bill,

The first goal would be to test on a real glider since it would be easier to install and perform tests/recordings.

When it works, it could be used on RC gliders as well.

The goal is to provide both real time horizontal (x/y terrestrial plane) and vertical (z terrestrial axis) wind indications. Vertical wind information is what Total Energy variometers try to measure.
Horizontal wind allows to optimize flight performance during transitions as well as anticipate for thermodynamic/wave conditions. Vertical wind could replace traditional TE vario during climb, without the secondary effect of TE probe due to horizontal wind gradient as well as load factor.

The first step would be to determine if UDB can compute wind with enough accuracy and precision to avoid use of air data sensors.

When this works, a second step would to propose an optimized flying pattern to the pilot to maximize climb performance.
This could be seen as a climb flight director which could be used by a pilot (real or RC) as well as an input to AP for RC.

I can install such a prototype on a 2 seater which is equipped with what is considered a good vario/computer (LX9050) that would be used as a reference.

A 2 seater has the advantage to let one person flying while the other focuses on the tests.

The goal would be to visualize UDB info in real time (to fly and compare to LX) as well as record the data to perform off line analysis. A small display attached to UDB or a BT connection on the datalink, connected to a smartphone, could be used for real time display.

JL

Le mardi 13 octobre 2020 à 01:25:05 UTC+2, william premerlani a écrit :

Jean-Luc,

You right, there are a lot of links broken and a lot of material you do not need.

I am willing to either guide you through and/or update the wiki.

However, if you could tell me a little bit more about what you want to do, it would limit the scope of what I need to do.

For starters, are you planning to control a model RC plane or are you going to bring the UDB along for a ride in a real glider as a variometer and/or vertical wind estimator?

Best regards,

Bill

On Mon, Oct 12, 2020 at 5:51 PM Jean-Luc Derouineau <jlde...@gmail.com> wrote:

I started to look at the MatrixPilot on Github.
Lot of info to read...

The board has a lot of interfaces that I will not need and the software has also lots of features I will not use since I really want to focus on using the wind estimation.

I can probably get the data I need from SERIAL_UDB_EXTRA.

I looked at the wiki (https://github.com/MatrixPilot/MatrixPilot/wiki) but I am afraid a lot of links are broken (referring to gentlenav).

Is there a tuto or equivalent that could help get started? (I did forget to mention I am a noob, especially with Microchip's MPLA).

Regards,

JL

--
--
---
You received this message because you are subscribed to the Google Groups "uavdevboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavdevboard...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/bac18ed4-0be0-45fc-a2ae-793770c248ban%40googlegroups.com.