Control of four motors with PIC or DSPIC

[victorcastro89]

I'm building a four-wheeled robot, where a Pic receives information wirelessly, sends other information for four other pic that controls the wheels, but the four pics that make the control wheel should return information on the current speed of each wheel to the first pic to make control of the robot.





My question is what kind of communication to use to the Master (pic1) transmit to the Slaves and the Slave Return information to the master.
Spi, I2c,rs485, Wich can do this?

Thank You!

[jgschmidt]

I'm working on something similar and am using CAN. Several of the Microchip processors support this. I have several reasons for using CAN: I am not limited by distance as I2C and SPI are and I don't have to write my own protocol/traffic handler as would be required with RS485. Also, CAN can be set up as peer-to-peer and many-to-many so my communications setup can be very flexible. You do have to be a bit creative with the physical topology since it is a linear bus.

I'm using the CCS CAN development kit as a starting point. Microchip also has a low-cost CAN dev kit that includes a great traffic logger which is invaluable for debugging. You have to know if the message ever got onto the bus so you know if the transmitter or the receiver is the problem if things go wrong. You can also use it to insert your own messages to test your receivers.

It takes a little bit to understand the philosophy behind the CAN protocols so be prepared for a little reading.

You can check out the bottom of this page for a list of CAN references:

http://www.jgscraft.com/microchip.php
_________________
Jürgen
www.jgscraft.com

[Gabriel]

why so many pics?

cant you do all in one?
_________________
CCS PCM 5.078 & CCS PCH 5.093

[temtronic]

Whole LOT simpler to use ONE PIC !
InterPIC communications will really eat up time and code space let alone programming and debugging time!

Without more details, like PIC to motor driver interface,feedback..encoder or ??, can't help more except even the 'old' 16F877 will more than handle all aspects of that robot.

Cut code to control 1 wheel(drive and feedback), once that's working right, clone 3 more times...done.

[victorcastro89]

Thank you all!
The first pic has a very robust control that has high processing costs, I tried using just two dsPIC, one to control the robot and another to control the motors.

But my dspic33fj128mc802 failed to receive information via the first dsPIC UART, reading speed of each motor, motor control, and return back the speed of each motor via UART.
The problem is that, for each hall effect sensor generates up to a thousand interrupts per second to calculate the speed of the motors, it hinders the dsPIC can receive information, make four controls and send data back to the first dsPIC.

You think the dsPIC can do it all at the same time and I did not get programming correctly?
Four interrupts 1000 times per second is crashing everything!

And about CAN, never worked with it, is difficult to implement?
Thank for the link!

[jgschmidt]

CAN is pretty easy from the hardware side. CCS has the necessary functions for handling the message traffic and there are dedicated CAN interrupts. I had a three-node system breadboarded and running in a day, blinking lights and returning messages in response to button presses. The fun is deciding on the message formats and getting into a "publish and subscribe" mindset for working with CAN. Some of that you would have to do regardless of the messaging system.
_________________
Jürgen
www.jgscraft.com

[temtronic]

Somewhere, somehow your code has a huge 'bug'...in either design or implementation.
4KHz interrupts are easily 'do-able' on even modest PICs(ie: 16F877).

Not seeing your code or the scope of the design does 'handcuff' us on the sidelines.

'robots' in general are slow and 4 wheeled ones probably don't need ground control down to the nearest millmeter. I've used 20MHz '877s for 3DOF helicopters, 3 axis CNC plotters, etc. for the past 15 years.

There are hundreds of wheeled robots out on the net for sale and they certainly don't have dsPICs or CAN bus controllers in them. Try to apply the 'kiss' principle..as all the commercial products have !

[SherpaDoug]

[victorcastro89]

[temtronic]

I can see both sides here, one PIC versus 5 PICs, having done both methods.

Using only one PIC you save on the R&D time to cut code to send/rcv data to the other 4 PICs which should(_must_) have some form of 'data valid' in the communications(CRC or ???).Without that a wheel or two could go 'funny', causing all sorts of grief! This added 'overhead' takes up CPU cycles(overall time), as well as additional PCBs,wiring,costs,etc.
Also some form of 'still connected' signalling should be built in.What happens when a wire breaks to the right rear wheel PIC?

Overall it is simpler,faster and cheaper to have one PIC do all the work.Any 40 pin PIC is capable of the task.Simpler, tends to be easier to code, easier to debug and faster to manufacture.

'distributed processing' has it's place but really is overkill for a simple robot.

[victorcastro89]

[temtronic]

Your original post asked about controlling 4 motors through a wireless module.

One PIC will easily do all that.
Been there..done that 15 years ago,'simple' fire fighting bot to seek out and put out a fire(candle) in an unknown maze.

What you didn't include were the other 'things' it has to do...vision, collision advoidance,FOF,ball kicker,interRobot communications,'find the ball',etc.There's probably a few LEDs that have to be lit up too.

Also not stated was the physical size limits.Maybe not a problem with SMT today, but should be noted,along with any other 'must haves'.

Given the new scope of the project I'd still use one PIC, running at 80MHz, gives millions of machine cycles to do the various required tasks.

[SherpaDoug]

In an application this small and fast I wouldn't bother with CRCs or checksums. Just refresh the motor control commands every 10ms or 25ms and if one occasionally gets corrupted the trajectory will not be too far off anyway. The overhead of verifying CRCs and requesting retransmission of packets would be too much.

What is the update rate of robot position you get from the video? Is this something you extract from raw video, or does the arena provide this to you?
_________________
The search for better is endless. Instead simply find very good and get the job done.

[victorcastro89]