It looks like ArduPilot only supports two channel encoders. Is this correct?
It’s my understanding the three channel encoders on a brushless motor are usually used by the ESC to know which coil to energize. Using only two channels should be able to provide speed information as long as the transition times are averaged. Normal quadrature encoders provide four transitions per encoder cycle but three channel encoders provide six transitions.
When using only two channels of a three channel encoder, the transitions will not be evenly spaced through an encoder cycle.
I don’t know if this non-uniform transition intervals would cause problems with the ArduPilot software. Does anyone here know if using only two of the three channels will be a problem?
Two of the three channels is still enough to monitor the direction and speed of the wheel but the speed calculation will need to be done using at least two transition intervals since the transitions intervals will not be evenly spaced through the encoder cycle.
I still haven’t found the possibility of connecting my hoverborad motor to the Pixhawk, I even have the ESC brushless motor esc, but the hall effect sensors still don’t follow the configuration as it deals with the documentation about the wheel encoders, I would have a more updated possibility , it would be interesting because there is no such information on the internet. appreciate
You might be able to leave one of the Hall effect sensor wires disconnected. I don’t know if ArduPilot will work well when using two of the three sensor wires but it might. The two sensor wires provide enough information for the controller to determine the direction the motor is spinning but I’m not sure if it will control speed well or not.
Do you have the original drill parts? I’m guessing the purple wire is used to power the encoder but it would be nice to check when the wires are temporarily connected to the rest of the drill.
Edit: I’m not sure if the encoder example in the documentation uses an ESC which can be controlled using normal servo pulses. I don’t understand ArduPilot well enough to know which parameters may need to be changed.
Pensei também nessa hipótese do fio Roxo ser o do codificador, assim q eu testar de forma segura, estarei comentando aqui. Pois a princípio segue a mesma configuração de um hoverbord, mas a documentação não tem muito detalhe referente. Estou juntando mais informação pra poder fazer um teste mais seguro, para q eu possa assegurar a controladora.
Outra dedução, é que por ser um motor sem escova e está sendo controlado pelo ardopilot por GPS, a documentação trata como se não tivesse tão necessidade pois é papel do GPS,
A princípio os codificador são usados quando não há GPS, que seria já outro caso.
Mas pode usar 100% da tecnologia do motor pra seria eficiente pro meu projeto.
Hoverboard motors have a very low kV. I never managed to get them running smoothly with a regular RC ESC (sensored or sensorless)
They run fine with an Odrive, VESC, or a reflashed hoverboard controller.
The hall sensors need to be connected to the ESC, to get the full benefit of low RPM control and a smooth start.
I also tried to use two of the hall sensors as a wheel encoder for ardurover, but even after a lot of trying, I could not get a consistent result. If I remember correctly, the most prominent problem was that the reported distances were different for CW and CCW rotation.
There should be a way to calculate a 90° offset quadrature signal from the 120° degree hall sensor signal, but I never tried that.
I use AMS 5047d encoders on one of my rovers. To use them with hoverboard wheels, you would have to build a frame to mount them to the outside of the wheels.
After choosing a motor (brushless or brushed (DC)), an appropiate controller must be chosen. After that (MOT_PWM_TYPE):
The controller may require a RC pulse control signal (1000/1500/2000µs or variants), as common brushless motors.
The controller may require a PWM control signal (duty cycle 0% to 100%). It is confusing that this is measured/represented as 1000 to 2000 (or chosen range).
This is ideal. Now I am wating to receive parts for assembling a balance bot with two of these motors (size double than those in above video), but from initial experiments this seems promising.
While on above video the balance bot with direct drive and low KV motors was more difficult to tune (lower cog, also lowering ESC’s), and resulted less stable than others with DC motors, the result is acceptable.
Although I think that IRQ handler code for encoder signals can be greatly optimized in timing (with a slight code size saving), I think the code is very solid. These are the WENC signals for the direct drive balance bot on above video:
Note the similarity between them, going opposite (the balance bot is pivotting), although the initial offsets and the drift.
As said, I don’t think that the code considers that they should be at 90º (Randy could give a reasoned opinion on this), and as shown connecting two signals at 120º gives acceptable results. However, as said, the other balance bot has stepper motors with encoders, and I found that the encoders gave pulse/direction instead of direct/quadrature signals (not supported; see WENC_TYPE/WENC2_TYPE), so I inserted an Arduino for doing the conversion (hanging at Ken’s back, with red/green signaling leds). The same can be done for 120º/90º conversion.
For what it’s worth I am getting good low-speed performance (full torque down to 0 RPM and smooth start) from BLDC motors (from https://www.freerchobby.cc/) without sensors (i.e. in sensorless mode) using Vedder’s VESC controllers. This on both 50kv and 140kv motors (not that it matters).
I wasn’t able to get the ODrives working in RC(PPM) mode, likely due to operator error or operator inexperience…
I wrote some code using a hall sensor example and a quadrature encoder emulator and hacked it together, i only checked if it compiled but i never actually tested it.
The forum software appears to drop the final period in your link.
People wanting to follow the link can manually add the period at the end or follow this link.
Certainly, I would prefer them instead of substituting the electronics, but here what is all about are four wheels vehicles, without needing balance (may be I am missing something).
Not exactly. On the hoverboard the two plates rotate one in respect to the other from human action, and the side boards translate this into movement. Above the plates are fixed, and the FC moves the motors (human action outside (TX radio)).
I’m using the dcf887b dewhalt motors, they are brushless motors, a very good motor to use in a rover, but I still haven’t found the right way to use it, could someone help me with some esc, in I could adapt it with power control with the controller
it would be a great idea to use the drill’s own esc, but I believe that the tension would damage the controller, could someone help me with some adaptation
I think you will need a digital interface like a lua serial driver, it will give you much finer control with no deadzone as your setting the values directly, it should give better control for a balancing application where you need very fine control, pwm isn’t a great interface for that.
