Wanted to evaluate two common 6DoF sensors for use on the Inqster. Here is my summary.
@inq Thats a nice comparison report, but won't you need a 9 axis mpu for the magnetometer if you are going to use GPS for navigation?
@inq Thats a nice comparison report, but won't you need a 9 axis mpu for the magnetometer if you are going to use GPS for navigation?
InqEgg had a magnetometer on it and all the motor stuff going on near it made it near useless.
But, I'm not sure I follow you. I've played around with a GPS receiver on the ESP32. It tells you where on Earth you are. It'll even tell you direction if you're moving, but a magnetometry isn't needed in addition to it.
I might need the magnetometry if I do inertial navigation.
@inq I was thinking along the lines of the way I used a magnetometer to navigate which was to have a lat/lon destination coordinates for the bot to navigate to, find the current coordinates from the GPS and calculate the angle in degrees from the current position to the destination. Then using the magnetometer readings, adjust the steering to set the bot trundling along the correct compass bearing.
When I last played with this, about a couple of years ago, my bot was tending to go in a meandering fashion towards its destination rather than straight as an arrow type of course. Of course being tossed about by the lumps and bumps of the ground it's to be expected, but I also thought the bots skid steering was some of the reason plus the magnetometer I was using, an mpu9250, where, probably due to my fusion code to adjust the compass bearing according to the tilt and yaw, the compass readings were a bit wayward.
I decided I would try again with a front wheeled steering bot, probably by modifying a RC model car, and recently @lee-g put me on to the bno055 9DoF sensor where the sensor calculates the fusion for itself and the magnetometer readings are very stable. I put some remarks and a short video on this on his My first robot thread.
However I take your point that the bearing the bot is currently traversing can be calculated from the GPS readings which may be good enough possibly depending on how tightly one is intending the bot to follow along a route. I think I will get around to giving this a trial and comparing to the magnetometer navigation.
I will probably get a suitable bot chassis later this year when I have a bit more time and start my bot adventures again.
@inq I was thinking along the lines of the way I used a magnetometer to navigate which was to have a lat/lon destination coordinates for the bot to navigate to
Oh! You mean old school... 🤣 triangulate two mountains to find where you are and take a strait line to... I think the pub is that'a'way!
I put some remarks and a short video on this on his My first robot thread.
A link would be incredibly nice. I think I had a 9DoF on InqEgg, but it seemed like I only used them independently. Didn't know that they'd auto correct each other! But as I mentioned earlier... I think it left home for greener pastures.
I will probably get a suitable bot chassis later this year when I have a bit more time and start my bot adventures again.
Cool, always great to have company during the highs and lows.
Inq
A link would be incredibly nice.
https://forum.dronebotworkshop.com/postid/52798/
https://forum.dronebotworkshop.com/postid/52830/
https://forum.dronebotworkshop.com/postid/52833/
rgs Mr Nice Guy. 😎
-
There is the Evolution class. This is generalized for any type of AI problem. Its only limitations would be defined by how much memory a computer (or microcontroller) has. It contains the ability to do the Genetic Evolution on a problem and run the Genome. I'll be porting this to C++ to also run on Inqster so that it can learn on its own.
-
There is the Inqster0 class. This inherits (OOP - Object Oriented Programming term) the Evolution class to define a specific problem. Obviously, this is for the first generation of Inqster. It contains the Physics of a self-balancing robot using an Inverted Pendulum.
-
The last part is the program wrapping those up, slapping a GUI so I can watch it learn. I want to eventually try to generalize it so it can be used for more than just Inqster.
-
I've used the Standard Deviation data from the https://forum.dronebotworkshop.com/electronic-components/comparing-lsm6dsv-vs-mpu6050-gyroscope-accelerometers/ to incorporate some noise into the simulated data used in the input for the Inference.
-
As part of the Genetic Evolution process, it supplies a Genome (a bunch of matrices). The Inqster0 class takes those, applies simulated sensor data, runs the Inference and gets the results that would be sent to the motors. It is up to the class to score those results. Setting up the scoring is one of the more subjective aspects of Genetic Evolution. I'm not sure if I'm there yet. As I get more experience watching the evolutions, I make tweaks to the scoring routine. For instance, these might sound logical to use:
-
The score gets bigger, the longer it doesn't fall over or doesn't travel too far from its starting point.
-
If it falls over say 45 degrees, or travels over the preset limit, its time stops.
-
If it tries to use more acceleration than I think the motors can provide or the surface doesn't slip, it is rejected.
-
The score is reduced by how far it does travel away from the starting point.
-
The score is further reduced by how much it travels moving. IOW if it doesn't travel away from the starting point, but rocks back and forth; it gets penalized.
-
-
Early on, I was letting it start from a perfectly balanced (upright) position. I noted a distinct, one-sided preference... always falling backwards or running off in the negative direction. I changed the Activation function and substituted two distinct starting points - one starting from 20 degrees off-center and -20 degrees off-center. These seem to clear any one-sided preferences.
-
Evaluated 385k Genomes
-
Rejected 225k Genomes
-
Found 160k Genomes
-
The best 100 are displayed for inspection visually.
-
To run the program: Menu - Run, Evolve (or simply press F5)
-
The list of Genomes (green arrow) is filled out during the analysis. It only shows you ones that are better than the last one by the score in the right column. Once the entire analysis is complete, it will sift through all the Genomes (16,000) and find the best 100. These are then displayed ready for viewing. The Run column has three numbers:
-
Describes the computer thread that found that Genome
- Which generation found the Genome (1 to 100)
- Which Genome of the Population (1 to 100)
-
-
Some settings (red arrow)
-
The first is the number of cores of your computer to use. I should warn you, the more you use up to the maximum, will run your computer harder and up to 100%. The computer will still remain useful, but it will probably crank up your fan! It defaults to one thread, which is the slowest.
-
Delay - 1 ms is the time between frames and is about real-time, 0 zips through animations very fast and greater than 1, is slow-motion.
-
The next three are:
-
Auto Play - play the best Genome while they're being generated.
-
Play - (if Auto Play is turned off) will allow you to play any Genome by selecting it and hitting play or simply double-click a Genome. You can do this while they are being generated or after its done.
-
Replay - I don't think this is working yet?
-
-
-
While running, the status (yellow arrow) is updated. Mouse hover over will tell which is which:
-
Number of generations
-
Number reject because identical to one previously used
-
Rejects
-
Total number evaluated
-
Inq
Attachment:
Last week, I rolled my office chair back and I heard a crunch. @)($%, $#)), *(!&#!!!! Sailors would cringe. I busted one of the wheels on the mule. As, those were my old school's colors and with the thought Inqster will trudge around with me on campus, I decided I'll go ahead and make some new shoes. The old ones also were made to get good grip in grass, hills, gravel and mud. Where as now, I'm thinking Inqster will be a University traveler seeing concrete walkways and smooth floors, I thing a new tire design is in order. Oh, and my new school colors are Purple and Gold. Eeeh-gads!
I finished the wheel design in CAD, exported the 3D models and did the same with the tire. Stupid me, I hadn't saved the tire CAD model when the power went out! Another few choice words. But I've printed both and the exports are good and didn't need modifications... Wheew!
They're still 200 mm OD, but a little narrower (25mm) than the old ones. Wheels are ABS and tires are TPU.
Inq


