Inqster - The re-Aw...
 
Notifications
Clear all

Inqster - The re-Awakening

53 Posts
5 Users
20 Reactions
2,472 Views
Inq
 Inq
(@inq)
Rocket Scientist or Space Cadet
Joined: 5 years ago
Posts: 2071
Topic starter  

Wanted to evaluate two common 6DoF sensors for use on the Inqster.  Here is my summary.

https://forum.dronebotworkshop.com/electronic-components/comparing-lsm6dsv-vs-mpu6050-gyroscope-accelerometers/  



   
ReplyQuote
byron
(@byron)
No Title
Joined: 7 years ago
Posts: 1283
 

@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?



   
ReplyQuote
Inq
 Inq
(@inq)
Rocket Scientist or Space Cadet
Joined: 5 years ago
Posts: 2071
Topic starter  

Posted by: @byron
↑

@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.

 

 



   
ReplyQuote
byron
(@byron)
No Title
Joined: 7 years ago
Posts: 1283
 

@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.



   
Lee G reacted
ReplyQuote
Inq
 Inq
(@inq)
Rocket Scientist or Space Cadet
Joined: 5 years ago
Posts: 2071
Topic starter  

Posted by: @byron
↑

@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!

 

Posted by: @byron
↑

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.

Posted by: @byron
↑

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



   
ReplyQuote
byron
(@byron)
No Title
Joined: 7 years ago
Posts: 1283
 

Posted by: @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. 😎 



   
Inq reacted
ReplyQuote
Inq
 Inq
(@inq)
Rocket Scientist or Space Cadet
Joined: 5 years ago
Posts: 2071
Topic starter  
Progress on Design
 
I want to keep the other topic about the understanding and implementation of Neural Networks and using Genetic Evolution to derive the Neural Network.  This topic is about the development of the Inqster.  There are three distinct parts of the Evolution C# program.  I won't clutter this up with defining the terms used.  I've attempted to use industry standard terms so you can Google them or see them in the other topic.
 
  • 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 have been refining the Inqster0 class in an attempt to model the real world as best I can and build in as much robustness to the end Genome so that it can recover from any discrepancy between the Physics and mechanical reality.  Here are some of things that have changed or enhanced:
 
  1. 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.
  2. 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:
    1. The score gets bigger, the longer it doesn't fall over or doesn't travel too far from its starting point.
    2. If it falls over say 45 degrees, or travels over the preset limit, its time stops.
    3. If it tries to use more acceleration than I think the motors can provide or the surface doesn't slip, it is rejected.
    4. The score is reduced by how far it does travel away from the starting point.
    5. 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.
  3. 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.
 
 
Here is the latest run of the Evolution program on the Inqster0 model.  It's a pretty boring 5 minutes...
 
Summary
  • Evaluated 385k Genomes
  • Rejected 225k Genomes
  • Found 160k Genomes
  • The best 100 are displayed for inspection visually.
 
If anyone is interested, I'm supplying the executable here.  I'd appreciate any feedback if you have a problem running it.  It does not have an install program, you can simply unzip it in a directory and run it.  I'm guessing, it'll prompt you - complaining, do you trust the source?  That's up to you.  It only runs on Windows.  I built it on a Windows 11 box and tested it on Windows 10.  Windows installs some run time libraries by default, but if you don't have the latest, it might prompt you to update.  I believe it'll automatically detect and ask for your permission.  Again, I would appreciate hearing if it does that for you.  
 
image
Here are the hi-lights of the program:
  • 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:

 

 



   
Lee G reacted
ReplyQuote
Inq
 Inq
(@inq)
Rocket Scientist or Space Cadet
Joined: 5 years ago
Posts: 2071
Topic starter  

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.

Wheel
image

 

Inq



   
DaveE reacted
ReplyQuote
Page 4 / 4