ESC32 goes robotics

Info and Discussion about the ESC32 hardware and software

ESC32 goes robotics

Postby yang » Fri Jul 11, 2014 9:41 pm

I had some discussions with kinderkram in the FPV forum and he suggested to post my suggestion here in order to get your feedback.

I built a CableCam and want to start to automate its movement. ... -with.html

So I added a microcontroller which in turns creates the PWM signals for my Hobbywing ESC in order to move the CableCam to a given position. All works fine but not perfect and the ESC logic is the problem as I found out.

Hence I would like to add a few small-to-medium-complex functionalities to the ESC32 code. Interestingly all of them would make sense in other use cases as well. Not necessarily drones but airplanes, cars and robotic applications.

  • Change 1: Support forward reverse. If the RC stick is at +100 the motor turns at 100% in one direction. Move the RC stick in the other direction and motor will turn at full speed but in reverse.
  • Change 2: Support motors with Hall sensors for smoother startup and to enable rotation at extremely low rpm.
  • Change 3: Change the start logic. It should not simply start accelerating the motor until the minimum rpm is reached and then start with the brushless control logic, it should allow low rpm values as well.
  • Optional change 4: Merge servo and governor mode into one for absolute positioning. Turn the motor 20'000 times in order to move the robot/car from the current position to the target position. So the motor will start to accelerate slowly with a selectable max acceleration, until a max rpm is reached and then start decelerating to reach the target position precisely. For this control loop I have the STM32 code developed already and it is working.

With these changes I would think you can support more applications
  • Airplane can use very low propeller speeds with regenerative braking for speed braking
  • Airplan on ground can use a thrust reverse
  • Can be used for cars and robots to accelerate smoothly and drive at extremely low speeds
  • Robots would benefit from the governor mode where you define the rpm, e.g. 0.5 rpm. If the ground is not flat this might actually mean to do regenerative braking!
  • Robots would definitely benefit from the absolute positioning, move 10'000 steps forward and stop there. Today you use steppers which are very heavy, slow and have little torque especially at higher speeds.

Questions you might have:

Airplanes use Outrunners, there are no Outrunners with sensors ... 0kv-1500w/

ESC32 has no connectors for the Hall Sensor
I would suggest to solder the SWD connector and use its pins. I checked there are three pins on this connector that can be used as GPIO and trigger interrupts.

How should the Hall Sensor logic be implemented?
Very simple, instead of having Interrupts on the ADC to set the next commuting step, the Hall sensor pins trigger the interrupt. Actually, the best would be to have both, e.g. in case the Hall sensor cable got disconnected fall back to BackEMF.

How to avoid going from full forward to full reverse and hence overloading the hardware?
No problem to split that into two parts. Brake until 0 rpm, then switch the direction and start accelerating.

Without sensors there is no BackEMF at very low speeds
Just turn the magnetic field slowly, the same way the servo mode works I assume.

I am about to try implementing all of that myself, I familiarized myself with the source code and found all the places and variables. And I ported the code to use the CooCox IDE without the additional libraries. Does not work 100% yet, the status cli command hangs after printing half of the first line. sprintf() problem??? Anyway.

My fear is that if I do the changes it would take me longer than you for sure and I would produce a code branch that cannot be merged back to your development easily. And frankly it is a problem finding enough uninterrupted spare time.
So if any of you would tackle that for me, it would sponsor it. How exactly I don't know, at least I would buy you a motor with sensor for testing. And if you want join forces with me and get the parts for a cablecam from me, that would be a more than fair deal in my opinion.

Posts: 5
Joined: Fri Jul 11, 2014 8:27 pm

Re: ESC32 goes robotics

Postby kinderkram » Fri Jul 11, 2014 11:58 pm

Ah, the cable cam man! :D

Welcome to the AQ forums, Werner.
Looks like you got the hardware and gimbal part covered well. I thought the UltraESC in combination with a NanoWii and special MultiWii fw could do the trick. But dunno if they´re sufficient for bigger motors to carry some payload.
You know I´m not the expert around - but the upcoming ESC32v3 might be a candidate for your needs. ;)

Posts: 2911
Joined: Fri Jun 22, 2012 7:47 am

Re: ESC32 goes robotics

Postby yang » Sat Jul 12, 2014 7:32 am

Maybe I should explain what the current issue is for you to decide if this is something new or covered by the ESC32v3 - whatever that is.

I wrote a PID controller for absolute positioning. Input is the RC signal, output a PWM signal for the ESC. The PID controller knowes the current position, the target position, calculates the error, transposes that into a PWM signal and the ESC will drive to the target position. Everything fine.
For a PID controller to work flawlessy, the ESC would need to have a steady output curve. But it does not. At acceleration and holding the speed everything is fine. The more PWM signal the more energy, the faster it drives. But how do you brake with an ESC? By putting the stick in neutral or reverse even. This way you adjust the brake power. So the PID controller would not need to change the PWM signal to 50% throttle, it would need to go to neutral, wait until it decelerated enough and then go to 50% throttle again.
Another example, the car goes down a steep hill. So for 10% forward speed the ESC needs to brake with 30% force instead of having the throttle at 10% forward.

The ESC32's governor mode would be perfect for that, because now I can specify the rpm and the ESC does whatever it takes to achieve that speed. Apply more power, brake. But that would need to work not only from 300rmps to 30'000rpms but from 0 to 30000.
Posts: 5
Joined: Fri Jul 11, 2014 8:27 pm

Re: ESC32 goes robotics

Postby bn999 » Sat Jul 12, 2014 2:18 pm

If you need to actively brake to maintain requested RPM, then ESC32v3 would be the way to go as it uses active freewheeling. A reduction in output duty cycle automatically provides a large degree of braking due to the regenerative effect with using a battery as a power source. Your project sounds interesting - perhaps there is someone here that has the time to work on it with you.
Posts: 1559
Joined: Thu Jun 21, 2012 11:40 pm

Re: ESC32 goes robotics

Postby yang » Sun Jul 13, 2014 9:08 am

Thanks Bill, can you elaborate on that a bit?
My current understanding is that todays hardware revision and firmware code supports regenerative braking already (experimental). Now you are saying I need the new hardware. And for active freewheeling, isn't that just the combination the half bridges are turned on/off, assuming that practically all MosFets can deal with reverse power flows?
As it seems I lack some knowledge here....

Thanks in advance

btw, I cannot motivate you to help somehow, can I? The forward/reverse should be a piece of cake for you, low rpm would be the most difficult one I assume.
Posts: 5
Joined: Fri Jul 11, 2014 8:27 pm

Re: ESC32 goes robotics

Postby bn999 » Mon Jul 14, 2014 3:12 am

The braking feature of ESC32v2 is not well tested and some people have reported problems with it. I would not count on it working for you.

Yes, the active phase's low side FET is turned on when the high side is turned off instead of just letting the phase float. This gives a low resistance pass for the freewheeling current back to the battery instead of having to go through the body diode.

I have too many projects going to take on a new one at this time.
Posts: 1559
Joined: Thu Jun 21, 2012 11:40 pm

Re: ESC32 goes robotics

Postby LPR » Mon Jul 14, 2014 2:02 pm


Have you looked at this type of ESCs. ... oRockC.htm

Posts: 1323
Joined: Tue Jun 26, 2012 1:29 pm
Location: MN, USA

Re: ESC32 goes robotics

Postby yang » Mon Jul 14, 2014 2:22 pm

Yes, this goes into the proper direction but first it is for brushed motors - their brushless line does not seem to have such as well - and it lacks the absolute positioning I added as extended goal. Thanks for the tip, though!
Don't get me wrong, my Hobbywing brushless ESC is quite good as it supports rock crawlers as well. It is just not the last step towards perfect and I cannot extend its firmware with absolute positioning, need to do that externally. Nothing wrong with that but both together caused me to ask and investigate.

btw, there are products available to buy, they are not optimized for RC equipment, large and expensive.
Posts: 5
Joined: Fri Jul 11, 2014 8:27 pm

Re: ESC32 goes robotics

Postby yang » Mon Jul 21, 2014 9:00 pm

I have started to make my first changes in the code. Basically it is a mixture of the servo mode and the startup sequence with START_STEPS_NUM.

In RPM mode the startup sequence does the align but stops here. ESC state remains in ESC_STATE_NOCOMM. When I now enter the command rpm 1, the runRpm() method starts rotating the field using the servo logic. Once it reaches 100rpm, I would start with the commutation and bring the state in ESC_STATE_STARTING and therefor RUNNING. And if the rpms are set below 100, I am back in the NOCOMM logic.
That's the idea, it is not working yet. Some sideeffect I haven't found yet. From my point of view I am still in the NOCOMM state and hence the behavior should be the same as what the servo mode does. Align the motor and then increase the degrees. Need to find out why it is not. At the moment imemdiately after the ALIGN the motor starts making high frequency noises, the rpm in the status screen is 25'000 and although the fetServoAngle is increasing slowly, the motor does not turn. As said, from my point of view I am doing the same thing as the servo mode does. Obviously there is something overriding my fet settings which doesn't when mode=ESC_SERVO_MODE. Will find out.

Other issues I have with my CooCox development environment
* in one out of 10 compilations the serial port does not work. Not even the first serialPrint() does something. ESC Led is toggling, so systick works and the initial fetbeep is produced as well. No idea.
* Had major issues with the gnu compiler around stdio and floats. At the moment I am using the full C library and everything works here except the sscanf(). for example I can successfully execute the command set FF1TERM 1 or FF1TERM 2.0 but a FF1TERM 1.1 does cause the ESC to freeze, a value of 2.4e-8 of course as well. I have no idea. As setting the FF1TERMs manually is time consuming anyway, I had modified the defaults instead for now.

Next step, once above works, would be to check if the transition from NOCOMM to fetStartCommutation() works smoothly. But should as it is in the regular startup sequence as well. But the way back to NOCOMM will be harder, I need to find out the starting angle.
The SERVO_DUTY config value concerns me a bit. If it is too high it will overheat the FETs and the motor, I assume. If it is too low it will not create enough momentum to start the motor. Keep in mind, my use case is not a propeller but a car like application. Much more resistance or even a full blocking motor in worst case.

The space vector and sinusoidal field implementation might be worth implementing for regular commutational movement as well. But then the RUN_FREQ needs to be increased, 2kHz is not enough steps at high rpms. I am not sure I am brave enough to do that myself. But frankly, this is actually all I am trying to implement. A rotating space vector aligning to the BackEMF communtation commands and if the BackEMF is too low, keep rotating the field at the targetRpm value.
Posts: 5
Joined: Fri Jul 11, 2014 8:27 pm

Re: ESC32 goes robotics

Postby volatile666 » Sun Mar 08, 2015 1:43 am

I dont want to hijack this thread but my use case seems to be the same so Ill post here:
Id like to use brushless motors in a robotic enviroment too. For that I need powerful yet reasonably priced hardware thats able to do FOC and read encoders, resolvers or something similar. I couldnt find information or plans about that in ESC32 except in this thread...
Is there anything I missed?
Should I buy an ESC32v2 for development or wait for ESC32v3?
yang, could you tell me about your progress on this topic?
Thank you everybody!
Posts: 2
Joined: Sun Mar 08, 2015 1:23 am

Return to ESC32

Who is online

Users browsing this forum: No registered users and 2 guests