search

Openvario / meta-openvario

Official OpenEmbedded layer for Openvario flight computer.
http://www.openvario.org
31 stars 29 forks source link

Sensorboard microcontroller board #283

Open iglesiasmarianod opened 2 years ago

iglesiasmarianod commented 2 years ago

I'm working on an intermediate microcontroller board to get sensor data. I'm using ESP32 and, so far, I'm getting data from sensors, I still need to change sensord so it can read from this board. My idea is to plug this microcontroller between sensorboard and mainboard, then add a configuration option to sensord so it reads data from the intermediate board or sensorboard directly. This way we get full backwards compatibility. The only hardware modification is adding a flat cable and a very small board that will fit inside the case. The board polls sensors regularly and store data in a buffer for sensord to get it. This way there's no need to change your sensorboard. I can get IMU data as well, so we will need to change OV protocol in case we want to send this data to XCSoar. This board will need to be updated. I was thinking about an update option in th OV menu, but still can't see how to implement this. The IDC port has serial pins. What do you think it is the best way of doing this updates?

On the other hand, a new sensorboard is being developed with new sensord. I don't know if the new sensord is going to be backwards compatible. I want to add this option to the sensord we have, I believe the new sensord should be written in the same way so the user can choose wich option to use. New sensorboard, old sensorboard, intermediate board. Thoughts?

hpmax commented 2 years ago

@DanD222 and I designed a replacement sensorboard with an ESP32-S2 on it. The new board is mechanically a drop-in replacement for the old one but has a lot of improvements including much newer/better sensors. It'll require new software, but, so what... If you're rolling a new custom board anyway, what's the benefit of this vs using the a new sensorboard? I just don't like seeing the project split into so many versions. In the end, that's not going to really help anyone.

linuxianer99 commented 2 years ago

I think both approaches are valid.

Some toughts in my mind for both solutions:

@DanD222 , @hpmax , @iglesiasmarianod : Maybe you can have a look to use the same software sources (the controller is the same, so this should be possible) ?

Should we open a new topic in the discussions ??

iglesiasmarianod commented 2 years ago

That'll be nice @linuxianer99. Sensorhub (as you named it :) ) is not meant to replace new sensorboard. It solves timing problems we have and provides some backwards compatibility. I will not run sensord or variod from this board and it will not be stand alone. Cost will be low, modifications minimal. Points I believe might be important to discuss may include:

I can help with ESP32 code. For testing purposes I'm using Arduino IDE. Final code will be written using ESP-IDF and eclipse.

hpmax commented 2 years ago

@iglesiasmarianod I have no experience with ESP32 coding... If you could give me a starting point, it would be much appreciated.

FWIW, my ultimate goal is to develop an external device that would talk to OV (or XCSoar) over Bluetooth and give you a fully independent device with a display. I think this improves the reliability of the system versus relying on OV.

mihu-ov commented 2 years ago

Maybe you want to look at https://github.com/iltis42/XCVario for a starting point?

iglesiasmarianod commented 2 years ago

Hi guys. A good starting point would be Espressifs site. You'll find all chip info and programming guide. I usually start using Arduino IDE before writing pure C code. You may also look here https://forum.xcsoar.org/viewtopic.php?f=30&t=3062&start=135 There you'll find some code for my external vario gauge. As @linuxianer99 said, it would be great of we can agree a protocol to communicate with OV.

hpmax commented 2 years ago

@iglesiasmarianod I'm happy to work with you on an appropriate protocol. I anticipate having:

GPS data (position, ground velocity), AHRS data (roll, pitch, magnetic heading), airspeed (indicated and true), static pressure, and compensated vario, outside air temp, humidity, and voltage.

I could potentially provide uncompensated vario, and netto data as well. I will try to compensate for magnetic deviation internally, but there is an additional question of should I compensate for magnetic variation. Given GPS data and some knowledge of where the north pole is, I assume it shouldn't be hard, but given how fast the north pole is moving, I'm not sure there is an easy way to get that information from the Internet. Best I could find is here:

https://www.ngdc.noaa.gov/geomag/GeomagneticPoles.shtml

I think most of this is actually covered in currently existing protocols. We certainly have voltage, AHRS can be done through Levil protocol, GPS is GPS, temperature and I think humidity are in the current environmental protocol, etc.

Flap settings would be interesting, but I'm not sure how best to do a flap sensor. My first guess, only because I like non-contact, and I think it would work on my LS6 is to attach a small reflective "target" via a hose clamp under my flap control rod and then mount a small optical time-of-flight detection sensor and an Arduino or some other microcontroller that would communicate via USB or BT to the OV directly.

lordfolken commented 2 years ago

Please try to avoid inventing additional Protocols, XCVario/OpenVario does most of what you currently want. The only thing i couldn't find is voltage. https://github.com/XCSoar/XCSoar/blob/051adf385a61ece227360f91f70ea13096354b4d/src/Device/Driver/XCVario.cpp#L51-L71

hpmax commented 2 years ago

@lordfolken As stated, I don't want to invent a new protocol if I don't have to. XCVario protocol doesn't strike me as that comprehensive.

It lacks humidity, voltage, magnetic heading, airspeed (true/ indicated) as well as roll/pitch/yaw rate. That said, most of these are covered by other protocols that XCSoar ALREADY covers. The OV protocols have airspeed, voltage and I think humidity. I believe Levil covers magnetic heading and rates.

iglesiasmarianod commented 2 years ago

Hi guys. My intention is not inventing a new protocol. I want to include IMU data into existing OpenVario $POV protocol so it can be used by sensord and variod. I believe an improvement to sensorboard and, in the end, a new one with an MCU for new devices is the way to go. This leads me to the question about what to do with sensord and variod:

hpmax commented 2 years ago

@iglesiasmarianod To be clear, when I first discovered the flaw with the MS5611, my original proposal was to attach an AVR to the I2C port on the back of the sensorboard, and allow the AVR to poll all the sensors and shove the data into a FIFO, and then have sensord read out the FIFO through the i2c. My concern with this is sensord would have to know when to talk (and when not to talk) to the AVR. Without a separate way to communicate to the AVR (or in your case the ESP32) it's probably a bit tricky.

The new sensorboard does have a Class AB audio amplifier on it. It is setup to allow creation of an audio variometer mixing of audio from the Cubieboard either with analog circuitry, or potentially digitally via the ESP32 with the vario audio. Honestly, I think it's a crappy solution. If Max can integrate the audio into XCSoar and have it work well, I'd prefer that, but... one of the points behind making a separate device is that it could operate properly even if XCSoar/OV crashed or otherwise had problems.