Motor Drivers

[techhelpbb]

Originally Posted by apalrd

The propeller has basically no peripherals. While that gives you a lot of flexibility in code, there are some things that should stay peripherals.

I work professionally with a MPC5600 series processor, which has a lot of peripherals. The eTPU (Time Processing Unit), eMIOS (Modular Input Output System), and DMA (Direct Memory Access) alone on the chip I am currently working with would take around 192 propeller cogs to get something close in functionality, and the TPUs also additional peripherals to synthesize clocks (e.g. angle clock/angle timestamp) and manage timestamps/clocks that would have to be replicated somehow. This dosen't include SPI, QADC or the actual PowerPC itself. While you could likely move some of the algorithms into the cogs that deal with the IO, you would basically need over 200 cogs to get the low and some mid-level software done, and we haven't even touched comm, OS, or high-level application code.

A good C compiler is basically a requirement for an embedded platform these days, especially with autocoding tools which generate C code from models.

I can't speak for the cog count you've assigned to these functions but realistically if you really need purpose built peripherals there are many choices to achieve that result. For example I had no trouble at all gluing a Xilinx CoolRunner CPLD or Spartan 3 to the Propeller and I have a rough prototype using the XCore. More importantly I could change the glue to multiply the number of CPLD/FPGA connected to one or many cogs or Propeller chips. (Interestingly the prototype for the Propeller was made in an FPGA).

Realistically speaking if we can compare the Parallax Propeller 1 to the cRIO which includes the FPGA it's only fair to consider the inclusion of similar hardware.

Also there are OS for the Parallax Propeller.

I can't argue that you should back-hand your way to the sort of integrated functions you enjoy on your microcontroller / microprocessor of choice if you don't have some other reason to do it. Surely if those peripherals are your highest priority you'd be foolish to try to round the square peg to fit that hole. Especially if those peripherals are some kind of proprietary IP.

Still I can drive a FIRST robot on a single Parallax Propeller and it would be sort of like the performance of a bunch of the old IFI control systems.

[yash101]

Originally Posted by philso

In addition to all the issues that Andrew has raised, I should point out that drawing the schematic is the "easy" part. Laying out a circuit board for a processor like this would require that you have experience designing (properly) multi-layer, high-speed circuit boards with multiple power and ground layers. There are no secrets or black art involved, just years of study. Learning to use the free Altium package only makes you a CAD operator, not a PCB designer. If you do not understand the difference, you are unlikely to design the circuit board properly, leading to "anomalous" operation that will make you tear your hair out. It is also likely that you will have a lot of trouble properly soldering the QFP and QFN packages.

It may be best if you do some research and find out what external processor boards other teams have been using to do their vision processing and buy one of them. It is likely that you will pay much more for just a bare PCB than you will for one of these fully functioning, mass produced processor boards.

I am in a STEM program and I have teachers that help me with these problems.

[Nirvash]

Originally Posted by team1165wins

Would it be possible to create a SLAVE circuit to the cRIO to control the small servos or even the motors, to prevent lag. I have an eight core processor that I could use to do all the dirty work...Just note, this would be for next year. not this year...no time

Don't think it would be legal, see quoted rule below, though it would make for a neat project.

R67
Every relay module, servo, and PWM motor controller shall be connected via PWM cable to the Digital Sidecar and be controlled by signals provided from the cRIO via the Digital Sidecar. They shall not be controlled by signals from any other source.

[cgmv123]

I don't understand why you want to do this. The cRIO has more than enough power to handle whatever you can throw, except maybe intensive vision processing, and the FPGA can go down to the microsecond.

[apalrd]

This sounds like a terrible idea, even if it were legal (which it is not).

The Propeller is one of the last processors I would want to use as a robot controller. There are far better micros which have far more useful peripherals.

The cRio IO is really quite slow since it's read through the FPGA which itself reads it from the modules over some high-speed bus (unsure exactly what it is), and the layering and OS overhead isn't insignificant, but it's still a 400mhz 32-bit PowerPC with hardware floating point and many megabytes of RAM. The Propeller runs at max 80mhz with an external clock, has 32 IO lines with no analog, no peripherals to speak of other than the 8 cores (Each of which has 512 words of RAM) plus 32K of system memory (RAM and ROM).

For some comparison, some of the MPC5500/5600 processors I deal with could be configured to run the RT control loops of a robot through peripherals and DMA entirely (without any actual processor action or interrupts). That is the processor I would like to use in FRC.

[yash101]

I was wanting to make it possible for a microcontroller with parallel processing capabilities be getting input, talking to the cRIO, and then send motor output. If possible, I would like the microcontroller to take over while the cRIO is processing an image. This microcontroller costs $8 from manufacturer and $12 from stores and can operate twice as fast as the cRIO. with a clock running at 5MHz and a PLL of 16, 8 cores can give 160 MIPS (160,000,000 instructions per second). That is pretty nice for this. Also, the cRIO needs to continuously interrupt, reducing performance. Sending a Pulse through a PWM means that the cRIO will need to wait for the signal to send before it can do the next thing. This processor can have a core doing it in realtime. The microcontroller has i2c so it can be easily interfaced through the WPILib C++.

[yash101]

I am working on a schematic for a control board with two MCP3204 chips for ADC 12b. 3v3 and 5v regs, and 256kb EEPROM. I also have programmed this chip in ASM before. Hard, but the performance was just great.

[apalrd]

Originally Posted by team1165wins

That is pretty nice for this. Also, the cRIO needs to continuously interrupt, reducing performance. Sending a Pulse through a PWM means that the cRIO will need to wait for the signal to send before it can do the next thing. This processor can have a core doing it in realtime. The microcontroller has i2c so it can be easily interfaced through the WPILib C++.

Interrupts don't exactly work that way.

There are many ways to do something. The MPC5500/5600 I mentioned earlier has dedicated hardware to time outputs (eMIOS and eTPU) so the processor only has to set them up at init and write a memory mapped register to set the value. The eTPU can even run timing-critical code on it's internal processor, without interaction with the PowerPC. The cRio uses an FPGA to do something similar, neither method requires an interrupt at all.

On a normal processor supporting interrupts, it would be common to generate PWM using a timer interrupt. You could setup the timer to interrupt when you next need to service some IO thing, go on and do other things, and interrupt back when it's time to do something again. All of this assumes the micro dosen't have PWM generation in hardware, most can do it using timers, the propeller has nothing resembling hardware PWM generation.

The purpose of an interrupt on micro programming without a pre-emptive OS is to provide a method to pre-empt the running task to deal with an important event (usually IO or clock related) allowing the running task to go on with it's buisness on a single faster core. There's not very much inherintly inefficient about the interrupt if the code is written well. When you can prioritize interrupts, it's common to run fast code in a low-priority ISR as a basic pre-emptive system.

An embedded microprocessor is frequently surrounded by peripherals which can do a LOT of things in hardware and only signal interrupts when they are needed or wanted. The propeller has none of these, and has to do everything in software. It will spend most of it's time doing these mundane IO tasks which are usually done in hardware, including waiting for events instead of using interrupts, which is exactly how it is designed to work. This means it will spend many clock cycles waiting for timing or spinning until it's ready, where an interrupt driven processor could use those clock cycle to do useful other things and interrupt back when it needs service again.

[ferret_guy]

that sounds like a great personal project but in order to match the c-rio you would need something far faster and more advanced. If you really wanted to do this you could use the dio pins and set them to correspond to a single motor controller output

[yash101]

I am basing it off the arduino, but placing a much better processor instead of an Atmel AVR. Currently I am designing with the P8X32A-D40

[cgmv123]

Originally Posted by team1165wins

Currently I am designing with the P8X32A-D40

Which can't come close to the cRIO. Unless you're trying to do very intensive vision processing/process multiple images simultaneously, the cRIO can handle whatever you throw at it. I still don't know what you're trying to accomplish.

With regards to (this year's*) rules: Coprocessors are allowed, but the cRIO has to control the robot. [R67, R55] Altering PWM pathways is expressly disallowed. [R54, R67] You have to go through the cRIO anyway, so I don't see what you'd gain.

*I (not an expert nor insider) do not anticipate any of the relevant rules changing significantly for (near) future seasons.

[yash101]

This is to continuously drive the motors. When the cRIO is busy with another task, it cannot output another signal to the Jaguar or Talon. Also, I wanted all sensors to be connected to this. The final output to the cRIO could be possibly: LEFT | RIGHT | BACK | FORW, and the driver input. I really like Parallax products because I find them robust, powerful, efficient and high quality. Parallax has a nice support team, even though they are such a small corporation. They are also quite resistant to some dangerous things like electrostatic discharge. For example, the cRIO could send this chip a command, like RETRIEVE [sensor name], for example, and the chip could give the data. Using a laser range finder, for example, would allow you to get an accurate distance from a point, like the goal in this year's challenge. The cRIO would only have to make the final decisions. Also, I could integrate a CAS into this chip so that when the cRIO needs to calculate large numbers, the coprocessor could do it. When there is only one processor doing a ton of work, the whole system becomes laggy. It is common about how the robot will stop in place while processing an image.

[Joe Ross]

Originally Posted by team1165wins

This is to continuously drive the motors. When the cRIO is busy with another task, it cannot output another signal to the Jaguar or Talon.

As others have told you, this isn't true.

[cgmv123]

Originally Posted by team1165wins

This is to continuously drive the motors. When the cRIO is busy with another task, it cannot output another signal to the Jaguar or Talon. .... It is common about how the robot will stop in place while processing an image.

The FPGA controls the outputs. The CPU does image processing. They can are designed to work in parallel. With proper coding, the cRIO should never be too busy to not set the outputs.

Co-processing complex inputs, like cameras is feasible, legal, and in many cases, recommended.

Bottom line: You are not allowed under current FRC rules to use a separate processor to control or modify the control signal to the motors. It isn't feasible anyway and what you're proposing won't do anything but be very hard to accomplish. The cRIO is an excellent product, get to know it.

[apalrd]

The point of a real-time pre-emptive operating system is to manage high priority timing critical tasks and low priority less critical tasks on the same CPU.

An operating system can pre-empt the slower or more resource-intensive task to execute a higher priority task, then return to the slower task. In FRC, the slower task could be vision, and the faster task could be everything else. Since it takes at least 100ms to process an image, the faster task could pre-empt the image processing several times for each image processed. The higher priority stuff gets done on time, and the lower priority stuff gets done eventually.

The cRio's PowerPC actually sends data to the FPGA (I'm not entirely sure if it's through mapped memory or something else, but it gets transferred to the FPGA's RAM space) which then deals with the actual sensors. It's almost like your input/output coprocessor except it runs fully parallel at 40mhz. Since an FPGA describes hardware, instead of operating on a vector of instructions to execute it actually arranges logic gates to pipeline the operations all in parallel, so everything happens at once or at a lower clock frequency (e.g. many DIO loops run at only ~150khz to match the max speed of the DIO data).

If things ever stop happening because vision is too demanding, then you need to architect the code to run vision in a lower priority task and VxWorks will schedule it like a lower priority task, pre-empting it when the control code needs to run. This is possible and not very difficult to do, it's quite trivial in LabVIEW.



I also suggest you try to find the time it takes to do a 64-bit double precision floating point divide on the cRio's PowerPC vs the Propeller. Actually, tell me if the Propeller can even do it at all.

The propeller and it's cousin the BASIC stamp are probably my definition of low-power microprocessor. There are many far better chips available which can do a far better job at handling embedded controls.


A far better design direction would be to put vision on a co-processor. There are many solutions that have been tried, I can't recommend any of them personally but some sound reasonably fast.