storing data from sensors

I want to get this information and transmit wirelessly using Xbee's

You already have an array that contains the data. Why do you need to copy it somewhere else?

Transmitting data wirelessly or wired is exactly the same from the Arduino's point of view. It doesn't know that the pins it is wiggling are connected to a USB to serial chip or to an XBee via a shield. The pins are wiggled exactly the same way. Sometimes it matters which pins are wiggled, and whether the HardwareSerial class or the SoftwareSerial class is doing the wiggling.

You already have an array that contains the data. Why do you need to copy it somewhere else?

I don't want to send just one array, I am getting a lot of information from the sensors and I want to send all of it

I don't want to send just one array, I am getting a lot of information from the sensors and I want to send all of it

You get some data. You store the data in an array as you get it. When you have all of it, you start over getting more.

Once you have an array full of data, send that array, and then start over.

You get some data. You store the data in an array as you get it. When you have all of it, you start over getting more.

Once you have an array full of data, send that array, and then start over.

I don't know if this would work in my case because I want the car to go all the way in the path and then send the data. And then I want another car to read this data and go through the same path, and I don't think the arduino would have memory enough to store all this data.
I bought a sd shield to store all these arrays in a sd card, but I am having difficulties in doing so. This is the code that the arduino IDE has as example to read and write something in a card

/*
  SD card read/write
 
 This example shows how to read and write data to and from an SD card file 	
 The circuit:
 * SD card attached to SPI bus as follows:
 ** MOSI - pin 11
 ** MISO - pin 12
 ** CLK - pin 13
 ** CS - pin 4
 
 created   Nov 2010
 by David A. Mellis
 modified 9 Apr 2012
 by Tom Igoe
 
 This example code is in the public domain.
 	 
 */
 
#include <SD.h>

File myFile;

void setup()
{
 // Open serial communications and wait for port to open:
  Serial.begin(9600);
   while (!Serial) {
    ; // wait for serial port to connect. Needed for Leonardo only
  }


  Serial.print("Initializing SD card...");
  // On the Ethernet Shield, CS is pin 4. It's set as an output by default.
  // Note that even if it's not used as the CS pin, the hardware SS pin 
  // (10 on most Arduino boards, 53 on the Mega) must be left as an output 
  // or the SD library functions will not work. 
   pinMode(10, OUTPUT);
   
  if (!SD.begin(4)) {
    Serial.println("initialization failed!");
    return;
  }
  Serial.println("initialization done.");
  
  // open the file. note that only one file can be open at a time,
  // so you have to close this one before opening another.
  myFile = SD.open("test.txt", FILE_WRITE);
  
  // if the file opened okay, write to it:
  if (myFile) {
    Serial.print("Writing to test.txt...");
    myFile.println("testing 1, 2, 3.");
	// close the file:
    myFile.close();
    Serial.println("done.");
  } else {
    // if the file didn't open, print an error:
    Serial.println("error opening test.txt");
  }
  
  // re-open the file for reading:
  myFile = SD.open("test.txt");
  if (myFile) {
    Serial.println("test.txt:");
    
    // read from the file until there's nothing else in it:
    while (myFile.available()) {
    	Serial.write(myFile.read());
    }
    // close the file:
    myFile.close();
  } else {
  	// if the file didn't open, print an error:
    Serial.println("error opening test.txt");
  }
}

void loop()
{
	// nothing happens after setup
}

I ran it and works fine. but how where do I put my code so it stores the array that I am generating?
Again this is how I am getting the values from the sensors

int ping(int j) {
  int duration, distance;
  pinMode (trigPin[j], OUTPUT);
  pinMode (echoPin[j], INPUT);
  digitalWrite(trigPin[j], LOW);
  digitalWrite(trigPin[j], HIGH);
  duration = pulseIn(echoPin[j], HIGH);
  distance = (duration/2) / 29.1;
  return distance;
}
void loop(){
  int minimum, Position, distance[3], j;
  for (i=0; i<3; i++){
  distance[i]=ping(i);
  delay (35);
  
  }

victorfb:

Two important questions are:
How many values do you want to store?
What are you going to do with the stored values?

The answers to these questions will determine what options are sensible for storing them.

I want to get this information and transmit wirelessly using Xbee's

You didn't answer the first question.

You didn't answer the first question.

I don't know how many values will be stored, it will depend on how long is the path that the car that has the sensors will pass. I imagine will be a lot of values since I have a sensor reading every 35ms

victorfb:

You didn't answer the first question.

I don't know how many values will be stored, it will depend on how long is the path that the car that has the sensors will pass. I imagine will be a lot of values since I have a sensor reading every 35ms

You need to know the answer to this question. If you can't produce an exact answer, then work out what would be the upper limit you need to support. Just saying 'a lot' could mean anything from 100 to 100,000,000.

victorfb:

You didn't answer the first question.

I don't know how many values will be stored, it will depend on how long is the path that the car that has the sensors will pass. I imagine will be a lot of values since I have a sensor reading every 35ms

I submit you should just cut to what the real problem is, and forget about answering unanswerable questions, for which you probably already have a solution.

You have already done the bleeding obvious and gotten a SD card module, which probably cost $1.50. In the (highly) unlikely event that the data you need to store doesn't really justify an SD card, then it's still only $1.50, which would be struggling to be 5% of your Arduino investment, and it will do the job anyway. If you have too much data, either get a bigger card or come to terms with the fact that Arduino might be the wrong choice to start with, and it cost you $1.50 to find that out.

I believe the real problem is just a matter of code, not storage. The first bit you attach in reply #12 is simply a one-shot to ensure everything is kosher, but contains the seeds for proper employment. I know nothing about the second bit, I can't even see how you can say it works, but it does, so all you need now is to splice them together.

I know this sounds a bit glib but the Arduino sends information to its various receptors in the same way. The one-shot shows the way

open file
myFile.print(data)
close file

you just need to put it in the loop which, in your code, currently does nothing. So:-

void loop() {

aquire data// tralala
Serial.print(data);

myFile = SD.open("name.txt", FILE_WRITE); //+++++++++++++OPEN

myFile.print(data); // just like serial
myFile.print(" , "); // comma separation

myFile.close();//++++++++++++++++++++++++ CLOSE
}
// and go round again

The file is typically a CSV, i.e. comma separated, suitable for a spreadsheet, which is an array of data, and I guess it is the sort of thing you need.

Is that what you need?

that was what I needed thank you. but now how can I use the values that I stored on the file, I was able to read the files back from the file and now I need to use these values. can I go backwards and read these values 3 by 3 as I was reading from the sensors?

victorfb:
that was what I needed thank you. but now how can I use the values that I stored on the file, I was able to read the files back from the file and now I need to use these values. can I go backwards and read these values 3 by 3 as I was reading from the sensors?

I'm sure the answer is yes, even though I have not progressed far enough myself to be sure I understand the question - particularly the last sentence.

Essentially: no matter what you want to do, if you can see it sensibly, you can use it sensibly. Even if you can't see it sensibly, i.e. just a continuous stream of numbers, it is still possible to use it sensibly but it involves a lot of work you would probably rather not know about.

Sticking with the first, by seeing sensibly, I mean easily understood on the monitor. A properly formed CSV file is formed the same way as a properly formed display on the screen. It can even be exactly the same, whereby the file is derived from the monitor.

So the code in the loop looks like

Serial.print(var1);
myFile.print(var1);
Serial.print(" , ");
myFile.print(" , ");
Serial.print(var2);
myFile.print(var2);
Serial.print(" , ");
myFile.print(" , ");
Serial.print(var3);
myFile.print(var3;
Serial.println(" , ");
myFile.println(" , ");

which gives three columns, one row for each loop. The println at the end is the vital punctuation. You don't actually need the commas in the serial stuff, just the spacing. The commas don't get printed on a spread sheet. They are just signals.

I'm not sure this helps, principally because I'm not sure what you want to do. I'm a newbie too and, at the moment, II don't use the SD to disseminate data, it is just a backup.

NickPyner:
I submit you should just cut to what the real problem is, and forget about answering unanswerable questions, for which you probably already have a solution.

I submit that you need to sort out what data you're dealing with (i.e. the type and quantity) and what you want to do with it, before you design mechanisms to store it. These questions ought to be easy to answer, and if you can't answer them then what hope do you have of choosing the most appropriate design?

what I am doing right now is building a car that goes through a path using 3 ultrasonic sensors and I am storing the values the values the sensors return during the run. I want to use this values on a second car, so essentially the file on the sd card would be the "sensors". Do you think that by running the code that you wrote I will be able to do that?

On the first car, the sensor inputs inform it about the environment. On the second car, the sketch may think it's getting feedback but actually it isn't. If you sketch is intended to respond to the sensor inputs and you want the second car to follow the same path as the first then I suspect that you will get better repeatability by replaying the movements (i.e. the outputs of the control algorithm) rather than the inputs.

victorfb:
what I am doing right now is building a car that goes through a path using 3 ultrasonic sensors and I am storing the values the values the sensors return during the run. I want to use this values on a second car, so essentially the file on the sd card would be the "sensors". Do you think that by running the code that you wrote I will be able to do that?

If you are alluding to what I wrote in #16 and #18 above, then no. It's not code per se, it's just snippets to establish the principle. I'm only talking about storage and I know nothing about robot cars. However, if I understand you correctly, I can't help but agree with the other guy.

Car#1 establishes the course to be steered by feeling its way with sensors.

Car#2 follows the same course without sensors, but using the sensor data from car#1

It would seem more sensible for car#2 to use the mechanical commands that car#1 used to achieve the desired result. That would tell car#2 what to actually do rather than describe the view out the window.

The storage issue is essentially the same - and just as easily solved!

I understand. so how can I store the directions the car took? I use if statements to analyze the values for the sensors for example:

if(sensor on right<20cm)
turnRight()// this is a function of the motor shield

and how can I use the information that I put on the file?

so how can I store the directions the car took?

You need a lot more information than just "the car turned". You need to know WHEN the car turned, and how much the car turned (or how long it spent turning).

Even with that information, do not expect another car making the same turns and the same time for the same length of turn/amount of turn to follow the same path.

What you really need are encoders on the wheels so that you can determine exactly how fast each wheel is turning. Then, quite often, you need to record that information. Much more often then the sensor data.

When replaying it in the other car, you'll need to use the encoder feedback to determine that you are going the same speed. Even if that all works, the two cars will follow only roughly the same path.

If you had a position system in both cars then car 1 could provide an obstacle map that car 2 could use to avoid obstacles regardless of exact paths. But then you'd need a position system.....

victorfb:
I understand. so how can I store the directions the car took?
and how can I use the information that I put on the file?

I can only guess. It might be a speadsheet where each column represents a stepper motor function and each row is a pulse applied to a stepping drive motor. The simplest robot vehicle is probably on three wheels. Two opposite each other are independently driven by steppers, thereby enabling them to do the steering, and the third is just a dumb castor. The course and distance is simply two streams of interrelated pulses, which are just numbers on the aforementioned SD card.

(This is the astronomer talking, not the robot car builder....)

victorfb:
I understand. so how can I store the directions the car took? I use if statements to analyze the values for the sensors for example:

if(sensor on right<20cm)

turnRight()// this is a function of the motor shield



and how can I use the information that I put on the file?

At what sort of interval do those steering actions occur? If the original vehicle is jittering left and right due to high frequency steering commands due to the sensor inputs, then you will get very poor repeatability (because the car will be accelerating a lot, and this tends to cause wheel slip which is not consistent). Even if you replay exactly the same sequence of movements to the wheels, the vehicle will not follow exactly the same path. The less frequent the changes speed/direction, and the lower the acceleration used during those changes, the better repeatability you will get.

Assuming you can design your original sketch to produce a manageably small number of speed/direction changes, your problem now it to store a sequence of actions that occur at irregular intervals. Given that your speed and direction changes are based on sensor input it seems likely that you won't know how far you've moved or turned until after the event, so I would design your encoding scheme to suit that. The most obvious way is to encode each change as an action and a quantity. For example you could define a set of byte values for action codes MOVE_FORWARDS, TURN_LEFT, TURN_RIGHT and follow each action with a number that specifies the number of degrees turned (or milliseconds spent turning, or however you want to represent it) or the distance moved (or time spent moving, etc). In this way the action code could be written at the start of each action, and the quantity could be written at the end of the action.

From the replay point of view it follows the same structure but now reads the action code and starts the action, reads the quantity and stops the action when the quantity has been reached, then starts the next action.

In both cases I'd use a read-ahead and write-behind to decouple the actions from the storage, so that the timing of the actions is not affected by the time to read and write from/to your storage device.

Probably the repeatability of the vehicle movement will be the limiting factor, rather than the storage capacity of your storage device; I suspect you will find the repeatability is so poor the replay is effectively unusable after a few dozen speed/direction changes and the quantity of data you're dealing with here may even be small enough to keep in EEPROM if you wanted to.

I just tested my whole system with the car reading the information from the array with the information of the sensors, and the second car went through the exactly same path. I just had to adjust the delay of the array reading.