OSCAR - motor controller - programming issues

[Ro-Bot-X]

Ok, so I am working on my motor controller module and I am trying to figure out how to program it so I can use eighter UART or I2C with the same command format.

I guess I need to receive something like: address, command, value1, value2...
The address and values are bytes, that's easy. The command can be a byte or a string. If it's a string, there will be a byte for each character, so there has to be a separator or a special character to look for to figure the string is complete and the first value comes in. To make things easy, I think a byte can be used as the command and the user can set up some defines for each command name to represent a certain number from 0-127, even for the address can be done the same thing.

So the user can say (arduino code):

Code: [Select]

#define Motor_Controller_Module 4
#define Set_Motors_Speed 28
byte Left_Speed=100;
byte Right_Speed=100;

 Wire.beginTransmission(Motor_Controller_Module);    //address
 Wire.send(Set_Motors_Speed);                              //command (register)
 Wire.send(Left_Speed);                                        //value1
 Wire.send(Right_Speed);                                      //value2
 Wire.endTransmission();
or:

Code: [Select]

#define Motor_Controller_Module 4
#define Set_Motors_Speed 28
byte Left_Speed=100;
byte Right_Speed=100;

 Serial.print(Motor_Controller_Module, byte);          //address
 Serial.print(Set_Motors_Speed, byte);                  //command (register)
 Serial.print(Left_Speed, byte);                            //value1
 Serial.print(Right_Speed, byte);                          //value2

Of course, the maker of the module has to provide a list of commands and the user can copy-paste the defines and mod them to his taste. I guess the same procedure has to be taken for a device that is allready available on the market.

What do you guys think, is this the correct approach or not? If not, please let me know what should I change.

Thanks.

[Ro-Bot-X]

So I get that no one actually knows the answer to this... All right, I'll do what ever works out best for me. If will comply with the standard, fine. If not...

[Asellith]

I think the last thing we discussed along these lines was for the module maker to provide a library to be included in the users code. The documentation for the module will detail the commands but the module maker can do whatever they want as long as the library is easy to use.

For instance you would need to provide a function like setMotorSpeed(channel, direction, % speed) Then the user only needs to call the function and fill in the blanks.

In module design like this it might also be better to stay away from left and right designations because you don't know what the user will plug into it. So if its a 2 channel motor controller then just label the pcb as channel 1 and 2 and then let the user define whats left and right or steering and drive. Whatever they want.

We also need a standardized library for communication commands so that every module can use them and each module library doesn't have to handle setting up communications.

As far as your approach goes that is what we discussed as the best way to do things. To write values to a register inside the module. so the communication standard calls for a module address then a register address then a register value. You can have several values in a row and just have the receiver iterate the register number. So what you proposed would work.

[Webbot]

We also need a standardized library for communication commands so that every module can use them and each module library doesn't have to handle setting up communications.

Yep - that's your 'deal breaker' for the whole OSCAR project. Since everything is meant to be I2C based. In its absence everyone seems to creating alternative drive mechanisms eg uart etc. So OSCAR adds little if this is the case (ie the whole OSCAR plug'n'play thing falls apart)

Someone needs to build and prove an I2C driver according to the OSCAR specs - eg Multi-master and Multi-slave that all module creators can use, and all roboteers can use. Without it you're dead.

Would have a go in my library but I don't have any I2C devices to play with.

[Asellith]

Well I'm to the point now where I can start working on new projects so I will try and throw something together to start testing the code. I might have to steal an o-scope from work in order to get a good idea of whats going on after I start coding.

[Ro-Bot-X]

Ok, it's god to know I'm not completly off. I'll keep playing with Arduino code and Wire library. The examples are very easy to understand and follow. I'll see about creating some functions like you sugested. I thought I'll use negative values for backwards and positive values for forward, but I see that needs an integger - which is 2 bytes, same like specifying direction separatelly. I want to keep the number of bytes to a minimum, so I'll make the commands accordingly. I just want to see the thing running. Then I'll go about more complex stuff.

[Webbot]

Most libraries, AVRlib included, allow easy comms between one master and multiple slaves. Done and dusted - easy  .
You should be able to control uni-directional modules like motor controllers quite easily.

But OSCAR calls for multiple masters so that your augmented motor controller can say 'hey I hit an object' and any other modules could do the same. So they are sorta like interrupts to the main program. This is where the challenge lies in the I2C programming interface. Some serious testing needs to happen to make sure that this works. In the current absence of 'master mode sensors' hardware designs then this may require a lot of debugging/experimentation. ie what happens when all of your sensors (lets say there are 12 of them) all want to become masters at the same time. Does it work? Someone needs to write this 'bullet proof' software so that it can be loaded onto modules and included in the main app. This needs serious source control as each bug fix release may mean that you have to upgrade the firmware in ALL of your sensors/modules. So I trust that all of you 'module designers' are including an ISP header for firmware updates.

[Ro-Bot-X]

I hear what you're saying. My module is simple and is not going to be a master because of lack of flash space. I prefer to add advanced functionality than master comms. But I can play around with 2 mega168 boards and see how's going, but still, that's not several slave masters on the bus. I am also not the programmer that can figure out how to work around any bugs.

I have posted this link somewhere else, but I will post it again, just in case it got "lost":
http://www.robotroom.com/Atmel-AVR-TWI-I2C-Multi-Master-Problem.html

[Ro-Bot-X]

So I got my boards talking to each other (one way) using I2C and Arduino Wire library. Very easy to set up and use. The fun part is that receiving I2C is handled as an event, like any other interrupt. I had my Roboduino set as master and my Ro-Bot-X board set as slave motor controller. My motors were turning as I2C commands were received, using PWM to accelerate and decelerate. I didn't use any encoders yet, so I can't control the distance traveled (I was thinking at using a time based calculation, but that complicates the code a lot and it will not be used after the motors with encoders will be installed), so just Forward, Reverse, TurnCW, TurnCCW and Stop are the only commands at the moment. Anyway, the code size so far gets close to 7k in Arduino.

[Ro-Bot-X]

I wrote the code with the encoders counting distance or degrees. I also managed to merge together functions with common code for optimisation and the whole code takes 6590 bytes. See attached .txt file and rename to .pde before opening in Arduino.

The controller works like this:
- receives a command followed by 2 value arguments: (forward, distance, speed) - all bytes, so distance goes up to 255 centimeters
- based on the command, determines the direction and starts the apropriate function passing the 2 value arguments
- resets the encoder counters
- accelerates to set speed
- calculates the distance to decelerate
- keeps driving at set speed until distance to decelerate
- decelerate
- if there is not enough time to get to the set speed, accelerates until half distance is traveled, then decelerates

Master has to keep track of the traveled distance without asking the slave where it is - it can calculate the necessary time for the command to be executed and issues a new command just before the last one is closed to be done.

Things to do:
- keep checking for new commands while driving/turning to allow quick stop
- if new command is not QuickStop(), wait until current command is finnished before starting the new command