Using SD Cards with...
 
Notifications
Clear all

Using SD Cards with Arduino - Record Servo Motor Movements

84 Posts
6 Users
1 Likes
7,800 Views
Will
 Will
(@will)
Member
Joined: 3 years ago
Posts: 2531
 

@robomaster 

When you're recording, how do you know when the pots are in their final position and the values can be saved to the file ? 

Are you recording and playing back a single observation ?

Anything seems possible when you don't know what you're talking about.


   
ReplyQuote
Will
 Will
(@will)
Member
Joined: 3 years ago
Posts: 2531
 

@robomaster 

I have adapted the Record() function to suit what I understand of your requirements. It also involves changing some of the other code as well.

I don't understand how you determine when all of the pots have been set and the data is ready to be displayed, sent to the servos and stored in the file. So, I've set up this code to wait until the user presses the red button again. That will trigger the sketch to collect the pot settings and continue on.

If that's not satisfactory, then adjust the code to whatever criterion you prefer.

I've renamed the package to be 5A instead of 5 to allow it to co-exist peacefully on your system (and mine) without overwriting the original.

I'll leave adapting playback to you 🙂

Anything seems possible when you don't know what you're talking about.


   
ReplyQuote
(@robomaster)
Member
Joined: 3 years ago
Posts: 36
 

 

This is a version that reads and stores the four channels into an array. Would using this as a start point be easier to switch to record and playback to the SD Card?


   
ReplyQuote
Will
 Will
(@will)
Member
Joined: 3 years ago
Posts: 2531
 

@robomaster 

I don't know if it's applicable or not because I don't know your requirements. Is there a reason you're not already using it ?

Anything seems possible when you don't know what you're talking about.


   
ReplyQuote
(@robomaster)
Member
Joined: 3 years ago
Posts: 36
 

It reading into a 700-byte array. I need more storage space that is why I need to use the SD Card. I will be will also down the road I will be adding control of an external MP3 player so I can sync it to an audio file.

I am trying to figure out how to use the code you gave me to get it to work inside the record and Playback function to expand it to control all four channels. Can you go over it again I am still having problems with getting it to work?

 

To explain what I have in mind here are the basic specs. To control sixteen servos using, in this case, using four-channel analog slider-pots on A0 to A3 analog inputs. To record and playback from an SD Card, includes seeing the servos move in real-time as they are being recorded and playback. Need to be able to switch the 4 channel console between servo banks without affecting what was recorded previously.  Again I thank you for all your help on this


   
ReplyQuote
Will
 Will
(@will)
Member
Joined: 3 years ago
Posts: 2531
 

@robomaster 

OK, let's start off this way ...

1) Have you read and do you understand what the Record() function is doing as it stands in 5A ? It is currently reading all 4 pots and saving the value of each into a set of 4 bytes and then processing and storing each set (as a single unit) to the file.

The sketch you proposed last time seems to read all 4 pots and then compare them and store them separately (i.e. each pot value at different index in the array). Clearly, these are not compatible.

2) You have alluded several times to using 16 servos, but it appears that you're only going to be using 1 input device with 4 pots. Is this correct and do you propose to somehow read the pot values 4 times (i.e. 0-3, 4-7, 8-11, 12-15) and stitch them all into one 16-byte data record ?

Whether reading only 4 or four sets of four, how to you intend to indicate that the pots have been set correctly and the data set should be saved to the current data set ?

Anything seems possible when you don't know what you're talking about.


   
ReplyQuote
(@robomaster)
Member
Joined: 3 years ago
Posts: 36
 

I am sorry I just discovered the 5A program and I am looking at it right now. I guess I did not read through all the replies as carefully as I thought. To answer the question asked in that post I am just stopping the record function when the stop button is pushed. It keeps adding on to the file. which makes it longer and longer each time you record to it. I hope this answers your question.


   
ReplyQuote
Will
 Will
(@will)
Member
Joined: 3 years ago
Posts: 2531
 

@robomaster 

The 5A sketch keeps waiting until you press the red button again, then it processes the pots, sets the servos, reports the values and saves them to the file. It keeps doing that until you press the stop button.

Is that acceptable ?

Have you run the sketch to test the Record() function ?

Anything seems possible when you don't know what you're talking about.


   
ReplyQuote
(@robomaster)
Member
Joined: 3 years ago
Posts: 36
 
Serial Monitor

 

I run the 5A code and above is the Serial Monitor Screen dump. I have to hold the record button down to make read.


   
ReplyQuote
(@robomaster)
Member
Joined: 3 years ago
Posts: 36
 

Also, the servos are not moving as I move the pots.


   
ReplyQuote
(@robomaster)
Member
Joined: 3 years ago
Posts: 36
 

I will look at it and will get the buttons working. I will send you the updated code.


   
ReplyQuote
Will
 Will
(@will)
Member
Joined: 3 years ago
Posts: 2531
 

@robomaster 

I didn't see that you had posted anything because you didn't use the Reply button, so I didn't receive emails notifying me of your reply.

1) when in Record(), the sketch waits for you to set all the pots and then press the red button. When you push it, the sketch processes the pots and saves the record. It then moves back to waiting for the red button again. If you hold down the red button it just cycles and copies the current pot readings.

2) You never mentioned that the pots were supposed to immediately follow changes to the pots, so that was never built into the sketch. Now the servos are only moved during the Record() code when the data is stored (nota s it's read).

3) It seems that using the red button to indicate that you're finished setting the pots isn't a good idea. Another possibility is giving you say, 5 seconds to set the pots and then the data will be stored (ready or not). Can you suggest some better way to indicate that you're finished setting the pots and that they should be processed and stored ?

4) the print to serial routine appears to be printing chars instead of numbers. Please change the declaration at the top from type "car" to type "uint8_t". That should help tell Serial.print(ln) to treat it a s number and not a character.I think you need only change the defining type near the top.

Anything seems possible when you don't know what you're talking about.


   
ReplyQuote
(@robomaster)
Member
Joined: 3 years ago
Posts: 36
 

@will 

Sorry about not using the replay right, The record button just starts the record function loop and putting the servo position on the SD Card. The blue button (Stop) is what breaks it out of the record function stopping it.  I will work on getting to work correctly tomorrow. I need to go to bed.

Put this statement uint8_t where at the top of what? Never had to do this before I am a little confused about it.


   
ReplyQuote
frogandtoad
(@frogandtoad)
Member
Joined: 5 years ago
Posts: 1458
 
Posted by: @robomaster

@will 

[snip]

Put this statement uint8_t where at the top of what? Never had to do this before I am a little confused about it.

He means to change the following from: 

char dataBuffer[DATA_POINTS];

 To... 

uint8_t dataBuffer[DATA_POINTS];

But since uint8_t is the underlying type for the 'byte' data type, we should prefer to use that type definition as reccomended instead: 

byte dataBuffer[DATA_POINTS];

 Cheers.


   
ReplyQuote
frogandtoad
(@frogandtoad)
Member
Joined: 5 years ago
Posts: 1458
 

@will

Posted by: @will

@robomaster 

[snip]

4) the print to serial routine appears to be printing chars instead of numbers. Please change the declaration at the top from type "car" to type "uint8_t". That should help tell Serial.print(ln) to treat it a s number and not a character.I think you need only change the defining type near the top.

True, that should solve the problem, but not because it's an integer type (as is char), but because it has a greater positive range than than char. The byte data type is a type definition for the uint8_t data type, but with the difference being that byte data type is an unsigned data type, with a range of 0 - 255, where as the char data type is a signed data type, providing the range of -128 - 127.

So anything beyond 127 in the map function would produce undefined behavior.

Cheers.


   
ReplyQuote
Page 3 / 6