Once again, Aftershock is working hard to make videos and explanations of what we are doing, especially early in the year. We hope to share as much as possible with as many teams as possible (mainly on our YouTube channel), so don’t forget to subscribe if you haven’t already!
Awesome! Yeah I have been working on some similar code, but I find it drifts WAY to much. Despite my various attempts at compensating for this drift I have yet to find a solution that works really well. Anyway, are you using any GYROs or Accelerometers? How are you compensating for drift? Will your measurements be thrown way off if your hit by another robot?
P.S. would love to see that code, even if its not finished…
What do you mean by actual movement? say you are shoved in the side where none of your motors are moving (unless your using an H drive?). Your measurement will then be off because your motors couldn’t move and you will be in a different position when resuming your measurements. Therefore your measurements will be off, right?
I too have heard this, a few days ago I found an accelerometer in the deep dark depths of my teams supplies and I am interested to see just how inaccurate it really is. I also want to look at implementing a kalman filter as well as some high and low pass filters to see if that will help in any significant way.
Our sensor setup is independent of our drive setup, which allows for mechanical errors such as slippage, getting shoved, etc. I am fascinated by the concept of a kalman filter, but I have no idea how to implement one as of now. Guess that’s what Google and Wikipedia are for
The main idea of kalman filtering is really just a weighted average. The trick is that you change the weighting of each sensor(how much you trust each one) based off of how accurate the sensor was during the last cycle. This means that inherently the sum of the sensors is always better than either individually. If one sensor is just utter trash and the other is really good the filter will naturally trust the good sensor a lot more but still use the trash data to get something better than just the good sensor alone.
Several Gyros with a lot of drift each could be interesting to apply a Kalman filter on.
If you want to see examples of applying this concept in ROBOTC you can take a peak at BNS lib.
I Toyed with the using multiple gyros for position tracking last year, the problem is when you have 1 gyro at 359 degrees and on at 1 degrees, then you average to somewhere near 180, when you want it to be at 360, and I never thought of a way around it
I have never programmed multiple gyros but I think that you could have an if statement that says “if gyro1>350 && gyro2<10 then gyro2 += 360” so that 360 and 1 would average out at 360.5. Then you can say “if angle>360 then angle -= 360” to get 0.5.
Have a look at the old gyro library I released a few years back. One feature was tracking the absolute value of the gyro, it would continue to accumulate an angle once you passed 360 deg. So in your example one gyro may be at 359 degrees while the other would be at 361 degrees, the average would be 360.