Thoughts on designing a new controller

Hardware Electronics
101

Since it’s off-topic, I won’t go in to great detail but I think you’re not understanding the constraints of real-time, -live- broadcast quality, HD video from the broadcast/satellite world. Think CNN, BBC, Fox, Superbowl, World Series etc. I wasn’t referring to streaming static files in a PC context.

Consider, for a moment, a single stream moving 60 frames per second of video and audio through paralllel audio/video transcoding paths and maintaining lip sync and clock sync accuracy that varies less than +/-500ns (unique clock per stream), delivered over UDP with no opportunity for loss or delay. Then do that scaled across 36 inputs at 54 (or more) megabits per second each (1,944 megabits/second total on the input) and deliver the live output at 36 x 19.4 Mbps (698 megabits/second). The system is moving ~2600 megabits/second (spread across multiple network cards and IRQs) in an environment -extremely- sensitive to jitter and loss. The system needs to perform without losing a single 188 byte frame of data - 24/7/365. And each individual stream needs to be able to be stopped, started or modified without the stop/start impacting any of the parallel streams in any way. As well any stream on the input may be mildly or heavily impaired without warning due to signal impairment in the upstream transmission path (like rain fade or satellite transponder malfunction, or an originating piece of equipment hitting a bug). To make things more interesting consider that hardware inputs other than ethernet also need to be supported for these live signals, like satellite reception, off-air antenna reception, or legacy digital transports like ASI (serial interfaces than typically running up to 108 Mbps or more).

Not to mention actually transcoding the video payload from MPEG-2 > MPEG-4 compression for all streams as well as transcoding 1-4 live lip-sync audio streams -per- video stream and re-multiplexing them back together in real time, as well as doing filter and transform operations on the various sub-payloads of the overall transport stream. While doing this, also provide an interactive web interface for configuration and live status monitoring and alarming for seven different conditions of each stream. I think you get the idea. There is also sub-title burn in considerations and ad splicing/program substitution scenarios to consider.

Many firms use a RTOS to help achieve that, but the load conditions described above are being met 24/7/365 on systems with a single (older generation) i5 class CPU running a fairly stock Debian Linux base, slightly older kernel, booting from flash and running from RAM disk. This is achieved (and this is a mature commercial product) with efficient parallelization of the video specific code, dedication of specific cores to various functions and careful tuning of low level hardware and OS parameters like IRQ balacing, buffer and queue depths, network driver configurations optimized (but stock drivers otherwise) etc. As challenging as CNC is (which also doesn’t run 24/7/365) ,
I would humbly suggest the Maslow does not represent higher real time load or precision demand than likely one to two of the kinds of streams described above, let alone an entire system.

-Jeff

102

Would a stepper driver for the Zaxis need to be configured for microsteps?

103

I came across this the other day and thought it could be super helpful if Maslow ends up going in the Raspberry Pi direction. This allows you to very quickly and visually build a base image for distribution including auto scripting file downloads etc if necessary and issue an image. Super easy to customize. I suspect other maker minded folks here would also benefit from it: https://www.pibakery.org/

-Jeff

104

not necessarily (although 1/2 step microstepping may make it quieter)

common steppers are 200 steps/rev, with fairly common lead screw of 8 revs/inch,
this is 1600 steps/inch or 0.000625" per step (0.016mm/step)

even if you were to go to a 2 rev/inch lead screw, this is still 0.0025"
(0.0635mm) per step.

so you don’t need microstepping for accuracy.

David Lang

2 Likes
105

I “designed” a controller board using diptrace (free) that has 5 tle5206 and 1 pololu dvr8825 driver centered around a teensy3.5 (what I’m currently using for my four motor design). I’ve never designed a pcb and have not done any real electronics design in over 25 years. Unfortunately I had to make it 4-layer because I couldn’t get big enough traces for power/gnd… but others are likely more talented than I and might have a better way. I’ll post it to my github repo tomorrow if anyone feels inclined to look at it and give me feedback. It’ll cost me about $120 to make 10 so would appreciate any pointers.

5 Likes
106

I work at MacroFab. Let me know if you want we to run a proto before you place a big order. I can have some wise eyes review as well.

4 Likes
107

@madgrizzle I would love to take a look at it. Nice work!

@cmullins70 MicroFab looks awesome. I’m going to keep you guys in mind too. I’ve been looking for a good PCBA solution

1 Like
108

I’m trying to figure out how to package it up. I can post the files from diptrace but not sure if it will just ‘work’.

1 Like
109

Can’t guarantee what it will look like or if it will find the libraries (new to using diptrace).

Here’s a link to diptrace if you are inclined to download the free version… It’s weird that its only 144 MB in size… I didn’t think any Windows program these days could be smaller than 1GB.

2 Likes
110

Can you get a ODB++ out? If so you can just drag and drop onto the new pcb screen. Otherwise you can manually upload gerbers + excel or csv BoM.

111

I’ll check. Is the Excel/bom file required for just the plain board?

112

I don’t think you can do plain boards. We’re you going to hand assemble? You might be surprised at how cheap assembled boards can be, especially on the prototype service.

113

Yeah, was planning on hand soldering (everything is through hole)… I’ll see about a bom

114

I’m making progress on getting it into the macrofab system. I’m going to do some revisions to the design to put headers into the schematic (I planned to use them for the teensy and the stepper controller to plug into) so they appear in the bom correctly.

4 Likes
115

Would it be safe to say that if you want assembled boards you should strive for surface mount? It appears the labor on the through-hole boards is too much. I’m at $300 for the prototype… $25 of it is for labor of soldering the headers for the teensy. I assume surface mount labor is much lower since its just put in an oven?

1 Like
116

Not direct control, but Waveshare sells a motor control hat (schematic) that uses a PCA9685 I2C LED control chip to send PWM to an L298 to control two motors.They’re basically using it as a multi-channel I2C IO expander with per-pin PWM capability. :+1:t2:
The TLC5947 and TLC59711 are SPI chips with similar PWM functions. Adafruit sells boards using those chips (for dev., use a 220-ohm current limit resistor in line with the PWM signal).

2 Likes
117

Edit: All references to Web Ground Control in this post were based solely on my assumption of how it probably works based on nothing but the name, and I probably didn’t even get that right. So assume I am talking about some future hypothetical version that goes with the rest of the system I described.

I agree with @madgrizzle and will go a bit further.
First some background info https://www.socallinuxexpo.org/sites/default/files/presentations/Steven_Doran_SCALE_13x.pdf

Unless R Pi has changed to include a deterministic microcontroller like the 2 PRU 32 bit microcontrollers on beagle boards, the R Pi is inappropriate as a low level controller and would require an additional small microcontroller like the Arduino situation is now.

The needs of maslow motor control PID loops fit within much more modest microcontrollers. The only reason (and it is a valid reason) to move up to a SBC(Single Board Computer) is to gain additional ways to connect it to Ground Control or Web Ground Control via WiFi, Ethernet, USB, UART, Bluetooth. If we make that jump to SBC, the community will reasonable expect that all those options will eventually be supported. Is that a can of worms we are ready to support? I would like the answer to be yes, but I would not like to be actually doing the support.

I’ve seen SPI mentioned, but that is a chip to chip protocol intended for traces on a single board. The capacitance and length of cables make it unreliable outside of that. Yes, there are plenty of examples were it worked. Lucky them, does not mean it should be used that way inside a product.

On the surface, ESP32 WiFi equipped microcontrollers seem like the ideal low cost simple solution. I’ve had a chance to use some recently and while they worked, they were extremely unreliable, full of quirks. I would not trust them unless the goal is to produce end user frustration.

Converting a drawing or CAD file to something that can be consumed by maslow should be done on the fastest machine at the user’s disposal, whatever that may be. AWS, Android, iOS, Pi, Windows, Linux, ReactOS, a data center in your basement, whatever. WebGC provides a nice fallback that runs on everything without developing for specific targets, but there should always be at least 1 officially supported local Ground Control option for at least 1 platform with source code published so community can build for alternative platforms.
The main user interface should be OS agnostic. Don’t make someone learn a new os to use a woodworking tool. I never had to learn Fortran to use a Skillsaw. Don’t force someone to do post processing on a R Pi when they have a monster with Quadro GPUs at their side.

Whatever machine runs Ground Control, it should que up a list of moves. It should be able to send manageable chunks of that list wirelessly to the motor control/microprocessor mounted to the maslow, possibly in a different room. The maslow onboard controller should handle all PID loops locally and reports list progress, ready status, errors, button pushes, touch off points, calibration requests, etc. back to GC. Before maslow onboard controller reaches end of list of moves it has in RAM, it requests a new batch from GC, or from SD card if the entire routine was stored there. This allows Ground Control to serve as a full featured interface panel with machine simulator showing feedback from maslow onboard controller, or to serve as simple upload to SD, start, then disconnect type of use case.

For an example of the type of motor controller that can accept a list of planned moves, they call it a “Motion Profile” http://www.ctr-electronics.com/talon-srx.html
They receive constant development, have a worldwide user base and have been very reliable. If these particular controllers aren’t used, I suggest whatever is used be made compatible with the format of their MotionProfileGenerator.xlsx tool and share some parts of the published API. That way we have a known working solution to compare to whatever we develop. And we would have something already familiar to a large base of FRC users.

1 Like
118

@madgrizzle the only thing proprietary about the teensy is the bootloader, which comes on a preprogrammed chip for $6.95. https://www.pjrc.com/store/ic_mkl02.html The schematic is available and reference board is on OSH Park, so it can be done completely without pins. Teensy can be built right onto the motor controller board. I like teensy a lot, but it requires the teensy loader app to run on the host machine. That makes it a bit more complicated for the end user than Arduino Mega. Did you have a plan for dealing with Teensyduino?

1 Like
119

Unless R Pi has changed to include a deterministic microcontroller like the 2
PRU 32 bit microcontrollers on beagle boards, the R Pi is inappropriate as a
low level controller and would require an additional small microcontroller
like the Arduino situation is now.

This is only true if there is a requirement in the software for tight time
bounds on the responses to signals or on the timing of generating signals. If
instead of having to count pulses for encoders, you query the current position
of the encoder and then adjust your PWM signal, it doesn’t matter that much if
you change the PWM signal a few tens of ms later, the next cycle through the
loop will work to correct your error. At the slow feed rates we have, this isn’t
going to be a significant amount of movement.

The needs of maslow motor control PID loops fit within much more modest
microcontrollers. The only reason (and it is a valid reason) to move up to a
SBC(Single Board Computer) is to gain additional ways to connect it to Ground
Control or Web Ground Control via WiFi, Ethernet, USB, UART, Bluetooth. If we
make that jump to SBC, the community will reasonable expect that all those
options will eventually be supported. Is that a can of worms we are ready to
support? I would like the answer to be yes, but I would not like to be
actually doing the support.

the idea is to make something like WebControl be the default method of control
for the new systems. no need for USB, UART, Bluetooth, just wired and wireless
networks.

I’ve seen SPI mentioned, but that is a chip to chip protocol intended for
traces on a single board. The capacitance and length of cables make it
unreliable outside of that. Yes, there are plenty of examples were it worked.
Lucky them, does not mean it should be used that way inside a product.

tell that to the encoder manufacturers that list SPI as their mechanism for
interfacing with encoders (which are seldom traces on a single board), but a
number of them use RS422/RS485 signaling for noise immunity.

On the surface, ESP32 WiFi equipped microcontrollers seem like the ideal low
cost simple solution. I’ve had a chance to use some recently and while they
worked, they were extremely unreliable, full of quirks. I would not trust
them unless the goal is to produce end user frustration.

what is the problem with them?

Converting a drawing or CAD file to something that can be consumed by maslow should be done on the fastest machine at the user’s disposal, whatever that may be.

nobody is suggesting that CAD or CAM should be done on the controller, you
upload the g-code file to it, not the model.

but there should always be at least 1
officially supported local Ground Control option for at least 1 platform with
source code published so community can build for alternative platforms. The
main user interface should be OS agnostic. Don’t make someone learn a new os
to use a woodworking tool.

so why would a WebControl with source code not be acceptable, that is far more
OS agnostic than GroundControl is?

Don’t force someone to do post processing on a R Pi when they have a monster
with Quadro GPUs at their side.

nobody is suggesting that they should, where did you get this idea?

Whatever machine runs Ground Control, it should que up a list of moves. It
should be able to send manageable chunks of that list wirelessly to the motor
control/microprocessor mounted to the maslow, possibly in a different room.
The maslow onboard controller should handle all PID loops locally and reports
list progress, ready status, errors, button pushes, touch off points,
calibration requests, etc. back to GC. Before maslow onboard controller
reaches end of list of moves it has in RAM, it requests a new batch from GC,
or from SD card if the entire routine was stored there. This allows Ground
Control to serve as a full featured interface panel with machine simulator
showing feedback from maslow onboard controller, or to serve as simple upload
to SD, start, then disconnect type of use case.

that’s actually a far more sophisticated interface to the controller than just
about any CNC machine (not just hobby ones). CNC machines either load the entire
g-code file and run it, or they accept the g-code a line at a time and process
it.

no batching of messages, etc. grbl breaks the g-code down into sub-movements and
plans those sub-movements

For an example of the type of motor controller that can accept a list of
planned moves, they call it a “Motion Profile”
CTR Electronics They receive constant
development, have a worldwide user base and have been very reliable. If these
particular controllers aren’t used, I suggest whatever is used be made
compatible with the format of their MotionProfileGenerator.xlsx tool and share
some parts of the published API. That way we have a known working solution to
compare to whatever we develop. And we would have something already familiar
to a large base of FRC users.

I’ll start by pointing out that these motor controllers can use an SPI
interface :slight_smile:

I don’t see the value of their spreadsheet, just specify the max acceleration
and max speed (and any other parameters needed) and let the motor controller
generate whatever it needs, no need to enter a large table of numbers, let alone
this cryptic spreadsheet to generate them.

David Lang

120

Well, Im developing a concept of a 4 motor maslow and chose the teensy 3.5 because of the raw hp, number of gpio and pwm pins, and being 5v tolerant. I need the horsepower of the teensy to try to do some floating point computations mid PID loop (which may or may not be needed). I don’t think the mega can keep up. But in the end, I won’t be productizing my design. Everything I’m doing is for testing purposes and I personally don’t plan to productize my work. But, I’m not doing anything special that some other microcontroller can’t do.

1 Like