I hope this hasn't been yet posted in other topics...
I'm newbie in Arduino and I am looking for code informations to create a box equipped with a nano, screen oled and piezos which could collect the i2c values of both a compass and a timer, to record them every 10 seconds ( for example ) then would, with each change of heading or every minute, display the resulting vector ( heading + time ) at the following of the previous vector displayed.
A kind of road book created by the user during his journey showing the time spent on each heading.
The use is simple and would come in addition to the compass and lines we use during cave diving for the main purpose of topos surveys for exemple.
I already have the case and piezo.
The question is whether it is possible to easily apply a code to display on an oled:
the current bearing,
cumulated time ( or approximate length using the accelerometer?) for all vectors created
the track created and saved on a sd card.
In an ideal world, using the piezos to signify the half turn or stop or pause, and then on half turn invert the created display and scroll to check the infos logged, would be also great though...
No need for background, impossible to use gps tracking in this environment, so any good advice will be really appreciated for this project...
As I said in my post : GPS simply don't work in caves 3 or 4kms long
We're not speaking about a journey to the center of the earth, but only about up to 5 hours underground diving and walking
As I also said : the timer is the second info, not the speed. So, I guess time+direction could easily give a vector? We for exemple use gribs files for sailing that include strength of wind + bearing. TMO, a value is a value. But maybe the accelerometer could give a speed.
I guess I didn't read your question very well. Sorry for that.
The length and the track is really a problem if the speed is not known.
It is possible to show a direction (I think that is what you call the "vector").
Using the accelerometer to determine the speed and position is possible indoors for a short time and only a number of meters. But the sensors are noisy and drift.
I suggest to get a accelerometer + gyro + magnetometer and calculate everything with a standard library. Perhaps you can use the direction. I think it will be very hard if the box can be held in every way. Using the accelerometer to determine in which direction (with the compass) the box is moving will not be easy.
His newest code is with a MS5637 barometer. I think that is useless under water. It would be nice if a water pressure sensor was added to calculate the depth.
For now, the MPU-9250 with AHRS is a good start, in my opinion.
1/ You're right, it's gonna be difficult to get precise values from the MPU even with a AHRS. If I understand, maybe making an average of the bearings collected over a minute could be the solution?
2/ If I understand how it should works,
the values written and collected every mn are "time" and "MPU-9250 and its ahrs filter bearing or the average over a designated time lapse ".
They can become "variables" that can be stored using the IDE and then be collected when needed ( let's say the last variables created or the variables created concerning the last mn, which can be convenient but could create some troubles later on for the display ).
They can be "applied" to or with a "constant" which could be the lenght of the vector for 1mn.
The main problem then is : how to screen each new vector following the last one without deleting it.
Two possibilities then :
either display every vector following the last one every one mn. Ok that's the original idea.
either calling using piezo every stored vector but that would display any vector only by one mn samples...
So, I guess the simplest solution would be to :
get rid off this "vector" thing and
only create a displayed logbook with a line created every time the bearing changes in a significant way ( let's say 15° ), then displaying for each significant bearing one line with " everage bearing calculated", " time spent following this bearing", " total dive time at the end of this period" ( we only use this method for our deco plans and with our dive computers, anyway. Moreover, this value would tell us roughly how much time is needed to get back. So even better ). Piezos would be used to navigate among this logbook.
Only left problem : the bearings stored in the logged book need to be corrected to show the correct heading for the return. So, even if its possible to correct the heading to display it correctly in the log, we still need to acces to the initial datas for topo needs
Koepel, you did great for giving me a better start for this project tlaking about adding the depth value I don't need any shield, just to display a log of stored values. Am I right?
ok so making an average including all samples made during a minute is ok
Storing is made using the AT24C512, ok.
The Oled, I have to check the exact room available but a 2.7" would be easier to read underwater, 1.3 is really small even if it seems perfect at first.
So, we have now two needs :
one log book including the data collected w or wt the average made ( for the topo needs later on),
and one log book with the “return” heading.
Could the return just be calculated and stored like this in the second logbook : if heading value>180 then display value-180, if heading value<180 then display value+180 ?
Detecting the direction when the box is moving is a very hard. I don't even know if someone has done that.
A software engineer would not need a logbook with the return values, just the stored values are enough to calculate them.
Maybe you could ask another question on this forum. For example "How to calculate the direction when carrying a box with a MPU-9250". I doubt if someone has the solution, and I don't have it either.
When you ask a follow-up question, add a link to this one, so others know the background.
A magnetometer shows where the magnetic vector points to. That is not to the north at the horizon, it can point upward or downward. That’s why a tilt-compensated compass is important. To measure to direction to where you are walking is hard to determine. It is easier with a car that goes straight most of the time with a few turns.
I think that it can be done, and someone should do it. But this is not for a beginner.
Ok, but let's say it works on three axes, and that z is the axe for height. Why not using mainly x and y while minoring z for keeping a small tilt function? Koepel, in fact I don't really understand why a tilt compensated, rather than a simple module like the HMC5883L for exemple?
When you would have it in a box that you carry with you, then the box is hardly always flat horizontal. Because of that and because of the magnetic inclination the compass will be inaccurate.
The compass is usually flat because put on a dpv arm or held in front of the diver during the dive if needed. But what is working best , you're right, is compasses permitting a reading up to 15° inclination.
I guess the project is far to complex for replacing actual tools. I'll then wait and see if future created projects around arduino or Raspberry will match for this kind of use.
Thank you a lot for your help and informations, Koepel
