What is an "ideal application for P2"?

profbraino · 2019-12-07 18:29

Now that the P2 is available, what are some of the things you plan to use it for?

That is, what application is the P2 best suited for, and what makes P2 the best choice, over some other microcontroller option?

Thanks for you responses.

Mickster · 2019-12-07 18:59

Multi-axis control of servo motors and servo hydraulics. I don't know of any other device that can directly handle so many quadrature encoders.

Many suppliers of motion control cards use the LM628/629 device but they are single axis devices and cost north of $30. The performance is nothing to write home about, either.

jmg · 2019-12-07 19:16

profbraino wrote: »

That is, what application is the P2 best suited for, and what makes P2 the best choice, over some other microcontroller option?

There are also cases where you might choose a P2, over some other microcontroller option simply for flexibility.
In the degree of flexibility it provides, P2 is more like a FPGA, than a microcontroller,
Any smart pin cell can become any peripheral, so if you want 2 or 6 or 12, or 24 Quad encoder interfaces, P2 can do that.
Or, you can have any number of DACs from Video to lower power.

The P2 ROM allows boot from SD, so that blurs the usage from some other microcontroller option into also some other microprocessor option

I can think of cases where a P2 could displace a RaspPi, and others where it could work very well with a RaspPi.

A product like Red Pitaya could get interesting, done with a P2.
A bare-metal P2 can offer a lower peak spec, but give users any mix of ADC/DAC and Digital.
An external AFE can boost the operation of a couple of channels of ADC/DAC.

Instrumentation and test are one area I see P2 shining in. Those are not price-paranoid but they are very flexibility focused.
Just like FPGAs are used in large numbers for development & R&D, I can see P2's being used to decide what is actually needed early in a product development.
Proof of concept is an important stepping stone, and funding can pivot from that.

whicker · 2019-12-07 19:29

I agree, and add that any kind of magnetic coil control seems like a good fit. Control of linear and rotary motors, voice coils, adjustable power supplies, levitation, mirrors, etc.

Rayman · 2019-12-07 19:48

I think P2 will be great for custom control systems. P1 is great, but often need expanded I/O or additional chips for interfacing and is sometimes just fast enough.
Also, I am always running out of memory with P1...
P2 will make things a lot I did with P1 a lot better and easier.
And hopefully, will be just as reliable.

Here at home, I'm thinking robots... Robots with a lot of servos and sensors...

Publison · 2019-12-07 20:37

profbraino wrote: »

Now that the P2 is available, what are some of the things you plan to use it for?

That is, what application is the P2 best suited for, and what makes P2 the best choice, over some other microcontroller option?

Thanks for you responses.

Is this the original prof_braino ? We have missed you for a couple of years.

Cats92 · 2019-12-07 21:44

Do you think that the P2 mode of fonctionnement may be effective for mobile vision applications?

Seems that there is an increasing demand in this field , for robots , security ,..

A lot a libs were developped in C or python.

As i am not a professional programmer i dont know if it will be a hard task to install such tools on a P2 .

profbraino · 2019-12-07 22:05

Publison wrote: »

Is this the original prof_braino ? We have missed you for a couple of years.

Yes, this is me. I lost my password to the prof_braino ID during the move, and I was to impatient to figure out how to recover it.

Thanks for asking.

profbraino · 2019-12-07 22:15

Cats92 wrote: »

Do you think that the P2 mode of fonctionnement may be effective for mobile vision applications?

This interesting. What functions are needed for this image processing? IF not present in the stock P2, could such functions be built into FPGA?

A couple years back I bought a part that could be trained to identify objects, it supposedly could identify 200 individual bouncing ping pong balls. The demo was impressive, but I never had a need for identifying 200 bouncing ping pong balls.

Publison · 2019-12-07 22:35

profbraino wrote: »

Publison wrote: »

Is this the original prof_braino ? We have missed you for a couple of years.

Yes, this is me. I lost my password to the prof_braino ID during the move, and I was to impatient to figure out how to recover it.

Thanks for asking.

I can take care of the password problem. PM me.

Cluso99 · 2019-12-07 23:39

One area that needs examination is instrumentation.

* With the improved ADC of the next RevC parts,
* together with the scope and streamer modes,
* plus the ability of using VGA/HDMI at 1920x1080
* and on-chip ADCs on every pin,
* and on-chip DACs on pin groups

I see some smart cheap instrumentation options here

There will also be many uses for...
* some form of OS running from SD (ie some form of dynamic loadable code/parameters) now that we have 512KB of HUB.

Each independent 32-bit CPU core (COG) has..
* 4KB (1K x 32-bit) Dual-Port RAM code space of which...
** 2KB can be a mix of code and register space
** 2KB can be code or lookup or streamer space
** 2KB can be "shared" with its' adjacent Core pair
* has shared access to a common 512KB (byte/word/long) HUB RAM (organised as 64K x 256-bit wide) such that every Core can access the hub on every clock (see egg-beater description)
* can execute code directly from HUB RAM with little penalty (HUBEXEC)
* most instructions execute in 2 clock cycles
* extremely powerful instruction set (32-bits) with
** multiply, divide, cordic and other very specialised instructions
** deterministic instruction set (with some restrictions)
* optional Interrupts - very specialised but simple interrupts
* available individually/separately on each and every core

And don't forget the speed...
* 200MHz is easy,
* and close to 400MHz with overclocking,
* mostly 2 clock instructions,

One of the original draw cards of the P1 was its' large RAM compared to FLASH of micros of the time. The P2 brings it into line with some new generation chips.
I never thought P2 would compete with ARM products, but I think this will happen in specialised areas

Then we get to 64 smart I/O pins...
* Each pin has its' own programmable smart functionality with
* internal pull-ups and pull-downs,
* counters,
* serial aids including async, sync (eg USB),
* and ADC on every pin (see above),
* and DACs on pin groups (can run multiple VGA/HDMI/Composite Monitors dependent on memory)
* and the ability to mix these with cores to become extremely powerful and flexible I/O peripherals

Need I say more??? - lots of opportunities here!!!

Cats92 · 2019-12-08 08:03

Profbraino,

you can download MobileNet appli for object detection from many internet sites.

Mobilenet is good for embedded machine vision : light, quick and accurate.
You can find how to create biblis with your own images : it is easy for a hobby work but a long procedure to get Professional level.

So i tried Mobilenet on :
* a PC
* a Raspberry pi (easy but a bit too slow)
* a Nvidia Jetson

Installation may be a bit tricky (if you have not the adequate version of the underlying Tools)

But it works nicely on a PC or a Jetson.

For FGPA and object detection see :

https://arxiv.org/ftp/arxiv/papers/1711/1711.05860.pdf

Jean Paul

Mickster · 2019-12-08 11:38

As one who has been unable/unwilling to decipher the P2 technobabble, this thread is proving to be very informative.

I understand that we have some awesome language developments happening but do I understand correctly that the new spin will be interactive and that code can be edited directly on the P2? Or did I just dream of this?

Reinhard · 2019-12-08 11:52

I have planned to use the P2 as DSP - like applications
First to make digital filters, like this:

'	IIR Highpass 1. Order
'	y[0]   = A[0] * x[0] + A[1] * x[1]  - B[1] * y[1]
'       out    = B[0] * y[0]

dat
	org
	mov		xx0,#0					'x[0]
	mov		xx1,#0					'x[1]
	mov		yy0,#0					'y[0]
	mov		yy1,#0					'y[1]

input
	mov		sample,##$4000			'come usual from adc (16bit)	

filter
	mov		xx0,sample
	
	qmul	yy1,B1
	qmul	xx1,A1
	qmul	xx0,A0
	getqx	T1
	getqx	T2
	getqx	T3
	sar		T1,#16
	sar		T2,#16
	sar		T3,#16
	
	add		T3,T2
	mov		T4,T3
	sub		T4,T1
	mov		yy0,T4
	mov		xx1,xx0
	mov		yy1,yy0
	
output
	mov		out,yy0						'go to dac (16bit)
	jmp		#input						'loop forever

										'filter coefficients
A0	long	$f831 							'0.9695
A1	long	$ffff07cf 							'-0.9695
B0	long	$10000 							'1.0
B1	long	$ffff0f98							'-0.9391

xx0		res	1
xx1		res	1
yy0		res	1
yy1		res	1
T1		res	1
T2		res	1
T3		res	1
T4		res	1
sample	res	1
out		res	1

I am already waiting impatiently for P2 hardware.
The results of a SIMULATION look very good.

ManAtWork · 2019-12-09 14:45

Mickster wrote: »

Multi-axis control of servo motors and servo hydraulics. I don't know of any other device that can directly handle so many quadrature encoders.

Yes, that's true. But most modern servo motors don't have quadrature encoders any more. For brushless motors you need some sort of absolute feedback for commutation. Incremental encoder plus hall sensores need way too much wires. Modern absolute encoders only need two pairs (5V supply + RS485 data).

But anyway, the propeller is still superior to other µCs, it can have an RS485 UART on any pin pair you like and as many as you need.

Mickster · 2019-12-09 15:27

ManAtWork wrote: »

Mickster wrote: »

Multi-axis control of servo motors and servo hydraulics. I don't know of any other device that can directly handle so many quadrature encoders.

Yes, that's true. But most modern servo motors don't have quadrature encoders any more. For brushless motors you need some sort of absolute feedback for commutation. Incremental encoder plus hall sensores need way too much wires. Modern absolute encoders only need two pairs (5V supply + RS485 data).

But anyway, the propeller is still superior to other µCs, it can have an RS485 UART on any pin pair you like and as many as you need.

Great to see you around again buddy!

Everything I come across, involves a simulated encoder output from the drive and still, the +/- 10v motor command.

I am typically in the 2KW+ range.

Servo hydraulics are also a big part of what I do and there you usually find an incremental encoder. Remember the line driver that you sent to me in Italy? That was for a servo-hydraulic system.

There are also absolute encoders that output quadrature. On power-up, your counters are brought up-to-date by clocking the encoder.

MattMatz · 2019-12-10 05:16

Just curious - if the P2 has solid and fast ADCs, and could do HDMI output - is an oscilloscope that uses a TV as a monitor possible?

jmg · 2019-12-10 05:44

MattMatz wrote: »

Just curious - if the P2 has solid and fast ADCs, and could do HDMI output - is an oscilloscope that uses a TV as a monitor possible?

Perhaps you imagine something like this ?
https://forums.parallax.com/discussion/170820/hdmi-4-channel-oscilloscope-demo/p1

To keep up with the rest of the system, perhaps an external 'better ADC' could be added, but P2 is certainly good enough to be a solid instrument.
It can be better than most MCU based LCD Scopes, and add an external ADC and it could push into 10~100MHz BW regions.

ManAtWork · 2019-12-10 08:09

Mickster wrote: »

Everything I come across, involves a simulated encoder output from the drive and still, the +/- 10v motor command.

An "universal" servo controller would be one of the "ideal" applications for the P2, providing all types of signal interfaces you can think of:
* absolute encoder input
* resolver input
* quadrature input
* simulated quadrature output
* +/-10V analogue command and tachometer input
* step/dir input
* EtherCat command input (that'd be a challange!)

Unfortunatelly, all those features increase the price of the controller. And you really need that only for retrofitting old machines. So I fear that the volume demand is not high enough to justify a new development. There are lots of existing drives that offer what you need. SanyoDenki R series can do everything but resolver input for example.

Mickster · 2019-12-10 08:45

EtherCat is a hot topic but I want get to the point where the only machine wiring is the power. Every control signal to be wireless. There are already integrated drive/motors out there.

Why aren't we doing this?

Eliminate the long encoder/resolver cables.

Eliminate hundreds of 1mm² sensor conductors.

cgracey · 2019-12-10 11:26

Mickster wrote: »

EtherCat is a hot topic but I want get to the point where the only machine wiring is the power. Every control signal to be wireless. There are already integrated drive/motors out there.

Why aren't we doing this?

Eliminate the long encoder/resolver cables.

Eliminate hundreds of 1mm² sensor conductors.

Yes, everything at point-of-load, just needing power, and then communicating wirelessly. Ideal, but seems kind of vulnerable.

Mickster · 2019-12-10 14:50

Hey, I first got the idea from the Programming and Customising the Propeller

cgracey · 2019-12-10 15:27

Cabling is a bugaboo, for sure.

There's the matter of minimizing lengths of high-current wire, as it's expensive and suffers IR drop. Same problem in mechanics with drive systems. A guy down the road from me rebuilds heavy construction equipment. He was telling me that these newer high-track dozers are much easier to repair than the older ones because of how they're engineered. In the old dozers, there was a transmission which drove a very large axle at low speed to drive the tracks. When something would break, he'd have to dismantle many heavy things before he could fix it. These newer machines have a torque converter that is easily accessible above the tracks. High RPM (low torque) goes into the center and very low RPM (higher torque) comes out the edge. This takes the high torque off a central axle and puts it into a hub that can be fixed more easily. It just needs to be securely fastened to the track carriage. All analogous to electronics, plumbing, etc.

ManAtWork · 2019-12-10 15:36

Mickster wrote: »

EtherCat ...

Eliminate the long encoder/resolver cables.

Hmm, sounds good at the first moment but in practice it's not all that easy. I doubt that wireless communication has enough bandwidth and reliability (at the same time! one of both is no problem) to serve multiple axes and hundreds of sensors in real time.

A power bus plus a (wired) communication bus is still a good idea. But this way you still need 2 cables to every (high power) device. One power cable plus two bus cables (shared with the next device). It's cheap as long as you can use standard RJ45 patch cables. But those industrial ethernet cables with 8-pin M12 connectors are really expensive. You need those in dusty or wet environments like CNC machines.

That doesnt matter much for big machines costing $100k+. But for small desktop machines with servos in the 100W to 1kW range it's all too complicated.

I'd prefer a single cable to the motor with both motor power and encoder signals. And all the electronics in one box. You can put that under the table where there are (hopefully) no chips and coolant or if that's not possible you only pay for one water tight cabinet.

K2 · 2019-12-10 15:45

Reinhard wrote: »

I have planned to use the P2 as DSP - like applications
First to make digital filters, like this:

'	IIR Highpass 1. Order
'	y[0]   = A[0] * x[0] + A[1] * x[1]  - B[1] * y[1]
'       out    = B[0] * y[0]

dat
	org
	mov		xx0,#0					'x[0]
	mov		xx1,#0					'x[1]
	mov		yy0,#0					'y[0]
	mov		yy1,#0					'y[1]

input
	mov		sample,##$4000			'come usual from adc (16bit)	

filter
	mov		xx0,sample
	
	qmul	yy1,B1
	qmul	xx1,A1
	qmul	xx0,A0
	getqx	T1
	getqx	T2
	getqx	T3
	sar		T1,#16
	sar		T2,#16
	sar		T3,#16
	
	add		T3,T2
	mov		T4,T3
	sub		T4,T1
	mov		yy0,T4
	mov		xx1,xx0
	mov		yy1,yy0
	
output
	mov		out,yy0						'go to dac (16bit)
	jmp		#input						'loop forever

										'filter coefficients
A0	long	$f831 							'0.9695
A1	long	$ffff07cf 							'-0.9695
B0	long	$10000 							'1.0
B1	long	$ffff0f98							'-0.9391

xx0		res	1
xx1		res	1
yy0		res	1
yy1		res	1
T1		res	1
T2		res	1
T3		res	1
T4		res	1
sample	res	1
out		res	1

I am already waiting impatiently for P2 hardware.
The results of a SIMULATION look very good.

Very impressive! Thanks for the demo code.

Mickster · 2019-12-10 16:50

ManAtWork wrote: »

Mickster wrote: »

EtherCat ...

Eliminate the long encoder/resolver cables.

Hmm, sounds good at the first moment but in practice it's not all that easy. I doubt that wireless communication has enough bandwidth and reliability.

The remote processors are kinda self interpolating. Let's say I want a vector position of x=2000, y=4000.

My trajectory generator is running at 2KHz.

I issue a global command "go"

For each generator update, the X is incremented by 1 count and the Y is incremented by 2 counts. Voila, I have linear interpolation.

Meanwhile the path buffers are being filled, via wireless comm's. We are talking updates on the order of 30/60/120Hz.

This translates in to real-world resolutions that are beyond practical.

kuba · 2019-12-12 18:26

Since EtherCAT is patented, you have to jump through Beckhoff's hoops to get a license, and to the best of my knowledge these hoops make the approval of a new ESC (EtherCAT Slave Controller) for something boutique/low volume like P2 impractical at best, and IMHO it's not gonna happen. That's kinda sad because e.g. we have spent some resources to develop an EtherCAT slave for XMOS, and had to abandon the EtherCAT-ness of it since it was impossible to license the patents. At least we learned how to do wire-speed processing, so that's useful for other things.

It seems that Beckhoff has a very manual compliance testing process; last time I heard from them they could compliance test like 1.5 ESCs per year. It was a few years ago though. Maybe it's better now? The best I can tell, doing EtherCAT on P2 is not feasible unless there are official statements otherwise, since if you attempt to sell anything that contains such an implementation, Beckhoff as the patent owner can go after you. If this implementation was used only within a machine, and not exposed to the end-user as an aspect of the product, then it might be iffy but feasible, while still exposing you to liability. It's still using the patents without a license (and the license will not be issued without passing compliance tests first, AFAIK). But perhaps it's a safe assumption that Beckhoff has bigger fish to fry than chasing down OEMs who use ECAT internally as an implementation detail only.

But it's all a bummer. We need a modern open-source communications protocol for realtime industrial stuff. All those patent-encumbered things are a serious barrier to interoperability. It used to be that Beckhoff would shut down open-source ECAT master projects, which were made simply to use EtherCAT slave devices - something that Beckhoff should be encouraging. At the moment such projects exist, but it's not clear at all what Beckhoff's position is on those (unless I missed some announcement). I have an extremely sour taste after my experience with ETG, and that's very regrettable, because at the low level, ECAT is a well-engineered protocol and was groundbreaking when it was first developed.

Given the performance of modern microcontrollers and even low-range FPGA's, you might just be rewriting JSON at wire speeds and just laugh at the binary protocols - they only come handy when you need to absolutely wring out the last bit out of the image sent down the wire. That's not a necessity when getting a 2nd ethernet port is so cheap. If you got spare bandwidth, then passing along a JSON object and operating on it at wire speeds works perfectly well for my needs. A web browser can be a non-realtime master for this. Cool, eh?

Mickster · 2019-12-12 21:19

TwinCAT/EtherCAT

Beckhoff did one heck of a marketing job with such overcomplicated garbage.

Reinhard · 2019-12-17 17:49

profbraino wrote: »

Now that the P2 is available, what are some of the things you plan to use it for?

That is, what application is the P2 best suited for, and what makes P2 the best choice, over some other microcontroller option?

Thanks for you responses.

I see the following applications:
- Signal generator for the electronics laboratory
- DTMF receiver
- Audio Signal Processing
- Spectrum analyzer
- Rotation angle detection
- Picture processing
- Education
.
.
.

Reinhard · 2020-01-26 11:38

for my electronics laboratory I need a device that can measure phase differences.
I thought of the P2 and something like that:

/*
 * Application          Phasor Measurement Unit
 * 
 *  -cos(wt) -->__________________________________________
 *             __________________                        |
 *             |                |                    ____|___________
 * sin(wt) --> |   D.U.T   F(jw)| -- sin(wt + a) --> | Vector OP    |
 *   |         |________________|        |           |______________|
 *   |                                   |                      |  |
 *   |                                   |                      |  |
 *   |                                   |                      |  |
 *   |                                   |                      |  |
 *   |                              _____|_____                 |  |
 *   |                             |           |                |  |
 *   |                             |    FIR    | -->  cos(wt+a)--  |
 *   |                             |___________|                   |
 *   |                                                             |
 *   |_____________________________________________________________|
 *

 *              ________________
 *   sin(wt) -->|              |---> a' == a
 *   -cos(wt)-->|   Vector     |
 *  sin(wt+a)-->|     OP       |---> Phasevector
 *  cos(wt+a)-->|______________|
 * 
 *  
 * FIR
 *              __________ 
 *              |        |
 *  sin(wt+a)-->|    -1  |_________a1__
 *      |       |  z     |             \
 *      |       |________|              + ---> cos(wt+a)
 *      |__________________________a0__/
 * 
 *

D.U.T. can be an linear analog circuit or a mic/headphone combination.
The fist prototype is running.
Reinhard

koehler · 2020-01-30 08:30

Its too bad the P2 can't do some sort of Powerline protocol with its unique resources.
Impossible I guess...

What is an "ideal application for P2"?

Comments