Hi everyone, I’d like to ask for some advice: I want to install a flight controller on this vehicle—what other parts do I need to buy? Do I need an ESC? If so, how do I connect the ESC to the motor?
I’ve provided a video below; I’d appreciate any guidance or feedback. Thanks!
Hi Rik,
I watched your video. Since this is a wheeled robotic platform rather than a multirotor, I would first identify the existing motor and motor-driver hardware before purchasing additional ESCs.
An ESC is not automatically required. The correct solution depends on whether your motors are brushed DC, brushless DC, or another type, and whether your existing motor controller accepts a suitable control signal.
A few questions that would help narrow this down:
Could you share the exact motor model and the specifications of the existing motor-driver board?
Are the left and right wheels independently driven, and how is steering currently implemented?
Are you planning to use PX4 specifically, or would ArduPilot Rover also be an option?
What level of autonomy are you targeting: RC control, waypoint navigation, or obstacle avoidance?
I would recommend documenting the existing electrical architecture first: battery → motor driver → motors, including how the motor driver receives its control commands.
Then we can determine whether your flight controller can interface with the existing driver or whether additional hardware is actually necessary.
There is no reason to replace a working motor-control subsystem before establishing its interface requirements.
Hi yigitcan
Thank you very much for your reply. Yes, this is a wheeled robot platform; there may have been an issue with the translation software, as my description was translated as an “aircraft.” I want to configure it as a standard RC car (rear-wheel drive) using PX4 firmware. I have already removed the other sensors, and the remaining components are as follows:
1、Two MG513 motors (with Hall encoders)
2、One Pixhawk 6C Mini
3、One SBUS receiver
4、One S20F servo
I will now answer the questions you raised:
1、The motor model is the MG513 (with Hall encoder). I want to use the signal output from the Pixhawk 6C Mini to drive the motors, but I likely need to purchase two modules (Fire Phoenix ESCs) to facilitate communication between the motors and the flight controller. I am considering buying the modules shown in the image below; would this be feasible? I would appreciate your advice.
2、The left and right wheels are driven independently, and the steering system is controlled by a servo
3、I intend to use PX4 firmware.
4、Currently, I only need to implement remote control functionality.
To better illustrate my issue, I have taken some photos showing the current state of the vehicle.
I look forward to your suggestions. Thank you!@yigitcan-ozturk
Hi yigitcan
I look forward to hearing from you. Thank you!
Hi Rik,
Thanks for the additional information and photos. The configuration is much clearer now.
Based on your description, I would configure this as an Ackermann-type rover, not as a differential rover. You have two rear drive motors providing propulsion, while the S20F servo provides the steering. PX4’s Ackermann rover support is suitable for this type of arrangement even if the mechanical steering geometry is not strictly Ackermann.
For your first objective — RC control only — I would keep the system as simple as possible:
SBUS receiver → Pixhawk 6C Mini → motor controller(s) + steering servo
The Pixhawk should not drive the MG513 motors directly. The MG513 is a brushed DC geared motor, so you need a suitable brushed DC motor driver/controller between the Pixhawk and each motor (or one dual-channel controller).
Regarding the Fire Phoenix modules in your photo: I would not purchase them yet solely based on the information shown in the picture.
Before choosing them, I would verify three things:
Do they accept a standard RC/PWM command signal compatible with the Pixhawk output?
Do they provide bidirectional motor control (forward/reverse)?
Can they safely handle the stall current of the MG513 motors at your battery voltage?
The third point is especially important. The normal/rated motor current is not sufficient for sizing the driver; the controller must tolerate the much higher startup/stall current.
There is also another approach worth considering. PX4 currently has support for the Hiwonder 4-channel encoder motor controller, including an I2C driver (hiwonder_emm) for brushed DC motors with encoder feedback. That could provide a more PX4-native integration path than using two generic motor controllers.
For the initial RC test, however, I would not introduce encoder feedback yet. First establish a minimal open-loop configuration:
Flash the PX4 rover firmware onto the Pixhawk 6C Mini.
Select Generic Rover Ackermann (SYS_AUTOSTART = 51000 if needed).
Connect the SBUS receiver to the RC input.
Map the drive output(s) to Throttle.
Map one PWM output to Steering for the S20F servo.
Use Manual mode for the first test.
PX4 Manual mode does not require wheel-speed, GPS or position measurements for this basic RC operation.
One detail I would like to confirm before recommending the exact motor-controller wiring:
Do you intend the two MG513 rear motors always to receive the same throttle command, or do you want PX4 to control the left and right rear motors independently?
Because you already have mechanical steering through the servo, for a conventional RC-car configuration I would initially treat the two rear motors as propulsion and use the servo exclusively for steering rather than mixing differential steering into the rear motors.
Also, if you can provide the exact MG513 voltage/current specification (or a link/datasheet for the motor) and the model/specification of the Fire Phoenix controller, I can check whether that controller is electrically suitable before you buy it.
Once that is confirmed, I can also give you a concrete Pixhawk 6C Mini → motor controller → MG513 + S20F wiring/output map.
Thank you very much for your reply. This is my first time working with a rover. For the initial test, I prefer the first method you described—driving the motors using the “Fire Phoenix” (Huo Fenghuang) ESC module. I have provided a link here; could you please take a look at it?
Both the motor and the ESC module are from niche domestic brands. I am not sure if the product pages will display English descriptions for you; if not, please let me know, and I will translate the details and upload them here.
I have also verified the three points you raised:
1、It accepts standard RC/PWM command signals compatible with Pixhawk output.
2、It supports bidirectional motor control (forward/reverse).
3、The stall current for the MG513P30_12V (model) is 3.2A, while the “Fire Phoenix” ESC module handles a continuous current of 35A and a peak current of 160A, so it should be capable of handling the load.
Regarding your question on whether I want the two rear MG513 motors to always receive the same throttle command or have PX4 control the left and right rear motors independently:
My current setup uses a servo motor for mechanical steering. Will this type of steering cause excessive tire wear? Does the PX4 firmware support the simultaneous use of two steering modes? (That is, triggering mechanical steering while varying the speeds of the two motors—one faster, one slower—which would likely require independent control via two ESC modules). If this isn’t supported, I will have to stick to using the servo motor for mechanical steering.
Additionally, I might use the second integration method you suggested later on (using the Hiwonder 4-channel encoder motor controller). I would like to ask: is the Hiwonder 4-channel encoder motor controller a main control module that can replace the Pixhawk 6C Mini, or are they meant to be used in series? If the Hiwonder controller replaces the Pixhawk 6C Mini, can I use an SBUS-protocol remote controller to operate the vehicle?
Thank you so much!
Hi Rik,
Thanks the additional specifications make the intended architecture much clearer.
I also checked the current PX4 rover documentation before answering your steering question.
For the first test, I agree with your choice to stay with the Fire Phoenix ESC approach. Based on the specifications you provided standard RC/PWM input, bidirectional operation, 35 A continuous / 160 A peak capability versus the stated 3.2 A stall current of the MG513P30_12V there is a very large current margin.
I would still do the first power-up with the wheels off the ground and verify neutral, forward/reverse direction and failsafe behaviour before putting the rover on the floor.
For your current vehicle I recommend keeping the first configuration as a conventional PX4 Ackermann rover:
SBUS receiver → Pixhawk 6C Mini
and then:
Pixhawk → ESC 1 → left MG513
Pixhawk → ESC 2 → right MG513
Pixhawk → S20F servo → mechanical steering
For the initial configuration, both rear motors should receive the same propulsion command and the servo should provide the steering.
PX4 currently treats Ackermann and Differential as separate rover control architectures.
In Ackermann mode, direction is controlled through the steering actuator. In Differential mode, direction is generated by varying the speeds of the left and right drive wheels.
Therefore I would not try to combine differential rear-wheel steering assistance with the mechanical steering servo for the first implementation. That would effectively create a hybrid steering/control-allocation problem rather than using the standard Ackermann rover behaviour.
It is certainly possible to investigate such a controller later, but I would treat that as a separate development step rather than part of the initial hardware bring-up.
Mechanical steering itself should not inherently cause excessive tire wear. Cars and other conventional wheeled vehicles use this principle.
What matters much more is the steering geometry: wheel alignment, toe, steering angles, wheelbase and the relationship between the inside and outside wheel angles during a turn.
PX4 also does not require a mechanically perfect Ackermann linkage; it supports front-steering rovers generally.
So I would first make the mechanical steering work correctly and keep both rear motors at the same commanded propulsion level.
There is one important clarification here:
The Hiwonder 4-channel encoder motor controller does NOT replace the Pixhawk 6C Mini.
They are used together.
The architecture would be:
SBUS receiver → Pixhawk 6C Mini → I2C → Hiwonder EMM → MG513 motors
The Pixhawk remains the flight/vehicle controller running PX4. It receives your SBUS RC commands and runs the rover control logic.
The Hiwonder module is a motor-control layer. It receives commands from PX4 over I2C and drives the brushed DC motors. It can also use encoder feedback for closed-loop motor-speed control.
PX4 has a dedicated hiwonder_emm I2C driver for this device.
So if you later switch from the Fire Phoenix ESCs to the Hiwonder controller, you would keep the Pixhawk and the SBUS receiver.
For your first test I would therefore proceed with:
SBUS → Pixhawk 6C Mini → two Fire Phoenix ESCs + S20F steering servo.
Once this works reliably in Manual mode, encoder feedback or the Hiwonder controller can be introduced as a second step.
If you want, the next step can be very concrete: I can propose the Pixhawk 6C Mini output assignment and PX4/QGroundControl actuator configuration for ESC 1, ESC 2 and the steering servo before you wire and power the system.
Hi yigitcan,
Thank you very much for your reply. I will go ahead and purchase two “Fire Phoenix” (Huo Fenghuang) ESCs to assemble my car, and I will get back to you here once the assembly is complete.
I am truly grateful for your help.
You’re very welcome, Rik.
Sounds good. Once the vehicle is assembled, feel free to post your configuration and initial test results here.
I’d suggest starting with a conservative bench test before the first autonomous run, and then we can look at the behaviour step by step if anything unexpected appears.
Looking forward to seeing how the build performs.
Hi yigitcan
I need to ask for your help again. I flashed the px4_fmu-v6c_default.px4 firmware (v1.16.0 Stable Release). When I set SYS_AUTOSTART to 1104, the parameter fails to save; I even tried 50000 and 50001, but those also failed. However, if I set SYS_AUTOSTART to 4001 (generic quadcopter), the parameter saves successfully. I have uploaded a video here to better illustrate the issue.
Suspecting a firmware bug, I flashed version v1.17.0, but the result was the same. I am wondering if you have ever encountered this situation. I look forward to your reply—thank you very much.@yigitcan-ozturk
Hi Rik,
Thanks for the detailed report and the video.
I checked the PX4 v1.16.0 release information and the px4_fmu-v6c_default board configuration. I think we have identified the likely reason for the behaviour you are seeing.
Starting with PX4 v1.16, rover support was restructured and a dedicated rover firmware build was introduced.
Your current firmware, px4_fmu-v6c_default.px4, is the standard build. The v1.16.0 board configuration includes the legacy rover position controller, but not the new dedicated Ackermann rover module.
This would explain why a generic quadcopter airframe (4001) works while the new rover configurations do not.
There is also an important correction regarding the airframe ID:
1104 — SIH Ackermann simulation
50000 — Generic Differential Rover
50001 — Aion Robotics R1
51000 — Generic Ackermann Rover
For your vehicle, 51000 is the correct target.
I recommend the following:
Check whether a rover-specific firmware build is available for your Pixhawk 6C Mini and selected PX4 version.
Do not assume that the normal default firmware contains the new rover modules.
If a compatible rover build is available, flash it through QGroundControl.
After reboot, select Generic Rover Ackermann, or use SYS_AUTOSTART=51000 if the airframe is not listed.
If the dedicated rover build is not available for your board, we should first verify the board build configuration and determine whether a custom firmware build is necessary.
I would not recommend continuing to change airframe IDs on the current firmware or treating this as a confirmed firmware bug yet.
If possible, please share the available firmware choices shown by QGroundControl for your Pixhawk 6C Mini.
Once the correct rover firmware is installed, we can proceed with the actual actuator configuration for your two Fire Phoenix ESCs and S20F steering servo.
For reference:
Hope this helps!
Hi yigitcan,
Thank you very much for your reply. Following your suggestions, I found the px4_fmu-v6c_rover.px4 firmware on GitHub and successfully got my rover up and running. Here is a video of it in operation.
I am not sure if my configuration is correct (as the red light in the QGC “Actuators” tab has not disappeared), so I am sharing my settings here and would appreciate your feedback.
SYS_AUTOSTART=51000 (Generic Ackermann Rover)
Pixhawk–M2 → ESC 1 → Left MG513 → PWM_MAIN_FUNC2=Throttle
Pixhawk–M3 → ESC 2 → Right MG513 → PWM_MAIN_FUNC3=Throttle
Pixhawk–M4 → S20F Servo → Mechanical Steering → PWM_MAIN_FUNC4=RC Yaw
PWM_MAIN_DIS2=1500
PWM_MAIN_DIS3=1500
PWM_MAIN_DIS4=1500
PWM_MAIN_REV=4
I also noticed a slight lack of synchronization between the speeds of the two motors; I am not sure if this is due to using two separate ESCs for independent control. To better illustrate the issue, I have uploaded another video here.
Of course, it is only a slight desynchronization, so it won’t have a major impact for the time being; I was wondering if you have ever encountered a similar situation.
Thanks again for your reply!@yigitcan-ozturk
Hi Rik,
Great progress! I’m glad the dedicated px4_fmu-v6c_rover.px4 firmware resolved the airframe issue and that your rover is now moving.
Thanks for sharing the configuration and videos.
I would check a few things before considering the actuator configuration complete.
1. Steering output assignment
Your current assignment is:
M2 → Throttle → Left ESC
M3 → Throttle → Right ESC
M4 → RC Yaw → Steering servo
The first two assignments are consistent with your intention to use a common throttle command for both motors.
However, I would change M4 from RC Yaw to the dedicated rover Steering actuator function, if available in your PX4 rover configuration.
RC Yaw is an RC passthrough function, whereas the rover steering actuator is intended to receive commands from the Ackermann control architecture. This distinction matters particularly if you later use other supported drive modes.
2. Red indicator in QGroundControl
I would not assume the red indicator is harmless simply because the rover moves.
Could you share a close-up screenshot showing the exact red indicator and any associated warning or tooltip?
We should determine whether it represents an unassigned actuator, incomplete configuration, output state or another warning before changing additional parameters.
3. Disarmed PWM values
You have set:
PWM_MAIN_DIS2=1500
PWM_MAIN_DIS3=1500
PWM_MAIN_DIS4=1500
For bidirectional ESCs, 1500 µs may be the neutral command, but this must be confirmed against the Fire Phoenix ESC specifications.
For the steering servo, 1500 µs is a common centre position.
With the wheels safely raised and the system disarmed, verify that neither drive motor rotates and that the steering servo stays in a safe neutral position.
Also verify the ESC behaviour during RC signal loss and PX4 failsafe activation.
4. Output reversal
Your current PWM_MAIN_REV=4 should also be checked.
This parameter is a bitmask, not an individual PWM channel number. A value of 4 corresponds to bit 2, normally affecting the third output channel (M3), not M4.
Please confirm that the resulting motor and steering directions are correct.
5. Difference between left and right motor speeds
A slight speed difference is quite possible when using two brushed DC motors with separate ESCs in open-loop control.
Even if PX4 sends the same throttle command to both ESCs, the actual speeds can differ due to:
ESC neutral/deadband calibration
Motor manufacturing tolerances
Gearbox friction
Battery voltage and wiring losses
Different mechanical loads
I suggest first confirming that M2 and M3 receive identical PWM commands for the same throttle input.
Then, with the wheels raised, compare the motor behaviour at low, medium and higher throttle settings. Start at low throttle and keep the tests brief.
If possible, measure the motor speeds using the Hall encoders. This would tell us whether the difference comes from the command signals or the motor/ESC response.
An important distinction: Sending identical throttle commands to two ESCs does not provide closed-loop speed synchronization.
If matched wheel speeds become important, encoder-based speed feedback and an appropriate controller would be the next development stage.
For now, I would prioritize:
Correcting and validating the steering function.
Identifying the red actuator warning.
Verifying disarmed, neutral and failsafe behaviour.
Checking whether M2 and M3 receive identical throttle commands.
You have already achieved a useful first milestone. Once these checks are complete, we can move toward a more reliable and reproducible rover configuration.
Well done on getting the system running!
Hi yigitcan,
Thank you very much for your reply.
1、I have changed PWM_MAIN_FUNC4 from RC Yaw to steering based on your suggestion, and the red alert in the QGC Actuators tab has disappeared.
2、Since I have configured my ESC for bidirectional mode, setting PWM_MAIN_DIS X=1500 works correctly; this setting is necessary for the rover to reverse. If I were to use the default value of PWM_MAIN_DIS X=1100, the rover would continuously reverse immediately after arming.
3、As for why PWM_MAIN_REV is set to 4, let me explain: the wiring sequence for both motors is identical—neither has been reversed—but since the motors are mounted in opposite directions, one of them must be configured to run in reverse to achieve synchronized movement.
4、Regarding the issue of motor speed differences: the problem seems much less noticeable after I recalibrated the ESC throttle range.
It looks like there aren’t any major issues with this rover.
@**yigitcan-ozturk**Thank you so much, yigitcan! Your suggestions helped me resolve a lot of issues; this has been a very useful thread. I plan to continue optimizing this rover—perhaps by adding GPS or RTK for route planning.
Unfortunately, I see a notice stating, “This topic will close 7 days after the last reply.” I’m not sure if you have the ability to change the settings so that it remains open permanently.
Hi Rik,
That’s excellent progress! Thank you for sharing the detailed results and explaining your configuration.
I’m glad switching M4 from RC Yaw to the dedicated Steering function resolved the QGroundControl actuator warning.
Your explanation of PWM_MAIN_REV=4 also makes sense. Since the two motors are mounted in opposite orientations, reversing the appropriate motor output is a reasonable solution.
Likewise, your use of 1500 µs as the neutral PWM value is consistent with your bidirectional ESC configuration. It’s particularly important that the motors remain stationary at neutral and behave safely during disarming and failsafe conditions.
The improvement after recalibrating the ESC throttle ranges is also a useful diagnostic result. It suggests that differences in ESC calibration were contributing to the motor speed mismatch, although encoder measurements would be needed to quantify the remaining difference.
For your next development stage, GPS or RTK could be a good direction. I would suggest progressing incrementally:
Preserve your current working configuration and parameter backup.
Verify steering, throttle, neutral and failsafe behaviour through repeatable ground tests.
Integrate GNSS and confirm position estimates in QGroundControl.
If you add RTK, verify correction status and positioning quality before relying on it for navigation.
Only then move toward controlled autonomous route-following tests in a safe environment.
Regarding the forum’s automatic closure notice, I don’t have moderator permissions to change the topic settings.
If the topic closes, you can start a new thread for the GPS/RTK development stage and link back to this discussion. You could also ask a forum moderator whether extending the topic is possible.
Thanks again for documenting your progress so clearly. Your experience with the Pixhawk 6C Mini, PX4 rover firmware and bidirectional brushed-motor ESCs should be useful to others building similar vehicles.
Best of luck with the next stage, and feel free to tag me in the follow-up thread!
