Yet another controller board

Good idea, the requirements are different from a CNC machine where you prefer to have each axis homed individually so as not to distrubt each other when the end stop is tripped. In a motion rig you need to think about the person sitting in the chair whilst homing.

Yes, under normal conditions you only have to execute the homing once per session when you switch the controller on for the first time. We have the main switch outside, at the control cabinet at the rear of the rig. So nobody sits in the cockpit. But if you have to recover from an emergency stop, power failure or any other type of error condition you should also be able to execute the homing while sitting in there.

Yesterday, we installed the controller with the new 3D printed casing. The ratsnest of wires hasn't got much better but it looks a bit cleaner and is at least safe to operate.

The improved homing procedure also works quite well. The controller currently has no online/offline switch but instead cross fades the position automatically from the parking position to the center position when FlyPT Mover connects. This folows the rule "make it as simple as possible". But probably a door switch would be even better. The rig would then go down to the parking position automatically when the door is opened without the need to flip a sepearte switch or to disconnect the Movoer output.

@Motion4Sim I just saw this video. Can you explain a little more in detail what has changed in the new firmware and what you did to improve smoothness? I still have one of your controllers. (It's on the marketplace but nobody has bought it, yet) Maybe I'll use it for the heli project...

BTW: I have AASD servos from @Klaus Schmidinger so no trouble to be expected, this time.

Update: I've made a new PCB layout which has 6 instead of 5 outputs for servo axes. The boards have just arrived. I'll assemble at least two for my own 6DOF rig and Sven's next heli sim. But if anyone else is interested I could make up to 5.

I've just assembled 3 boards.

Sorry for resurrecting an old thread but I've only just found it and wish I had discovered it a few months ago!

Long story short, I've been designing and coding my own (non-commercial) AASD controller board based on an ESP32 S3 using the MCPWM hardware units (basically hardware timers). I've learnt a lot doing it (which was my main driver for developing my own) and enjoyed the process but I've got a couple of questions I was hoping @Aerosmith and @Motion4Sim might be able to help me with.

1. Do you just run the servos at full speed all the time? Doesn't this mean that the motion can get jerky if the travel distance is very short? I'm thinking that if the servo moves to position more quickly that the ~2ms frame time for position data then it could be in a stop position until the next frame comes in, i.e. constantly stopping and starting. Is it better to calculate the speed required for each move between frames (or some filtered value) and adjust the pulse train to the servos (i.e. the speed) to match? Or does this not make any difference in the real world?

2. I am getting some significant but consistent overshoot when moving the servo at higher speeds. I think this is due to the feed forward and position deceleration settings on the AASD driver, however most people seem to have those enabled and don't suffer any issues. For my testing I'm sending (e.g.) 100,000 pulses to the motor and then stopping it dead (by turning off the pulses). It doesn't matter how many pulses I send (10,000 for 1 revolution or 100,000 for 10 revolution), the overshoot amount is always the same for a given speed. It's nearly zero at 100kHz but 5-10 degrees at 500kHz. How do you prevent this from happening or otherwise deal with it in code?

3. I'm using FlyPT Mover as my source of position data. I've assumed that it takes care of filtering and motion smoothing (i.e. ramp up and down ) so I don't need to do any of that in the controller. Is that correct or do I need to do some smoothing and filtering in the code?

Thanks in advance for any pointers you can give!

Thinqer.

@Thinqer77 You're welcome. Designing something on your own can be really challanging but also quite satisfying. You definitely learn a lot.

You can in fact output all movements as a series of step pulses at constant (max) frequency.The command input low pass filter of the servo will smoothen this to some degree so that the motor will not accelerate to full speed and decelerate each 2ms interval. A stepper motor couldn't do that and would stall immediately or at least run very rough. So adjusting the step frequency for minimum velocity discontinuities is much better and results in a more smooth and quieter running of the motors.

I made a presentation how my controller works in the Parallax Propeller Live Forum. Apart from the general theory of how a motion simulator works I talk about the motion algorithms that are used to calculate the output signal frequency for a given position command input. The basic ideas are:

• Calculate the current velocity based on position difference divided by time difference for each 2ms interval and use that for the frequency of the step/dir signal (explanation around 22:50 in the video)
• Let FlyPT Mover do the filtering so most of the time the servo just follows the command (that answers question 3)
• Exception: The commanded velocity or acceleration exceeds the capabilities of the hardware. Then the controller limits velocity and/or acceleration by clipping. I explain that with the car race analogy at 34:13.

Sorry for my bad English. I also apologize for my criticism of the Motion4Sim controller. We had some problems at that time which lead to me designing my own controller. But the M4S controller has also been improved since then and runs much smoother, today. So my criticism is probably no longer justified.

I think that is caused by the tuning of the AASD controllers. The factory setting is set to a rather low gain so that there is no tendency for oscillations independent of the mechanical setup (load inertia ratio). This makes installation and operation easier for unexperienced users but has the drawback that the response of the servos is quite sloppy, I mean there is delay and overshoot especially for high accelerations.

You have to tune the control parameters inside the AASD controllers to mach your mechanics and optimize them for increased stiffness and minimal delay and overshoot.

I just read your question again... If you send a burst of pulses with a constant frequency and no ramp-up or down you get overshot, of course. The motor can't follow an infinite acceleration command, e.g. a sudden jump from zero velocity to max. velocity and back. It has inertia and only limited toque.

To avoid overshoot you need to limit the acceleration by adding ramps. Say, instead of starting with 100kHz immediately you output 5, 10, 15, 20, 25... 95, 100kHz for the first 20 intervals.

You don't have to care about that if the commands come from FlyPT Mover as the filtering is already done, there.

Hi everyone,

I just got a notification that I was mentioned here, so greetings to all
Very interesting topic, and I can definitely relate to it.

I’ve also developed my own controller based on the ESP32, capable of driving AASD servo drives with up to 500 kHz pulse rates using hardware-based full-speed pulsing.

Here is a short video from back then:


Back at that time, the main limitation was that with a single ESP32 I could reliably drive only one, maybe two servos at full speed (500 kHz–1 MHz). More than that simply wasn’t feasible on one ESP. Because of this, I eventually abandoned the project.

It worked reasonably well, but there were additional issues—especially synchronization and sharing USB Voltage over the boards, since I ended up using one ESP per servo. I don’t think I was using the hardware timers properly at that point; there were some issues I never fully resolved. One would have to look at the old code again to see why that approach failed.

What actually worked best was misusing a hardware UART and sending the pulses through that.

Ramps, filtering, and AASD behavior
In principle, it is of course correct to use acceleration and deceleration ramps. However, it’s important to understand that AASD drives already do this internally when using position mode.

That means:
If you send a burst of pulses, the drive itself will internally generate a ramp. It will accelerate smoothly, run, and then decelerate again.

This also explains an important side effect:
If, within your 2 ms control frame, you only send a small number of pulses, the motor will start moving and then stop again. This is exactly why filtering on the command side is so important.

If your hardware allows you to generate different pulse frequencies independently on all channels, then it absolutely makes sense to distribute the pulse count evenly over the frame time and continuously adapt the frequency. That results in much smoother motion.

Overshoot issues
If you are seeing overshoot, that is not caused by the pulses themselves.
The pulses define where the servo should go. The actual motion behavior—including overshoot—is determined by the drive’s internal control loops and parameters.

In most cases, overshoot means:

• The Feed-Forward Gain is too aggressive
  
  
• Or internal filtering/smoothing has been reduced or disabled

Below are the AASD settings we currently use, and I would strongly recommend starting with these for developing and testing your own controller:

• Pn109 = 1 → Smoothing enabled
  • 1 = Fixed smoothing
    
    
  • 2 = S-shaped smoothing
• Pn110 = 30 → Smoothing filter time
  
  
• Pn113 = 20 → Feed-Forward (%)
  
  
• Pn114 = 10 → Feed-Forward filter time (ms)
  
  
• Pn115 = 100 → Gain (%)

Once your system runs cleanly and stable with these values, you can start experimenting and fine-tuning.

Electronic Gear (important!)
Also pay close attention to the Electronic Gear setting (Pn98).
This parameter acts as a translator between your incoming pulses and the motor’s internal encoder positions.

We typically use:

• Pn98 = 2

With this setting:

• Each external pulse is multiplied by 2 internally
  
  
• You get 5,000 positions per motor revolution

If you set:

• Pn98 = 1, you get 10,000 positions per revolution

However, that also means you need double the pulse rate to reach full motor speed. Keep in mind that AASD drives support up to ~550 kHz maximum—above that, they will shut down.

@Aerosmith:
I noticed that you recently offered your rig for sale on Kleinanzeigen. Are you still running a motion rig, or have you built something new in the meantime?