Closed vfear closed 3 years ago
What is the error you get?
Also, there has been a very recent bug fix for Variant PWM . I am not sure of the online compiler has the change.
the problem is that I give the signal and the wheels don't turn =) Just, I'd like to understand... To select the desired option, I just have to uncomment the line / / #define VARIANT_PWM, and that's it? or do you need something else?
Yes, that is correct. To select any Variant, you just need to uncomment the respective line.
When you say they don't turn. Do you get the startup melody, when powering the board after flashing?
Yes, you can give Your bin or hex for example with the selected PWM mode, I will try to flash it.
when turned on, a melody plays, then with an interval beep, and then it turns off. I send the signal of the receiver to the left UART blue wire. Arduino writeMicroseconds (1700);
You need to use the Arduino Servo library. The RC PWM protocol is not just pure pwm, it has a timing aspect to it as well!
You need to use the Arduino Servo library. The RC PWM protocol is not just pure pwm, it has a timing aspect to it as well!
Of course, I use this library. I also tried on your firmware - it works well.
so what to do?
After recent changes to the code it also doesn't work for me. That is why I had to installed toolchain on my machine and revert to the version from somewhere in the middle of may. The older version of code works like a charm with my RC radio setup (FlySky FS-I6x and FS-IA10B), but current doesn't.
Since the recent changes actually enabled channel 2, you might be running into issues with invalid input when using only one channel?
@benjaf I was also thinking about using only one Timer for both channel. I don't understand why this would work better than using 2 independent Timer. IF only one Timer is used, wouldn't the two channels reset each other making the timing measurements not ok?
I think this is what @sp5rfd is experiencing.
@EmanuelFeru On most receivers the signals for each channel is offset, so only one channel is ever high at any given time. Since only the 'high' period matters, it is possible to get away with using only one timer. Some of the fancier 8+ channel radios might behave differently though! I have not really taken those into account, as they generally support other protocols as well. I suspect the timer I initially used for channel 1 was also used for something else internally, because it caused very erratic results.
it would be nice if the firmware worked with the servo library for one channel. I want to use the radio control in conjunction with the gas pedal for a children's car.
@vfear If you do not intend to use steering, you should add a pull-down resistor to the unused input wire, and possibly disable the Channel 1 section here to make sure there is no interference on that channel.
@vfear @sp5rfd I made a commit for the PWM Variant (see 8ddfc82882ce7c55090b6841e6592682957bf467) Can you give a try to see if it works?
One last commit 205c054235e8abeb1a6a8090f81a01476749de3d to make them completely independend according to this:
Illustration of the PWM functionality
CH1 ________|‾‾‾‾‾‾‾‾‾‾|________
CH2 ______________|‾‾‾‾‾‾‾‾‾‾‾|________
↑ ↑ ↑ ↑
TIM2 RST SAVE RC_CH1 RC_CH1
Please try this last commit.
One last commit 205c054 to make them completely independend according to this:
Illustration of the PWM functionality CH1 ________|‾‾‾‾‾‾‾‾‾‾|________ CH2 ______________|‾‾‾‾‾‾‾‾‾‾‾|________ ↑ ↑ ↑ ↑ TIM2 RST SAVE RC_CH1 RC_CH1
Please try this last commit.
Need to download 3 files and replace in the latest firmware? or can you completely download everything from the main page again?
Just the 3 files should be sufficient. To maintain your eventual customizations.
Just the 3 files should be sufficient. To maintain your eventual customizations.
with one wheel will I be able to test?
Just the 3 files should be sufficient. To maintain your eventual customizations.
it worked, thanks a lot
another question, how to strengthen the brake? now the wheels can be easily twisted by hand. when you’re not going anywhere, the car may roll off the hill
Nice that it works!
To avoid rolling backwqrds, you can switch to Speed mode when speedAvgAbs<small_threshold
for some time (to define the time you can use a counter or save the main_loop_counter and compare how much time it passed).
The Voltage mode or Torque mode will inherently roll back. And there is not much you can do there.
speedAvgAbs<small_threshold
for some time (to define the time you can use a counter or save the main_loop_counter and compare how much time it passed).
Yay Works) Do I understand correctly that this can be configured? Can you elaborate? where can I find it?
@EmanuelFeru Thank you so very much for your latest update. It works very well and should resolve the issues @sp5rfd was seeing as I am using the same step-up.
it would be very cool if you could combine pwm with the pedal (for a children's electric car), the receiver on the left uart, and the pedal on the right uart. And for example, if the remote control is turned on, the parent controls it, and if it is turned off, the control is transferred to the child =)
Happy to hear that it works @k3nden
@vfear I would need similar functionality for my Hovercar. The pedals need to be on the Left cable because the ADCs are there. I don't think we can put pedals on the right UART because of no ADC. So, then the remote control needs to be (if possible) moved to the right cable.
In my Hovercar, I have pedals on the Left cable and one sideboard on the right cable. So, I am thinking to connect a remote to the sideboard which then sends the commands via UART to the main board. Maybe this be feasible for you too?
Regarding your previous question, I didn't fully understand , but that code is not available, so you need to write few lines of code for the if statement and time check. But it shouldn't be very difficult.
Happy to hear that it works @k3nden
@vfear I would need similar functionality for my Hovercar. The pedals need to be on the Left cable because the ADCs are there. I don't think we can put pedals on the right UART because of no ADC. So, then the remote control needs to be (if possible) moved to the right cable.
In my Hovercar, I have pedals on the Left cable and one sideboard on the right cable. So, I am thinking to connect a remote to the sideboard which then sends the commands via UART to the main board. Should this be feasible for you?
Regarding your previous question, I didn't fully understand , but that code is not available, so you need to write few lines of code for the if statement and time check. But it shouldn't be very difficult.
speedAvgAbs<small_threshold - what will it give me? everything works so well.
and about the receiver - it is possible and as you said. But it’s better to go directly to the motherboard (fewer parts - more compact)
speedAvgAbs<small_threshold - what will it give me? everything works so well.
How did you implement it? My idea there is just a check if the wheels are at standstill before switching to Speed mode. Usually is better to use a small threshold rather than an exact 0.
And I agree with you on the last comment. However we should check if it is possible. And if yes how much effort is to implement both ADC and remote in the same time.
If the pins used on the right sideboard can be used for i2c, I suppose there is no reason they could not be used for PWM. Can anyone confirm if PB10 and PB11 pins are 5V tolerant? In theory, all you woud have to do is switch the pins used in PWM_Init() (control.c) and the interrupt handlers in stm32f1xx_it.c. The bigger issue would be the handling of multiple input forms at once without configuration becomming too complicated!
If the pins used on the right sideboard can be used for i2c, I suppose there is no reason they could not be used for PWM. Can anyone confirm if PB10 and PB11 pins are 5V tolerant? In theory, all you woud have to do is switch the pins used in PWM_Init() (control.c) and the interrupt handlers in stm32f1xx_it.c. The bigger issue would be the handling of multiple input forms at once without configuration becomming too complicated!
if the receiver is on, then we use pwm, if 0 comes from the receiver (I checked when we turn off the remote, the receiver gives 0), then we switch to pedal mode.
According to the STM32F103RCT6 datasheet
TIM2_CH3
and TIM2_CH4
, which will match perfectly with the Left cable implementation that we have now. Yesterday I downloaded the latest version. I was very glad that they did the steering pvm / In general, it works. But the left wheel breaks at full speed. With a sharp change in the joystick. With smooth control, it works as it should, but sometimes the left wheel spins up to full speed.
I keep thinking about how best to do it. If you can combine the pedals and the receiver , then you need to make sure that there is a possibility of interception. For example: if there is a signal from the receiver and from the pedals at the same time - this is when the child controls himself under the control of the parent and at any time you can press the reverse gear, so as not to crash. Or if the receiver is turned off at all, it means that we only enable control from the pedals. Or if there is no signal from the pedals, but the remote control is turned on, it means the remote control mode only. I think it would be more correct that there would be the possibility of parental control over a small child, for example.
@EmanuelFeru I'm not sure remapping is even necessary. My understanding is that the timer tied to the pin is used for signal generation. Shouldn´t we be able to access any timer within the interrupt handler? I have no way to verify this currently, but simply switching the pins and seeing if it works would do the trick.
@marshalab from what I see you are using stock components, so I think the mapping of hall wires and motor phases should be ok. Still, I advise to double check with the board figure from ReadMe page if it matches just to be sure.
Then I suggest to check cmd1
and cmd2
with an FDTI serial debugger connected to Right cable (short wired) and see if the values are ok and do not jump. You can disconnect the motors for safety (only the phases and leave the Hall connected). You will hear beeping because the motors will not spin, but don't take it into account, because you are only interested if the commands are correct.
@vfear If 2 input sources are connected, then is good to prioritize. And in this case, the priority is the remote. In my opinion, the safety is critical, so for me the remote should always be connected. If the rc signal is lost from remote or remote if off, then the vehicle should stop immediately. So, I think is better to give control to pedals when a certain input combination is done from remote. For example if Steer is not needed, then you can use that channel to toggle control to pedals and back to remote.
@benjaf , Indeed a try would not hurt. However, at the moment I also don't have the setup ready. So maybe someone who already has already an RC connected @vfear what do you say? :) , can just change the Pins and Port from PA2, PA3 to PB10, PB11 here and here, move the RC receiver wires to Right cable and give a try.
yes, great idea. for example, if you turn on the machine and at the same time press the reverse gear on the remote control, or it may be better to do this: When you turn on, keep the pedal depressed. it will be switching modes with or without a remote control. (all of a sudden I’ll give someone a typewriter later. But the remote will be lost or not needed at all in the future)
I'm ready) compile me a hex file. I will download and check
@EmanuelFeru i am change GPIO_InitStruct.Pin = GPIO_PIN_3; to GPIO_InitStruct.Pin = GPIO_PIN_10; and GPIO_InitStruct.Pin = GPIO_PIN_2; to GPIO_InitStruct.Pin = GPIO_PIN_11; after the firmware - nothing happened. The board didn’t react at all to the console, in different connection variations.
@EmanuelFeru My board is with a standard connection, nothing has changed. I connected UART3 38400. I have not figured out the commands yet, but there is data output.
1:495 2:516 3:4 4:4 5:1474 6:3922 7:1595 8:475 1:494 2:549 3:5 4:3 5:1474 6:3922 7:1595 8:475 1:828 2:564 3:-19 4:31 5:1476 6:3922 7:1595 8:475 1:367 2:370 3:-205 4:793 5:1273 6:3916 7:1595 8:475 1:254 2:509 3:-106 4:1000 5:1440 6:3911 7:1594 8:477 1:1000 2:1000 3:-94 4:766 5:1530 6:3911 7:1594 8:477 1:1000 2:1000 3:-188 4:976 5:1415 6:3908 7:1594 8:477 1:500 2:563 3:-209 4:785 5:1477 6:3908 7:1594 8:477 1:382 2:1000 3:-170 4:836 5:1418 6:3908 7:1594 8:477 1:1000 2:563 3:-220 4:778 5:1501 6:3906 7:1594 8:477 1:126 2:509 3:-470 4:740 5:1418 6:3906 7:1594 8:477 1:500 2:510 3:-554 4:592 5:1449 6:3906 7:1594 8:477 1:494 2:546 3:-344 4:406 5:1501 6:3906 7:1594 8:477 1:500 2:560 3:-200 4:296 5:1481 6:3908 7:1594 8:477 1:1000 2:1000 3:-66 4:210 5:1478 6:3911 7:1594 8:477 1:482 2:502 3:21 4:129 5:1473 6:3911 7:1594 8:477 1:494 2:548 3:11 4:73 5:1473 6:3911 7:1594 8:477
Perhaps the control panel gives jerky values. But the servo on these channels moves smoothly.
@marshalab did you also chnage the Port? just a few lines after the pin assignment. GPIOA to GPIOB
@marshalab did you also chnage the Port? just a few lines after the pin assignment. GPIOA to GPIOB
can you compile us correctly? we will check
@EmanuelFeru Changed the lines in the code, compiled, flashed. And of course, I connected the receiver to the USART3 port.
One more note: the left wheel is always twitching. Even if the channels are reversed, the left one still twitches.
Check this bin file firmware_PWM_Right_cable.bin In the build I just changed these functions:
void PWM_ISR_CH1_Callback(void) {
// Dummy loop with 16 bit count wrap around
if(HAL_GPIO_ReadPin(GPIOB, GPIO_PIN_10)) { // Rising Edge interrupt -> save timer value OR reset timer
if (HAL_GPIO_ReadPin(GPIOB, GPIO_PIN_11)) {
pwm_CNT_prev_ch1 = TIM2->CNT;
}
......
......
}
void PWM_ISR_CH2_Callback(void) {
// Dummy loop with 16 bit count wrap around
if(HAL_GPIO_ReadPin(GPIOB, GPIO_PIN_11)) { // Rising Edge interrupt -> save timer value OR reset timer
if (HAL_GPIO_ReadPin(GPIOB, GPIO_PIN_10)) {
pwm_CNT_prev_ch2 = TIM2->CNT;
}
......
......
}
void PWM_Init(void) {
......
......
// Channel 1 (steering)
GPIO_InitTypeDef GPIO_InitStruct2;
// Configure GPIO pin : PA2
GPIO_InitStruct2.Pin = GPIO_PIN_10;
GPIO_InitStruct2.Mode = GPIO_MODE_IT_RISING_FALLING;
GPIO_InitStruct2.Speed = GPIO_SPEED_FREQ_HIGH;
GPIO_InitStruct2.Pull = GPIO_PULLDOWN;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct2);
// EXTI interrupt init
HAL_NVIC_SetPriority(EXTI2_IRQn, 0, 0);
HAL_NVIC_EnableIRQ(EXTI2_IRQn);
// Channel 2 (speed)
GPIO_InitTypeDef GPIO_InitStruct;
/*Configure GPIO pin : PA3 */
GPIO_InitStruct.Pin = GPIO_PIN_11;
GPIO_InitStruct.Mode = GPIO_MODE_IT_RISING_FALLING;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
GPIO_InitStruct.Pull = GPIO_PULLDOWN;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
......
......
}
@EmanuelFeru I updated firmware_PWM_Right_cable.bin connected the right cable. But nothing, there is no control, the reaction is zero.
checked - does not work
Then we need to check in more detail how to handle "remap" pins. Probably i missed something.
I think I know what we missed. To remap, we need to write this register:
And I think we need the Partial remap
10
by calling this function somewhere in Init:
__HAL_AFIO_REMAP_TIM2_PARTIAL_2();
Can you try this bin file firmware_PWM_Right_v2.bin?
I think I know what we missed. To remap, we need to write this register:
And I think we need the Partial remap
10
by calling this function somewhere in Init:__HAL_AFIO_REMAP_TIM2_PARTIAL_2();
Can you try this bin file firmware_PWM_Right_v2.bin?
I check with arduino with the servo library, 1 channel in turn on the blue wire and then on the green - it does not work
Hello. I want to make a firmware VARIANT_PWM using - RoboDurden's online compiler. Please tell me which lines need to be uncommented? I've commented out the VARIANT_PWM string, but it doesn't work, so I guess I need to do something else?