Query regarding connecting bigger ESCs
-
Hello Swaroop,
The ModalAi ESC can support most common motors. The ESC is rated for 2-4S battery voltage. The current rating is 15-20A continuous (per motor), depending on air cooling. What motors / propellers are you considering using with ModalAi ESC? We have some tools and calibration procedure for adjusting ESC parameters for new motors : https://gitlab.com/voxl-public/flight-core-px4/voxl-esc/-/blob/master/tools/calibration.md
Regarding support of 8 motors, the ModailAi ESC has hardware support for using two 4-in-1 ESCs on a single UART connection (8 ESC channels with IDs 0-7). However, our PX4 ESC driver does not currently support more than 4 motors.
Alex
-
Hello Swaroop,
The ModalAi ESC can support most common motors. The ESC is rated for 2-4S battery voltage. The current rating is 15-20A continuous (per motor), depending on air cooling. What motors / propellers are you considering using with ModalAi ESC? We have some tools and calibration procedure for adjusting ESC parameters for new motors : https://gitlab.com/voxl-public/flight-core-px4/voxl-esc/-/blob/master/tools/calibration.md
Regarding support of 8 motors, the ModailAi ESC has hardware support for using two 4-in-1 ESCs on a single UART connection (8 ESC channels with IDs 0-7). However, our PX4 ESC driver does not currently support more than 4 motors.
Alex
@Alex-Kushleyev Hi Alex,
Juset as a follow up, you say the board supports 2 4-in-1 ESCs on the same UART port. How would you then distinguish between sending commands to ESC 1 vs ESC 2, both connected to the same port?
E.g., I figure it would amount to some version of adding indexes 4-7 to
cmd.len = qc_esc_create_rpm_packet4_fb(_esc_chans[0].rate_req, _esc_chans[1].rate_req, _esc_chans[2].rate_req, _esc_chans[3].rate_req, _esc_chans[0].led, _esc_chans[1].led, _esc_chans[2].led, _esc_chans[3].led, _fb_idx, cmd.buf, sizeof(cmd.buf), _extended_rpm);but I am not quite sure how ESC1 knows it is 0->3 and ESC2 knows it is 4->7.
-
@Alex-Kushleyev Hi Alex,
Juset as a follow up, you say the board supports 2 4-in-1 ESCs on the same UART port. How would you then distinguish between sending commands to ESC 1 vs ESC 2, both connected to the same port?
E.g., I figure it would amount to some version of adding indexes 4-7 to
cmd.len = qc_esc_create_rpm_packet4_fb(_esc_chans[0].rate_req, _esc_chans[1].rate_req, _esc_chans[2].rate_req, _esc_chans[3].rate_req, _esc_chans[0].led, _esc_chans[1].led, _esc_chans[2].led, _esc_chans[3].led, _fb_idx, cmd.buf, sizeof(cmd.buf), _extended_rpm);but I am not quite sure how ESC1 knows it is 0->3 and ESC2 knows it is 4->7.
@Morten-Nissov , as i mentioned before, it is not officially supported right now, but we can explore this potential feature.
The way two 4-in-1 ESCs would communicate, you would connect the UART RX and TX to both of them. However, before doing that, we need to tell one of the ESCs that it should be behaving as IDs 4-7 as opposed to IDs 0-3. When we originally designed this feature, there was a special connection (by default DNI'ed on the ESC PCB), where if you placed a 0-ohm resistor, it would tell all the MCUs on the ESC to behave with "shifted" IDs. However, this feature this has not been tested / used in a long time (due to lack of demand) and the software tools are not set up to support it right now (tools light firmware update, etc :
voxl-esc).Let me go back and check which ESC boards could potentially support this feature (via the hardware jumper). Then i would need to evaluate how difficult would it be to update the tools for 8 IDs before I could tell you if / when we can support it.
Can you please clarify which ESC board(s) you are considering using for the dual ESC configuration?
Alex
-
@Morten-Nissov , as i mentioned before, it is not officially supported right now, but we can explore this potential feature.
The way two 4-in-1 ESCs would communicate, you would connect the UART RX and TX to both of them. However, before doing that, we need to tell one of the ESCs that it should be behaving as IDs 4-7 as opposed to IDs 0-3. When we originally designed this feature, there was a special connection (by default DNI'ed on the ESC PCB), where if you placed a 0-ohm resistor, it would tell all the MCUs on the ESC to behave with "shifted" IDs. However, this feature this has not been tested / used in a long time (due to lack of demand) and the software tools are not set up to support it right now (tools light firmware update, etc :
voxl-esc).Let me go back and check which ESC boards could potentially support this feature (via the hardware jumper). Then i would need to evaluate how difficult would it be to update the tools for 8 IDs before I could tell you if / when we can support it.
Can you please clarify which ESC board(s) you are considering using for the dual ESC configuration?
Alex
@Alex-Kushleyev Understood.
We were thinking of the mini ESSC: https://www.modalai.com/products/voxl-esc-mini?variant=47206467371312. But that's not necessarily a hard requirement, is it written which ones have this jumper? Sorry if I missed it.
We're not opposed to doing some of this ourselves either, if it's not a feature you were planning on or wanted to add. Before seeing this message we were brainstorming re-purposing the GNSS UART for this instead, and other such more "hacky" solutions.
Morten
-
@Alex-Kushleyev Understood.
We were thinking of the mini ESSC: https://www.modalai.com/products/voxl-esc-mini?variant=47206467371312. But that's not necessarily a hard requirement, is it written which ones have this jumper? Sorry if I missed it.
We're not opposed to doing some of this ourselves either, if it's not a feature you were planning on or wanted to add. Before seeing this message we were brainstorming re-purposing the GNSS UART for this instead, and other such more "hacky" solutions.
Morten
@Morten-Nissov , sorry i was out of office for a few days.
Let me double check the mini ESC, i believe we probably removed that option for the jumper in order to save the space. But there could be other ways to do this.
You are right that it could be possible to use two separate UARTs to achieve this. Then you would not need any change in the ESC itself, but there would be changes on the PX4 side. The easiest option would be to create a clone of the
voxl-escdriver and have it use a different port and have the functions mapped to motors 5-8 instead of 1-4. I don't see why this would not work, it's not really too hacky, other than duplicating thevoxl-escdriver, which is a lot easier than changing the single driver to work with 8 channels. You could just create a new module such asvoxl-esc2or something like that
and may need to modify the code a bit to allow to map motors 5-8 (i think currently you can only map motors 1-4).This is definitely worth a try if you want to give it a shot. Rough outline of the steps:
- create a copy of the
voxl-escdriver in px4 and rename it (lets sayvoxl-esc2) - add the new driver to the build for voxl2 platform
- verify that the new driver can be used instead of the existing driver to achieve the current functionality of
voxl-escbut using the gps uart port - verify that you can run two drivers at the same time (
voxl-escandvoxl-esc2), you can have them send the same commands at first - modify
voxl-esc2to map motors 5-8 instead of 1-4 and test controlling all 8 motors independently (you can use actuator test in QGC) - publishing ESC status could be weird because i think all of the ESC status is in one message, but you can disable that or if you only populate the esc status of the appropriate ESCs, that could work (
voxl-escto populate esc status 1-4 andvoxl-esc2would popoulate esc status of 5-8).
Just to summarize, we are not officially supporting this yet (i will need to do more thinking how to do this the easiest way that is in line with our future plans), but i think i provided a summary that should let you do this one your own without any changes in the ESC firmware. If you decided to go for it and run into an issue, i can try to help.
Alex
- create a copy of the
-
@Morten-Nissov , sorry i was out of office for a few days.
Let me double check the mini ESC, i believe we probably removed that option for the jumper in order to save the space. But there could be other ways to do this.
You are right that it could be possible to use two separate UARTs to achieve this. Then you would not need any change in the ESC itself, but there would be changes on the PX4 side. The easiest option would be to create a clone of the
voxl-escdriver and have it use a different port and have the functions mapped to motors 5-8 instead of 1-4. I don't see why this would not work, it's not really too hacky, other than duplicating thevoxl-escdriver, which is a lot easier than changing the single driver to work with 8 channels. You could just create a new module such asvoxl-esc2or something like that and may need to modify the code a bit to allow to map motors 5-8 (i think currently you can only map motors 1-4).This is definitely worth a try if you want to give it a shot. Rough outline of the steps:
- create a copy of the
voxl-escdriver in px4 and rename it (lets sayvoxl-esc2) - add the new driver to the build for voxl2 platform
- verify that the new driver can be used instead of the existing driver to achieve the current functionality of
voxl-escbut using the gps uart port - verify that you can run two drivers at the same time (
voxl-escandvoxl-esc2), you can have them send the same commands at first - modify
voxl-esc2to map motors 5-8 instead of 1-4 and test controlling all 8 motors independently (you can use actuator test in QGC) - publishing ESC status could be weird because i think all of the ESC status is in one message, but you can disable that or if you only populate the esc status of the appropriate ESCs, that could work (
voxl-escto populate esc status 1-4 andvoxl-esc2would popoulate esc status of 5-8).
Just to summarize, we are not officially supporting this yet (i will need to do more thinking how to do this the easiest way that is in line with our future plans), but i think i provided a summary that should let you do this one your own without any changes in the ESC firmware. If you decided to go for it and run into an issue, i can try to help.
Alex
@Alex-Kushleyev Sorry for not responding, and thanks for getting back to me.
I was curios if this jumper functionality was available on the mini? I'm guessing no?
Otherwise we'll proceed with your recommendations, it doesn't seem so challenging to implement these changes.
Edit: Just a quick question for a bug we found early on. I've made a copy of the driver and am trying to build it, but I am running into the following error message:
Duplicate parameter definition: VOXL_ESC_FUNC1+
I have removed entries from the params.c to make sure things are not doubly defined, but this one is not even defined there:// The following are auto generated params from control allocator pattern, put here for reference // Default ESC1 to motor2 //PARAM_DEFINE_INT32(VOXL_ESC_FUNC1, 102); //PARAM_DEFINE_INT32(VOXL_ESC_FUNC2, 103); //PARAM_DEFINE_INT32(VOXL_ESC_FUNC3, 101); //PARAM_DEFINE_INT32(VOXL_ESC_FUNC4, 104);I've looked for other references to
VOXL_ESC_FUNC1but I am not finding the right place, would you have any idea why this is now getting doubly defined. - create a copy of the
-
@Alex-Kushleyev Sorry for not responding, and thanks for getting back to me.
I was curios if this jumper functionality was available on the mini? I'm guessing no?
Otherwise we'll proceed with your recommendations, it doesn't seem so challenging to implement these changes.
Edit: Just a quick question for a bug we found early on. I've made a copy of the driver and am trying to build it, but I am running into the following error message:
Duplicate parameter definition: VOXL_ESC_FUNC1+
I have removed entries from the params.c to make sure things are not doubly defined, but this one is not even defined there:// The following are auto generated params from control allocator pattern, put here for reference // Default ESC1 to motor2 //PARAM_DEFINE_INT32(VOXL_ESC_FUNC1, 102); //PARAM_DEFINE_INT32(VOXL_ESC_FUNC2, 103); //PARAM_DEFINE_INT32(VOXL_ESC_FUNC3, 101); //PARAM_DEFINE_INT32(VOXL_ESC_FUNC4, 104);I've looked for other references to
VOXL_ESC_FUNC1but I am not finding the right place, would you have any idea why this is now getting doubly defined.@Morten-Nissov , i believe that module.yaml specifies the param prefix, which is used to generate the params inherited from the control allocator:
px4-firmware/src/drivers/actuators/voxl_esc/module.yaml at voxl-dev · modalai/px4-firmware
PX4 Autopilot Software. Contribute to modalai/px4-firmware development by creating an account on GitHub.
GitHub (github.com)
You would need to change the param prefix for your new module (in yaml and also double check the code to make sure it is using the correct params).
Also, the mini ESC does not have the jumper to modify the IDs, sorry!
Alex
-
@Morten-Nissov , i believe that module.yaml specifies the param prefix, which is used to generate the params inherited from the control allocator:
px4-firmware/src/drivers/actuators/voxl_esc/module.yaml at voxl-dev · modalai/px4-firmware
PX4 Autopilot Software. Contribute to modalai/px4-firmware development by creating an account on GitHub.
GitHub (github.com)
You would need to change the param prefix for your new module (in yaml and also double check the code to make sure it is using the correct params).
Also, the mini ESC does not have the jumper to modify the IDs, sorry!
Alex
@Alex-Kushleyev Do you think it is possible to reuse params between drivers? E.g. those which shouldn't be different between the too like baud, rpm min, rpm max, etc?
I was tempted to implement the extra serial read in the voxl_esc driver for this reason, to avoid doubly defining parameters which should be the same, but this is probably more complicated overall.Also, the mini ESC does not have the jumper to modify the IDs, sorry!
Ah unlucky, but thanks for checking.
-
@Alex-Kushleyev Do you think it is possible to reuse params between drivers? E.g. those which shouldn't be different between the too like baud, rpm min, rpm max, etc?
I was tempted to implement the extra serial read in the voxl_esc driver for this reason, to avoid doubly defining parameters which should be the same, but this is probably more complicated overall.Also, the mini ESC does not have the jumper to modify the IDs, sorry!
Ah unlucky, but thanks for checking.
Yes, that is probably a good idea. so in the clone
voxl-escdriver, you could just use the params and not define them inmodule.yamland if you need to be able to change directions, you can define just the params like VOXL_ESC_SDIR5 ... SDIR8, etc -
G Gary Holmgren referenced this topic on
-
@Alex-Kushleyev, Hi Alex
I recently setup a Hexarotor with 2 voxl-mini esc and created the second esc driver as described above. I know that this use case is not officially supported.
But i was hoping you still can help me out on the following issue.As flying the drone inside a motion capture setup with position tracking, px4 has tough time holding it's position. A similar (in size and weight) quadrotor with the same firmware and setup works flawless.
Flying in stabilized mode / attitude control both drones are fine.Looking into PX4 uorb rates I noticed running both esc drives reduces the update rate from 800 to 500hz in rate control. Also, some messages as the actuator_output and esc_status get published twice, once per esc, overwriting or setting the others esc status in the message to zero.
Inside the driver itself sometimes the write-read to the esc spikes up to ~2ms of execution time.Any idea if some of these observations might lead to the bad tracking performance of px4?
Besides that, both escs i use have one bad port that is not able to spin up any motor, it just gets stuck in the synchronization phase and motor is jumping back and forth but that's a different issue.
Thanks, in advance
Phil
-
@Alex-Kushleyev, Hi Alex
I recently setup a Hexarotor with 2 voxl-mini esc and created the second esc driver as described above. I know that this use case is not officially supported.
But i was hoping you still can help me out on the following issue.As flying the drone inside a motion capture setup with position tracking, px4 has tough time holding it's position. A similar (in size and weight) quadrotor with the same firmware and setup works flawless.
Flying in stabilized mode / attitude control both drones are fine.Looking into PX4 uorb rates I noticed running both esc drives reduces the update rate from 800 to 500hz in rate control. Also, some messages as the actuator_output and esc_status get published twice, once per esc, overwriting or setting the others esc status in the message to zero.
Inside the driver itself sometimes the write-read to the esc spikes up to ~2ms of execution time.Any idea if some of these observations might lead to the bad tracking performance of px4?
Besides that, both escs i use have one bad port that is not able to spin up any motor, it just gets stuck in the synchronization phase and motor is jumping back and forth but that's a different issue.
Thanks, in advance
Phil
Can you please let me know which version of VOXL2 SDK you are using (and which version of PX4 you are using as the base, before you made updates to the ESC driver)? We made improvements to the SLPI (DSP) UART driver about 6 months ago, which reduced io latency.
Also, what baud rate are you using to communicate with the ESCs?
The actuator output messages conflicting -- yes, unfortunately we do not currently properly handle publishing multiple messages from different instances, so they will all come in on the same topic and will kind of alternate..
Alex
-
Can you please let me know which version of VOXL2 SDK you are using (and which version of PX4 you are using as the base, before you made updates to the ESC driver)? We made improvements to the SLPI (DSP) UART driver about 6 months ago, which reduced io latency.
Also, what baud rate are you using to communicate with the ESCs?
The actuator output messages conflicting -- yes, unfortunately we do not currently properly handle publishing multiple messages from different instances, so they will all come in on the same topic and will kind of alternate..
Alex
@Alex-Kushleyev
Thanks for the quick replysystem-image: 1.7.8-M0104-14.1a-perf
kernel: #1 SMP PREEMPT Sat May 18 03:34:36 UTC 2024 4.19.125
hw platform: M0104
mach.var: 2.0.0
voxl-suite: 1.3.3and using px4 1.14.0
both ESCs are running with a 2M baud rate
-
@Alex-Kushleyev
Thanks for the quick replysystem-image: 1.7.8-M0104-14.1a-perf
kernel: #1 SMP PREEMPT Sat May 18 03:34:36 UTC 2024 4.19.125
hw platform: M0104
mach.var: 2.0.0
voxl-suite: 1.3.3and using px4 1.14.0
both ESCs are running with a 2M baud rate
@astro_phil
px4 version: 1.14.0-2.0.68
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login