Help storing data from external sensors in memory. Please.

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, I'd like to preface this by saying I was woefully underprepared for this, so if I sound inexperienced or stupid, it's because I am both these things.

 

With that being said, I'm working on a College Senior Project, a module to modify a lawnmower to be able to mime a route that it's been taken on. I selected an ATxmega256A3BU to serve as the brain of this project, and nearly everything is working, except for one big component.

 

The intent is for the mower to be taught the route by physically taking it on the route the user wishes for it to learn. The system, using five Reed switches per side, records how many times the drive wheels on the treads mounted to the mower spin, what direction they're turning, and what the "sequence" is. This is supplemented by data from an MPU-6050 Gyroscope module, which takes note of the mower's orientation at every "tick" from the Reed Switches. When the system is set to follow the recorded route, it mimics the movement of the wheels, while also using the Gyroscope data to correct itself should it turn off track. I have all of the components communicating, and I only have one issue remaining before the code is complete and I can finally sleep at night. I'm not sure how to go about storing the data gathered by the system, or if it's even possible to do what I'm wanting it to do. The idea was that every so many "ticks" from the Reed switches would cause the information to be stored in memory, in an arrangement that's something like this.

 

(Tick number, Left wheel forward rotations, left wheel backwards rotations, right wheel forward rotations, right wheel backwards rotations, Gyroscope data)

 

When the mower is following the route, it checks it's current readings against those in memory at every tick, and corrects itself if it's gone off course. The problem is that I'm not sure on how to go about getting the values into memory. I've been going  through as much information as I can find, and I'm not sure if EEPROM or Flash Memory should be used, if I need an external memory device, what format I should store the data in, how many ticks of the Reed Switch should occur before it stores the data, or if any of this is even remotely possible.

 

I'm using Microchip Studio to program this, which I'm also very new to. I have read all the datasheets I could find, but I've been learning all of this material at a fairly breakneck pace, so the chances of me having missed something are decent. All of the actual physical design choices are, unfortunately, set in stone, so I cannot use a GPS module, rotary encoder, or anything else to replace an existing component I've mentioned. Any insight on to what I should do to get this all working would be deeply appreciated.

OK, but why though?

Last Edited: Mon. May 3, 2021 - 04:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greetings and Welcome to AVR Freaks ...

 

Sounds like an interesting project!

 

It is quite possible to use EEPROM. You DO have one of those "write rarely, read often" applications. Check the EEPROM block read/write/update functions in AVRLibC. The only question is whether or not the EEPROM is large enough to store the counts between waypoints. XMega256 has bigger than average EEPROM, so it might work.

 

Don't see any reason why there would be anything wrong with storing raw counts. Saves a lot of data manipulation.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As Jim said the EEPROM is certainly one way to do it. 

 

If the on board EEPROM is not large enough there are external EEPROM that use either I2C or SPI for communications.

 

Most of the ones I've used require the user to write entire blocks at one time so you could cache the data until you get enough to write a block the write it out and do it again.

Same way on reading, read a block at a time.

 

BTW Welcome and good luck

Happy Trails,

Mike

JaxCoder.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you both very much for your input. The root of quite a few of my problems also became quite clear, as I don't believe I've had the AVRLibC files set up, which explains my code looked different from everything I was seeing online. Is there any site or documentation with somewhat more concise instructions for installing the AVRLibC files? Everything I'm seeing looks a bit overwhelming. Though, that may just be because I'm quite tired.

OK, but why though?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Its pretty straight forward, really.

 

1. You can start with the documentation here:    https://onlinedocs.microchip.com...

 

2. Open the Library Reference section.

 

3. There you will find a iist of libraries. For example, one says: <avr/eeprom.h>: EEPROM handling   This looks like it might be useful for your application so click it to open. There you will find some notes pertinent to that topic, and IAR compatibility link, a Functions link and a Defines link. The functions part simply lists all of the functions in that library and their prototypes. The Defines section tells more about how the functions are to be used.

 

4. To use this particular library, write #include <avr/eeprom.h> near the top of the file that is going to use these functions. Every file that is going to use one of these eeprom functions needs its own #include ... statement. Be careful because some are <avr/... while others are just <... and some are <util/...

 

5. Then, at the appropriate point in your program, just write the function name and the appropriate arguments. Thats all it takes!

 

Jim

 

 

 

 

 

 

 

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Sun. May 2, 2021 - 11:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Would there be a chance you or anyone else here would be able to give me an idea of what that would look like? I believe creating a Struct with all the information may make storing it into memory an easier affair, but would I have to create a new Struct for every tick or could I use the same one? Is Struct even a decent option, or am I entirely looking at the wrong things? Is there any particular metaphorical rakes I'm about to walk into from using the EEPROM, keeping in mind my utter lack of experience?

 

I've also seen documentation about having to use a Non-Volatile Memory Controller, and I have no idea if that's outdated information, or even where to begin with any of this.

 

I don't mean to sound whiny, and I apologize if I do, but this has been completely overwhelming in every way, since it's on rather short notice.

OK, but why though?

Last Edited: Mon. May 3, 2021 - 04:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Phoenix4545 wrote:
but would I have to create a new Struct for every tick or could I use the same one? Is Struct even a decent option,

A struct is absolutely the right way to go. - You are storing various related items of data collected at a "wheel tick".

 

  • You would store these items of data together in a struct.
  • You would store an array of these structs in EEPROM as a definition of your "mowing route".

 

NB: You will need some method of determining when you've reached the end of the route.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Before worrying about low-level implementation details like EEPROM, do you have a high-level design for how this is going to work?

 

It might be a better idea to get the "teach & repeat" working first, then add the non-volatile storage later? That way, you will have something working to demonstrate - even if you don't (quite) finish the EEPROM part.

You can have a "future enhancements" section in your project report ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, I thought I did. And then I realized it wouldn't work. So, I guess I should also ask how to get my array of five reed sensors per wheel to track the direction that the wheel is rotating, and how many times it does so. My assumption is that it's a series of statements that sorts out direction by the sequence in which they go off, but what would that actually be as far as code? I assumed it would be a number of else if or a switch statement, but is there a way of doing that without constructing some monstrous behemoth of code?

OK, but why though?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cool project.

I think, however, there is actually a lot to this project.

Do you have the drive capability already sorted out, so that you can control the R & L drive motors?

 

There are lots of ways to skin a cat...

One of the first approaches for reading the drive signals that comes to mind would be along this line:

Have a state machine and some counters in software.

You din't describe your HW in much detail, but you might typically have two sensors to read the reeds, as it were.

(You have 5 magnets on the wheel, and two reed sensors on the frame)

 

In SW, if sensor A fires, then sensor B fires, you know the wheel is moving forward.

And for every move forward you increment your moved forward X tics counter.

If you get a forward tic, forward tic, forward tic, and then all of a sudden you get two Sensor Bs in a row, you know it moved backwards.

While moving backwards you wil have sensor B firing, then A, repeat, repeat...

You tallie your backwards tics.

 

You might well have a running position counter, that increments for forward tics, and decrements for backward tics, so you know your distance fromt he starting point, for that leg of the overall path.

 

You need a pencil and paper to work out the state machine.

There are some interesting inbetween states, do tho the physical dimensions of the system and the sensor.

i.e. Sensor A fires, then B, (moving forward); (repeat a few times), now B fires, so it appears to be moving backwards.

But, what if it now Fires A again?   (AB, AB, AB, B, B, AB, AB...)

The User can chnage direction any time they wish...

 

Once you work out the logic for the R wheel, you simply duplicate if for the L wheel.

 

Then you work on the higher level of decision making.

For the learning, you are simply storing the data.

For the mow it robotically mode, you are interpretting where you are on the path, and where you need to be, and what your drive commands need to be.

(A lot like a line following robot, except your desired position info comes from the stored path, not from the line reader/sensor.)

 

Have you learned about debouncing push button switches?

 

You will need to "debounce" your reed switch signals, both because they might/will bounce, (0 - 40-ish mSec time frame), and because in the real world the wheel could be sitting right on the edge of tripping the reed, or not, as the human stops, starts, turns, etc.

So will will need a longer gap  from when a sensor trips, to when you acknowledge a sequential tripping of the same sensor, (without the other one having fired inbetween).

 

If you have a team working on this project, then perhaps group 1 works on the above, reading the sensors, reliably, and hence being able to provide a Forward / Backward tic to the higher levels.

Group 2 can assume they have that info, (e.g. a flag being set every now and then, or just watching the counters for changes), and work on the higher level intelligence for the mower.

 

Good luck with your project.

 

JC

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I would be really careful about saving more to the EEPROM than you need to, more often than you need to. For example, doing something every tick probably is not necessary. What will really matter is the total number along each discrete motion path. So, you can accumulate those, then only write when a path change occurs.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

Your project reminds me of something I read many years ago in Popular Electronics for building a robotic lawn mower.

 

Just some thoughts on your idea of counting the number of revolutions per wheel in order to determine when to turn etc.

 

unless the surface is perfectly flat, and the 'tick's come in exactly at the same time EVERY time, you will not get repeatability.  The outside wheels on a  turn will rotate more than the ones on teh inside of the turn.  Terrain will also affect how many revolutions you will see as well.

 

To fix this I would add a GPS module and build a 'teaching pendant'.  THE pendant would have left right, forward reverse buttons where you would use them to position the mower where you want it to stop, then using the pendant, 'turn' the mower, and store the GPS location.  Keep doing this for every point. and then when you are back at the start point press a button to signal the 'END' of the mowing pattern.  in your code you would tell the AVR to constantly red the GPS and have a tolerance of deviation between points the mower can move left or right to keep it straight.

 

Much easier, and more accurate than counting revolutions on a wheel that will never give the same readings twice in real life.

 

Also, there are many robotic lawnmowers on the market already, might want to do some reading on how they do it and see if oyu can 'learn' a few things to implement into your own.

 

Cheers,

Right Side Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
To fix this I would add a GPS module ...
better is GNSS with RTK as GNSS will have variable absolute error that can be corrected to a much lesser relative error.

Aftter a surveyor measures a house lot, there will be fiducial marks in the street (curb-to-curb) with the lot's marks relative to the fiducial marks; street is reference in a plat.

Could place GNSS+RTK on one of the lot's fence posts then transmit corrections to the lawn mower's GNSS receiver.

Lawn mower shall avoid some easements; one easement is the sidewalk due to right-of-way.

jgmdesign wrote:
Also, there are many robotic lawnmowers on the market already, ...
Likewise with tractors; a tractor's operator stays clear of easements, water wells, oil wells, poor soils, excessive slopes, etc.

 


fiducial - Wiktionary

OpenRTK Developer Manual — Aceinna OpenRTK Developer Manual documentation

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
unless the surface is perfectly flat...

Indeed; and many other real-life considerations - such as no wheel slip, exactly identical wheel diameters, etc, etc, ...

 

I think you really should be discussing these points with your teacher / project supervisor ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Phoenix4545 wrote:
Would there be a chance you or anyone else here would be able to give me an idea of what that would look like?
Just checking but have you read this in the Tutorial Forum?

 

https://www.avrfreaks.net/forum/...