Gyroscope, theoretical discussion
- Thread starter edmunds
- Start date
Dear all,
Help needed. I thought I had it figured out (and basic setup kind of works, but don't know why), but more I think of it more confused I become.
1. There is gyro ODR [output data rate]. This is how many samples per second the gyro takes. Can be changed from 12.5Hz to 1660Hz in the case of LSM6DS3.
2. There is FIFO ODR. This can be between 12.5Hz and 6660Hz. This is suggested to keep such, that a read of a single sample would be less than 1*ODR. If I don't do any calculation, but just read, this caps the frequency to max 208Hz (out of available settings) with I2C 400kbit/s.
How on earth does #1 relate to #2? What are reasonable, best sampling rates or rather, how would one calculate some minimum, maximum or best rate? What is my sampling rate for the calculation of angle in this case - the gyro ODR or FIFO ODR? Should be gyro, but how do I factor in FIFO rate?
3. There is FIFO decimation. Possible values are from 2 to 32.
Is this just throwing out samples? Does it mean I keep every 32nd sample or throw out every 32nd sample?
I have read data sheet multiple times from start to end, a respective application note and a few more application notes on similar sensors, but it must be I have a gap in theory knowledge and/or terminology, because I just cannot read what I'm after to put a picture together on a sheet of paper.
Thank you for your time,
Edmunds
Help needed. I thought I had it figured out (and basic setup kind of works, but don't know why), but more I think of it more confused I become.
1. There is gyro ODR [output data rate]. This is how many samples per second the gyro takes. Can be changed from 12.5Hz to 1660Hz in the case of LSM6DS3.
2. There is FIFO ODR. This can be between 12.5Hz and 6660Hz. This is suggested to keep such, that a read of a single sample would be less than 1*ODR. If I don't do any calculation, but just read, this caps the frequency to max 208Hz (out of available settings) with I2C 400kbit/s.
How on earth does #1 relate to #2? What are reasonable, best sampling rates or rather, how would one calculate some minimum, maximum or best rate? What is my sampling rate for the calculation of angle in this case - the gyro ODR or FIFO ODR? Should be gyro, but how do I factor in FIFO rate?
3. There is FIFO decimation. Possible values are from 2 to 32.
Is this just throwing out samples? Does it mean I keep every 32nd sample or throw out every 32nd sample?
I have read data sheet multiple times from start to end, a respective application note and a few more application notes on similar sensors, but it must be I have a gap in theory knowledge and/or terminology, because I just cannot read what I'm after to put a picture together on a sheet of paper.
Thank you for your time,
Edmunds
Last edited:
I would guess it means that if you leave it to fill up the FIFO it can fill at a maximum sampling rate of 1660Hz. In one second it will have accumulated 1660 samples, in two seconds it will have accumulated 3320, in four seconds 6640 samples.
Because you can empty the FIFO at a faster rate of 6660Hz, you can leave it to run for four seconds, then empty the FIFO in just one second and everything will be fine.
Whatever the actual time periods involved are it means your main program can sleep for 75% of the time and not lose any sample data even at the maximum sampling rate.
BeanieBots
Moderator
Obviously, you want to run at the fastest rate possible.
If your processor cannot keep up with real time data, you can use the FIFO to grab data in bursts but the maths to compensate for time error would be horrific even for a full PC with 64 bit floating maths to number crunch. FIFO decimation is when the FIFO buffer fills and data is lost. Hopefully the datasheet explains how it does that. eg no more data or if it overwrites etc. etc.
I admire your persistence but I fully agree with everything BESQUET has said. He clearly has a very good understanding of this subject and I would take his comments on board.
I have been down a similar road myself using gyro compensation in helicopters. My advice would be to simulate some of the functions in an Excel spreadsheet and see what comes out. If you put in realistic sensor errors and even using floating maths see what happens to your integral calculations as a result, you will soon draw your own conclusion about what sort of results are feasible.
If your processor cannot keep up with real time data, you can use the FIFO to grab data in bursts but the maths to compensate for time error would be horrific even for a full PC with 64 bit floating maths to number crunch. FIFO decimation is when the FIFO buffer fills and data is lost. Hopefully the datasheet explains how it does that. eg no more data or if it overwrites etc. etc.
I admire your persistence but I fully agree with everything BESQUET has said. He clearly has a very good understanding of this subject and I would take his comments on board.
I have been down a similar road myself using gyro compensation in helicopters. My advice would be to simulate some of the functions in an Excel spreadsheet and see what comes out. If you put in realistic sensor errors and even using floating maths see what happens to your integral calculations as a result, you will soon draw your own conclusion about what sort of results are feasible.
Well, the data sheet does not and I don't think you are right, because there is a whole chapter on how overfilled FIFO is handled and decimation register is never mentioned. I have also gone through tons of example code in C and while I'm not an expert in coding it myself, I can read most of it. Some people use the decimation, but with no explanation why and how. Why I'm interested in it at all is because of the different rates between FIFO ODR and 'real' ODR. The examples I can see are all running FIFO at lower ODR than the gyro ODR. To do this, some data has to go somewhere else, not in the buffer
. The only place I can think of is trash and if this is the case, I would have to match all three settings - both ODRs and decimation the latter being the difference between the two.Well, then you will understand I'm not giving up before I have a 6DOF thingy that works, so I understand what it is doing and why, picaxe code that is reasonably correct and fast and all of that does not give me a vehicle that can do 20cm square test
.It is all a learning thing after all.
Edmunds
BeanieBots
Moderator
Either way, decimation results in data loss. For a fuller explanation, have a read of this:-
https://en.wikipedia.org/wiki/Decimation_(signal_processing)
The point I was really trying to make is that the data that comes via a FIFO will be "late" compared to your other data and this needs to compensated for in your maths making the task even harder than it already is. Your servo loops needs to run as fast as possible to avoid accumulative errors. Unless you can compensate for the time difference, there is little or no point in obtaining data that is out of sequence with your other data.
https://en.wikipedia.org/wiki/Decimation_(signal_processing)
The point I was really trying to make is that the data that comes via a FIFO will be "late" compared to your other data and this needs to compensated for in your maths making the task even harder than it already is. Your servo loops needs to run as fast as possible to avoid accumulative errors. Unless you can compensate for the time difference, there is little or no point in obtaining data that is out of sequence with your other data.
Buzby
Senior Member
Hi edmunds,
I'm pleased to see you are trying hard, it will be a first for PICAXE if you get the thingy working.
Regarding why decimate, I'm no expert here, but I think it's something to do with anti-aliasing.
There's a lot to study in that datasheet, good luck !.
Cheers,
Buzby
I'm pleased to see you are trying hard, it will be a first for PICAXE if you get the thingy working.
Regarding why decimate, I'm no expert here, but I think it's something to do with anti-aliasing.
There's a lot to study in that datasheet, good luck !.
Cheers,
Buzby
Buzby
Senior Member
From reading the datasheet, it looks like the FIFO is useful in applications where the Master can sleep until the FIFO is full, then process the data in a burst. It doesn't sound like you need the FIFO at all in your application, or maybe just a very short ( 1-deep ? ) FIFO might allow reading co-incident gyro and accl data in two consecutive reads.
I would have expected it meant keeping every Nth sample, discarding the rest. "Decimation" is "removal of a 10th" so perhaps it does mean that later, removing the 32nd rather than only keeping the 32nd. Colloquially "decimated" is these days taken as more akin to reduction to a tenth. I am not familiar with the term in the context it is being used. Perhaps it accumulates an average of N readings before returning a single value.
Without a clear explanation you might have to try it and see which it is. If you aren't decimating or using the FIFO you likely don't have to worry about it.
As to why one would use decimation rather than simply sampling at a lower rate I have no idea. Perhaps that gives more options when the two are combined rather than just having sampling rate. It may be there to provide for lower sampling rates and not be as applicable to faster rates.
Last edited:
BeanieBots
Moderator
I'm not familiar with this exact device but 'normally' decimation (as applied to signal processing) involves some form or another of filtering which can be as simple as averaging but is often more complex and done in hardware.
lbenson
Senior Member
From BeanieBots's Wikipedia article, "decimation" in hardware could give different, and more accurate/useful readings than "down-sampling", or sampling at a lower rate.
I would take a stab at understanding decimation values of 2-32 as meaning that in hardware, each value that is returned or that goes into the FIFO is a calculated number (e.g., average, but possably something different) of between 2 and 32 readings.
(That's basically what BB said above.)
I would take a stab at understanding decimation values of 2-32 as meaning that in hardware, each value that is returned or that goes into the FIFO is a calculated number (e.g., average, but possably something different) of between 2 and 32 readings.
(That's basically what BB said above.)
Hi,
However, IMHO the FIFO would be better avoided if possible, since it basically introduces a delay that you probably don't want.
Yes, the "ultrasonic satellites" idea might be a challenge for an "exhibition" environment. Echoes and jangling keys (for example) could cause problems that might need nearer to "real" GPS techiques to be used (spread-spectrum and cross-correlation, etc.). Or perhaps adapt one of the older radio navigation techniques such as Loran (but I'm no expert on those).
Personally, I'd be looking at dead-reckoning using counting of (differential) wheel-rotations. I haven't started on my own micro "line-sensor pinhole-camera" yet, but the intention is to increase the field of view to "see" at least as far as the (inside of the) front wheels (which might be marked with "strobe" lines), so their rotation could be determined without any additional hardware.
Cheers, Alan.
The "classical" (Roman) definition would imply "throw out every 32nd" value, but my guess is that they are almost certainly using the more modern meaning and keeping only every 32nd value. The designers of the chip might have arranged some form of averaging, but I had assumed a simple "select every nth sample" method.
However, IMHO the FIFO would be better avoided if possible, since it basically introduces a delay that you probably don't want.
Yes, the "ultrasonic satellites" idea might be a challenge for an "exhibition" environment. Echoes and jangling keys (for example) could cause problems that might need nearer to "real" GPS techiques to be used (spread-spectrum and cross-correlation, etc.). Or perhaps adapt one of the older radio navigation techniques such as Loran (but I'm no expert on those).
Personally, I'd be looking at dead-reckoning using counting of (differential) wheel-rotations. I haven't started on my own micro "line-sensor pinhole-camera" yet, but the intention is to increase the field of view to "see" at least as far as the (inside of the) front wheels (which might be marked with "strobe" lines), so their rotation could be determined without any additional hardware.
Cheers, Alan.
BeanieBots
Moderator
I concur with AllyCat. Dead reckoning would also be my choice using interrupts to process as and when each event happens. Even that would suffer with accumulated error but it should be small enough to compensate with periodic markers to reset.
The use of an optical mouse output might be fun to try.
To see how even that can accumulate errors, try it on your own PC. Put your mouse inside a box and follow the perimeter inside. Then try it with your eyes closed. Perhaps using a paint program to draw the shape of the inside of the box. See what happens.
Anyway, this is a 'holy grail' so do keep going. Many (including myself) will be interested and willing you along.
The use of an optical mouse output might be fun to try.
To see how even that can accumulate errors, try it on your own PC. Put your mouse inside a box and follow the perimeter inside. Then try it with your eyes closed. Perhaps using a paint program to draw the shape of the inside of the box. See what happens.
Anyway, this is a 'holy grail' so do keep going. Many (including myself) will be interested and willing you along.
Although no gyros and no accelerometers, have a look at the PICAXE micromouse KIT 110. The videos show pretty impressive manoeuvering together with a purpose: getting from a corner to the centre of the maze.
Maybe I got the wrong end of the stick; nevertheless, the videos are fun to watch.
Maybe I got the wrong end of the stick; nevertheless, the videos are fun to watch.
Hi,
A differentially steered, stepper robot is basically the reverse of a wheel-sensed car, so I would expect wheel-sensing to work at least as well a robot.
Cheers, Alan.
Yes, I've wondered about that and if the PICaxe KBIN command would produce anything useful (the raw PS2 protocol is too fast for PICaxe). Maybe you could still find a "compatible" serial optical mouse. But I'm not clear exactly why the "LED" in an optical mouse flashes light/dark as much as it does.
A differentially steered, stepper robot is basically the reverse of a wheel-sensed car, so I would expect wheel-sensing to work at least as well a robot.
Cheers, Alan.
Thank you all for your inputs,
I have been a little busy with other stuff today, but I have more and new ideas and there are several old ideas that need verification and testing in code that I have not yet had time for. Will do my best to catch up in the coming days.
I do want dead reckoning, this is what I'm after. Wrongly or not, I think gyro can be part of what I need as distance (including direction) + angle can take me anywhere worth going. Angle is proving to be increasingly difficult to achieve, but hey - nobody said it was going to be easy.
Edmunds
I have been a little busy with other stuff today, but I have more and new ideas and there are several old ideas that need verification and testing in code that I have not yet had time for. Will do my best to catch up in the coming days.
I do want dead reckoning, this is what I'm after. Wrongly or not, I think gyro can be part of what I need as distance (including direction) + angle can take me anywhere worth going. Angle is proving to be increasingly difficult to achieve, but hey - nobody said it was going to be easy
.Edmunds
BeanieBots
Moderator
We all have different approaches to projects. None are better or worse, just different.
I like to do basic maths first to determine feasibility and then build to see what really happens.
Taking this approach, why not build something simple such as a cart that can move in one axis only. (eg model train on rails) and fit a gyro plus encoder.
Then test to see what the ACTUAL results are and how repeatable those results can be.
I like to do basic maths first to determine feasibility and then build to see what really happens.
Taking this approach, why not build something simple such as a cart that can move in one axis only. (eg model train on rails) and fit a gyro plus encoder.
Then test to see what the ACTUAL results are and how repeatable those results can be.
1)Try with the lowest data rate (no need for FIFO ; Picaxe read data in real time)
2)Try to achieve the square test. Will be inaccurate.
3)Slowly increase data rate and measure improvement till Picaxe overload.
4)Optimise code...
As horizontality seems to be possible in your case, magnetometer may be more reliable and easy to read than gyrometer.
Last edited:
Orientation and speed
Dear all,
I have made further improvements to gyro orientation result stability by rewriting everything based on interrupt, rather than polling data ready register. The code is dead simple and does the following:
1. Sets up gyro for single axes, 12.5Hz ODR. This gives 76ms between pulses, so if this rate turns out to be sufficient in any way, there is plenty of time for picaxe. Each following incrementation to next ODR halves this. I believe, quite something could be done in 40ms as well, at 20ms it would become tricky and later very difficult or impossible.
2. Sets up gyro to issue an interrupt when 'data is ready'.
3. Activates hardware interrupt on picaxe, pin B.1 (B.0 occupied with infrared, B.2 still available, probably for obstacle avoidance or layout edge (possible fall) detection).
4. Interrupt procedure handles the read and calculation of angle. Takes about 0.2ms to read two bytes and 0.17ms to calculate signed angle and sum it to the previous value. Reseting the interrupt takes another 0.1ms. 0.47ms in total. All measured at 64MHz.
It is a difficult thing to video the way it would make sense, but there is no zero drift that would be of any interest for the time span we are discussing. If it exists, it is below the level of low pass filter for minutes, which is very good for what I need. However, the gyro does not return to zero (or whatever the initial state) and progressively so (expected). I would like to start to experiment with ways of mathematically removing this and zeroing it as often as possible, while in parallel I study the magnetometers to choose which one to place an order for for Monday, but I realise there is one more question mark.
How do I take into account the changing speed of the vehicle? What is the relationship between angle and speed? Or, actually, speed is degrees per second, which I just converted to orientation in degrees... My first thought was, I would measure angle at every pulse of my odometer, so taking speed into account would be automatic. But that only works if I have a source of absolute angle, which is ok to poll irregularly. Now I cannot get my head around the concept somehow.
Thank you for your time,
Edmunds
Dear all,
I have made further improvements to gyro orientation result stability by rewriting everything based on interrupt, rather than polling data ready register. The code is dead simple and does the following:
1. Sets up gyro for single axes, 12.5Hz ODR. This gives 76ms between pulses, so if this rate turns out to be sufficient in any way, there is plenty of time for picaxe. Each following incrementation to next ODR halves this. I believe, quite something could be done in 40ms as well, at 20ms it would become tricky and later very difficult or impossible.
2. Sets up gyro to issue an interrupt when 'data is ready'.
3. Activates hardware interrupt on picaxe, pin B.1 (B.0 occupied with infrared, B.2 still available, probably for obstacle avoidance or layout edge (possible fall) detection).
4. Interrupt procedure handles the read and calculation of angle. Takes about 0.2ms to read two bytes and 0.17ms to calculate signed angle and sum it to the previous value. Reseting the interrupt takes another 0.1ms. 0.47ms in total. All measured at 64MHz.
It is a difficult thing to video the way it would make sense, but there is no zero drift that would be of any interest for the time span we are discussing. If it exists, it is below the level of low pass filter for minutes, which is very good for what I need. However, the gyro does not return to zero (or whatever the initial state) and progressively so (expected). I would like to start to experiment with ways of mathematically removing this and zeroing it as often as possible, while in parallel I study the magnetometers to choose which one to place an order for for Monday, but I realise there is one more question mark.
How do I take into account the changing speed of the vehicle? What is the relationship between angle and speed? Or, actually, speed is degrees per second, which I just converted to orientation in degrees... My first thought was, I would measure angle at every pulse of my odometer, so taking speed into account would be automatic. But that only works if I have a source of absolute angle, which is ok to poll irregularly. Now I cannot get my head around the concept somehow
.Thank you for your time,
Edmunds
With a gyrometer drift is mandatory.
As per #23
tolerance is 40mm-26 mm = 14 mm
Expected travel is 2000mm
so
alpha=asin(14/2000)=0.4°
Travel time is 2000/280=7 s
Possibilities are :
- very good gyrometer with minimal drift (and accurate time measurement)
- go faster...
Error on angle is directly proportional to error on time. (#15)
To "convert" from degrees/sec to degrees, you also need time.
If interval is 1/10sec and angular speed 90°/sec then each measure is 9°
If you measure this speed during 5 intervals, angle have increased (or decreased) 45°
If you have a servo, you can try making a compass :
When rotating sensor, servo must keep his heading (at least for 180°).
If rotation speed is measured at irregular interval, you must take into acount the duration of each interval.
At start, after a little delay, angular speed must be zero or a constant (bias).
Supposing sensor is steady at start, simply substract this bias.
So now, angular speed must be zero when sensor does not rotate, specialy when it move with same heading.
Now, you can integrate angular speed to have an angle.
If sampled at regular interval, formula is linear.
To show the angle, sertxd is not usable ; prefer using a servo as indicator.
As per #23
tolerance is 40mm-26 mm = 14 mm
Expected travel is 2000mm
so
alpha=asin(14/2000)=0.4°
Travel time is 2000/280=7 s
Possibilities are :
- very good gyrometer with minimal drift (and accurate time measurement)
- go faster...
I suppose you mean rotation speed, not linear speed.
Error on angle is directly proportional to error on time. (#15)
To "convert" from degrees/sec to degrees, you also need time.
If interval is 1/10sec and angular speed 90°/sec then each measure is 9°
If you measure this speed during 5 intervals, angle have increased (or decreased) 45°
If you have a servo, you can try making a compass :
When rotating sensor, servo must keep his heading (at least for 180°).
If rotation speed is measured at irregular interval, you must take into acount the duration of each interval.
What is gyro ? Angle or angular speed ?
At start, after a little delay, angular speed must be zero or a constant (bias).
Supposing sensor is steady at start, simply substract this bias.
So now, angular speed must be zero when sensor does not rotate, specialy when it move with same heading.
Now, you can integrate angular speed to have an angle.
If sampled at regular interval, formula is linear.
To show the angle, sertxd is not usable ; prefer using a servo as indicator.
Last edited:
Dear @BESQUET,
Thank you, this was exactly what I needed to take it further. Unblocked my mind.
Great, more work to do. Thanks again,
Edmunds
Thank you, this was exactly what I needed to take it further. Unblocked my mind
.It is actually worse than this, there is 7 mm of acceptable error to each side. And spinning the layout at 280mm/s (~90km/h) is not ok for most places, so it has to know how to go slower. But I understand what you are saying and this getting back to basics kick was what I needed.
This actually sounds pretty possible. I will try some models in a spreadsheet. Reality is I need to do it anyway, as I do need to know the speed I'm travelling with.
Because of the time it takes? So I should make sure I compensate for whatever my signal processing and reacting to the error takes in the algorithm. Or at least try the best I can.
Great, more work to do
. Thanks again,Edmunds
Last edited:
Dear @BeanieBots,
This would be cool to do, but along with programming and electronics, I'm also learning a lot about physics and mathematics. Its a blessing I went to a high school with math emphasis, so we studied calculus in school, while this is normally part of a university course (at least where I'm from). Also, physics and IT was pretty advanced, but after that I graduated law and MBA in business administration. I'm not afraid of learning, but there has been and is a steep learning curve with all of this. I have since taken a few online robotics, artificial intelligence and electronics courses, but applying them is still a challenge at times and one of the reasons I turn to the forum for advice (apart from it being fun) is because I do not have the skills (yet) to come up with good models for the systems I design.
Thank you for your input,
Edmunds
YES
I do no think it is possible to compensate. Sertxd is very long and not compatible with interrupt handling...
Another way is to store raw data in memory for further analysis with Excel.
BeanieBots
Moderator
Excellent, you have calculus and presumably trig? You will need a good understanding of both to model this.
We're at sub light speed so no need to worry about anything Einstein has to say about it. Just concern yourself with Newton.
S=U.t + (A.t^2)/2 and all its derivatives (in the calculus sense) to get the individual parts.
[S=distance, U=initial velocity, A=acceleration and t=time]
Where it gets tricky is that for a 2-dimensional system (as in your case) all of these values are vectors and must have their own individual angle associated with each other and to make it even more fun, they must also be in the same time domain. That is why using the FIFO will make things complex because I do not see how you can apply the required time correction for the vector calculations.
It is also why I suggested doing the basic "is this possible" maths using a single angle example such as a train on a track. That avoids the need to worry about vectors at all.
Once you have this modelled, you can then play with iteration times, quantising errors and calculation precision.
For what you want to do, my gut instinct is that you would need to iterate at several 10's of kHz minimum with a precision of at least 32 if not 64 bit.
Trying to do that (plus the later to be introduced trig functions) would be, how could we say, a "challenge" for a PICAXE.
I would not even try it on a PC because they have a habit of going off periodically to service interrupts which would throw out all your time domain calculations.
(models don't care about this but real-life does)
As you say, it's all about learning and the fun of trying. Trying this will be an excellent learning exercise in all aspects. Maths, control systems and embedded micros.
Even if you fail miserably, as long as you understand how and why what happens when it does, then it will have been a very fruitful lesson.
Even simple real-life issues like BESQUEUT has pointed out above. Inserting a simple sertxd to try and see what is going on can mess things up because an interrupt might be missed and the slow serial output will throw out your iteration times.
We're at sub light speed so no need to worry about anything Einstein has to say about it. Just concern yourself with Newton.
S=U.t + (A.t^2)/2 and all its derivatives (in the calculus sense) to get the individual parts.
[S=distance, U=initial velocity, A=acceleration and t=time]
Where it gets tricky is that for a 2-dimensional system (as in your case) all of these values are vectors and must have their own individual angle associated with each other and to make it even more fun, they must also be in the same time domain. That is why using the FIFO will make things complex because I do not see how you can apply the required time correction for the vector calculations.
It is also why I suggested doing the basic "is this possible" maths using a single angle example such as a train on a track. That avoids the need to worry about vectors at all.
Once you have this modelled, you can then play with iteration times, quantising errors and calculation precision.
For what you want to do, my gut instinct is that you would need to iterate at several 10's of kHz minimum with a precision of at least 32 if not 64 bit.
Trying to do that (plus the later to be introduced trig functions) would be, how could we say, a "challenge" for a PICAXE.
I would not even try it on a PC because they have a habit of going off periodically to service interrupts which would throw out all your time domain calculations.
(models don't care about this but real-life does)
As you say, it's all about learning and the fun of trying. Trying this will be an excellent learning exercise in all aspects. Maths, control systems and embedded micros.
Even if you fail miserably, as long as you understand how and why what happens when it does, then it will have been a very fruitful lesson.
Even simple real-life issues like BESQUEUT has pointed out above. Inserting a simple sertxd to try and see what is going on can mess things up because an interrupt might be missed and the slow serial output will throw out your iteration times.
I was talking about angular speed (°/sec) as measured by gyro meter. If irregular interval, you have to calculate increase in angle during each interval.
If regular interval, applied time is always the same and known when you write code. So it is easier and quicker.
IHMO, you don't need linear speed : only distance (mm)
and maybe time if you want to estimate angular drift.
(so of course you can calculate mean linear speed)
You only need that if only A is known (accelerometer ; mm/s/s)
But you already know S (odometer ; mm) witch is many more accurate and not subject to drift^2
(Remember : one drift to integrate from A to velocity, and another one to integrate from velocity to S...)
Forgot that...
Last edited:
Found a very good writeup on magnetometer+accelerometer implementation. Not on the manufacturers website anymore, so download to your computer if interested .
Edmunds
.Edmunds
YES : this is the one I used for #35Found a very good writeup on magnetometer+accelerometer implementation. Not on the manufacturers website anymore, so download to your computer if interested
Edmunds
No need for that if magnetometer is strictly horizontal.
Oh, boy. I have been struggling with heading not related issues now for quite some time. Had not reflow soldered and more importantly applied solder paste by hand for tiny things for a while and the skill has left me. Tried two boards and none was good. The components are kind of too close to each other to re-work easily and then I ran out of parts. This is what happens to the projects of this complexity. It is sometimes harder to get to solving the problem than solving it .
Anyway, with missing parts on order and with some discretionary time I browsed some more for what solutions are out there. I stumbled across this - 1.6x1.6x0.5mm sensor fusion co-processor that runs at 1/10th of power of most powerful enough processors for the task. It is available on a module like this, as well. The module claims to achieve 2 degree RMS heading error.
I have also come across Maxim Integrated MAX21100, but sadly it is out of production.
The benefit of the above solutions is no software to mess with. The down-side, of course, is you are dependent on yet another black box in your project. However, if I can get a heading with error below something I will ever be able to produce with picaxe and in ~3mm2 of board space including passives, I confess, I would give up on picaxe for the task. How can one obtain the SENtral thing is, however, a mystery for now.
Then there is LIS331EB from ST - an ARM processor with accelerometer built in. The bad thing with this is that you have to install the firmware yourself, but it seems to be available. Feels a bit like Arduino, though, where you compile God knows what and hope that it will work and most of the times it does, but if it does not you are stuck with trying to find bugs in code you have not written.
Finally, there is this company with sensor fusion chip that is basically a cortex something processor. Same story as above, but I get less of an impression there is easily available firmware to just install. It sounds more like we have a nice chip you can develop your software on.
Edmunds
.Anyway, with missing parts on order and with some discretionary time I browsed some more for what solutions are out there. I stumbled across this - 1.6x1.6x0.5mm sensor fusion co-processor that runs at 1/10th of power of most powerful enough processors for the task. It is available on a module like this, as well. The module claims to achieve 2 degree RMS heading error.
I have also come across Maxim Integrated MAX21100, but sadly it is out of production.
The benefit of the above solutions is no software to mess with. The down-side, of course, is you are dependent on yet another black box in your project. However, if I can get a heading with error below something I will ever be able to produce with picaxe and in ~3mm2 of board space including passives, I confess, I would give up on picaxe for the task
. How can one obtain the SENtral thing is, however, a mystery for now.Then there is LIS331EB from ST - an ARM processor with accelerometer built in. The bad thing with this is that you have to install the firmware yourself, but it seems to be available. Feels a bit like Arduino, though, where you compile God knows what and hope that it will work and most of the times it does, but if it does not you are stuck with trying to find bugs in code you have not written.
Finally, there is this company with sensor fusion chip that is basically a cortex something processor. Same story as above, but I get less of an impression there is easily available firmware to just install. It sounds more like we have a nice chip you can develop your software on.
Edmunds
Last edited:
I found the company with tiny fusion processor also have these cool 'geomagnetic sensors'. Very interesting stuff. Seems like you need to use their 'magic' IC to run them, but seem very interesting. Data sheet available here.
Edmunds
Edmunds
Last edited:
Did you also find price list ?Oh, boy. I have been struggling with heading not related issues now for quite some time. Had not reflow soldered and more importantly applied solder paste by hand for tiny things for a while and the skill has left me. Tried two boards and none was good. The components are kind of too close to each other to re-work easily and then I ran out of parts. This is what happens to the projects of this complexity. It is sometimes harder to get to solving the problem than solving it
Anyway, with missing parts on order and with some discretionary time I browsed some more for what solutions are out there. I stumbled across this - 1.6x1.6x0.5mm sensor fusion co-processor that runs at 1/10th of power of most powerful enough processors for the task. It is available on a module like this, as well. The module claims to achieve 2 degree RMS heading error.
I have also come across Maxim Integrated MAX21100, but sadly it is out of production.
The benefit of the above solutions is no software to mess with. The down-side, of course, is you are dependent on yet another black box in your project. However, if I can get a heading with error below something I will ever be able to produce with picaxe and in ~3mm2 of board space including passives, I confess, I would give up on picaxe for the task
Then there is LIS331EB from ST - an ARM processor with accelerometer built in. The bad thing with this is that you have to install the firmware yourself, but it seems to be available. Feels a bit like Arduino, though, where you compile God knows what and hope that it will work and most of the times it does, but if it does not you are stuck with trying to find bugs in code you have not written.
Finally, there is this company with sensor fusion chip that is basically a cortex something processor. Same story as above, but I get less of an impression there is easily available firmware to just install. It sounds more like we have a nice chip you can develop your software on.
Edmunds
Buzby
Senior Member
If you need to ask the price you can't afford it !.
The module with all the sensors and the sensor fusion processor was about 18USD somewhere. I cannot find that price anymore, but I'm talking to a representative of the producer, so I will find out soon. 18USD retail would be acceptable for my project if that would be a price to pay for solving the navigation problem
. But I believe the module would not work for me. The same reason I did not choose integrated 9DOF thing, but took 6DOF with magnetometer option - most of the board space I have is too close to wireless charging and main engine. The same goes for rotational axes of the car, which is the rear axle - I understand this is the best place for magnetometer, but I would probably have to take it elsewhere because of hard iron effects.Edmunds
Buzby
Senior Member
I must have been looking at the wrong magnetometer .....
https://www.pnicorp.com/product/targetpoint-dmc/
https://www.pnicorp.com/product/targetpoint-dmc/
Back in business
Finally. I have put together a decent test platform for further development that is happily repeating the line follower achievements. I now have three 40X2 working together to make this work:
1. The main processor, currently doing nothing, but a single HPWM command to run the main DC motor at desired speed. The interesting part from that is, I got the half-bridge HPWM mode working (through DRV8837). I do hope for that long, long, long promised manual from RevEd to come out one day, but in the meantime I did what I could with Microchip data sheet, other papers mentioned in posts of this forum and some educated guesswork. The one thing I can say about this is that if you want to maximise torque of your DC motor, this is probably the way to go. More to do with fine tuning the frequency and dead band delay to suit my motor best at some point.
2. The so called [and well known to frequent visitors of this forum] - steering co-processor. Handling the line following and physically steering stepper motor driven front wheels (through STSPIN220). My Murata LXDC2HN switching regulator [tiny, take a look at it by all means if you fancy tiny stuff] was not up to the task of supplying the current required, so the front of the car is running directly off the battery. Not good, but will do for now.
The above are connected with hserout and hserin pins respectively, so they should be able to talk with very little overhead.
3. A system state co-processor (cool name, ha?) running the tiny I2C 'dummy' [as per other recent thread] screen. I have not yet figured out how to talk to this one. I guess serout will have to do or I will do something tricky with some I2C multiplexer/separator chips I have somewhere in the drawer. This guy could be I2C slave, but then it has to be a master to run the display and that introduces two masters, which is probably not a very good idea.
I have a main switch, battery charging connector [so I don't have to take it out every time], two pushbuttons and three LEDs that I can use for anything on the main processor as well as our old friend 8 x LED indicator connected to the steering co-processor. I have also routed most of available main processor pins to the back of the car, so extra functions can be set up.
Lights and obstacle avoidance not there, would take another day, not a priority right now.
Will add pictures later as the forum does not seem happy to get any at this day and hour. Will dive into the magnetometer now.
Have a good weekend,
Edmunds
Finally. I have put together a decent test platform for further development that is happily repeating the line follower achievements. I now have three 40X2 working together to make this work:
1. The main processor, currently doing nothing, but a single HPWM command to run the main DC motor at desired speed. The interesting part from that is, I got the half-bridge HPWM mode working (through DRV8837). I do hope for that long, long, long promised manual from RevEd to come out one day, but in the meantime I did what I could with Microchip data sheet, other papers mentioned in posts of this forum and some educated guesswork. The one thing I can say about this is that if you want to maximise torque of your DC motor, this is probably the way to go. More to do with fine tuning the frequency and dead band delay to suit my motor best at some point.
2. The so called [and well known to frequent visitors of this forum] - steering co-processor. Handling the line following and physically steering stepper motor driven front wheels (through STSPIN220). My Murata LXDC2HN switching regulator [tiny, take a look at it by all means if you fancy tiny stuff] was not up to the task of supplying the current required, so the front of the car is running directly off the battery. Not good, but will do for now.
The above are connected with hserout and hserin pins respectively, so they should be able to talk with very little overhead.
3. A system state co-processor (cool name, ha?) running the tiny I2C 'dummy' [as per other recent thread] screen. I have not yet figured out how to talk to this one. I guess serout will have to do or I will do something tricky with some I2C multiplexer/separator chips I have somewhere in the drawer. This guy could be I2C slave, but then it has to be a master to run the display and that introduces two masters, which is probably not a very good idea.
I have a main switch, battery charging connector [so I don't have to take it out every time], two pushbuttons and three LEDs that I can use for anything on the main processor as well as our old friend 8 x LED indicator connected to the steering co-processor. I have also routed most of available main processor pins to the back of the car, so extra functions can be set up.
Lights and obstacle avoidance not there, would take another day, not a priority right now.
Will add pictures later as the forum does not seem happy to get any at this day and hour. Will dive into the magnetometer now.
Have a good weekend,
Edmunds
Ahh. There was one more improvement.
I noticed the car would handle superbly under low light conditions when reading the line. Much more stable operation and not loosing the line ever. Never.
I thought, while I don't have the time to play with pinhole camera idea, some sunglasses could help. I added a piece of red transparent film over the sensor and boy it did help! I basically have the same superb low light performance in full sunlight (still indoors). I had to double the power to the sensor illumination LEDs for this to work.
What this proves is, that there is room for simple improvements. I could try thicker (double?) the film and different colours - I have green, blue and brown right here, but others are available, too, of course.
Edmunds
I noticed the car would handle superbly under low light conditions when reading the line. Much more stable operation and not loosing the line ever. Never.
I thought, while I don't have the time to play with pinhole camera idea, some sunglasses could help. I added a piece of red transparent film over the sensor and boy it did help! I basically have the same superb low light performance in full sunlight (still indoors). I had to double the power to the sensor illumination LEDs for this to work.
What this proves is, that there is room for simple improvements. I could try thicker (double?) the film and different colours - I have green, blue and brown right here, but others are available, too, of course.
Edmunds
