I am attempting to run the basic position control example (link) with the exact same hardware as listed. When setup on an R3 it works as intended but when attempted on an R4 the gimbal motor sounds like a tattoo gun at all times. Constant high pitch noise when at rest and when in motion. Does not appear to be effect by changes in supply voltage.
I checked the FOCsheild jumpers and all are soldered correctly. I also tried two other gimbal motors I have and both had the same issue.
I am thinking it has something to do with the clock speed and/or PWM frequencies. I tried using driver.pwm_frequency = with varying values but it did not seem to be doing much.
One other odd thing that is unrelated to the above but interesting, when I run the motor CW it is very smooth & quiet. When I run CCW it is noticeably rougher and pulls 4x the power as compared to CW. Any ideas on why this would be?
Appreciate any help or guidance any of you may have on this.
Update: I pulled the dev branch library as I saw there were updates on this exact issue but now the motor does not seem to be initializing as there is no response in the serial monitor and no sensor alignment etc… maybe @runger could help me out here.
IDK about the other issues, but fundamentally if you want a system to be quiet it is actually a lot of work. There are dozens of ways a system can produce noise. You can start with a quiet system and add features or you can start with a noisy system and try to modify it to make it quiet. I started at the quiet end, it worked but took forever.
On another note, I wish you luck and it amazes me how talented some of the people on here area and how they can actually get stuff like this solved, but fundamentally, expecting to be able to take a whole code base which involves all kinds of low level hardware stuff and get it all working on new hardware is not a weekend project for a hobbyist.
That’s why I am a fan of taking one good board, which we don’t quite have yet (hopefully one of the third gen lepton variants will be that board), get everything from serial and can bus and timers and dead time and current sensing and everything else you need working on that one board… and then everyone has what they need, in this class of hardware/software system for years to come.
To try to get dozens of boards and hardware combos, which provide nearly the same functionality, working, is only leading to a collection of partially working solutions, none of which are really good enough and cheap enough for most things most of the time.
Just an aside, not to discourage you, but this is just an important pattern that’s worth noticing I think.
edit: to try to actually be helpful, your best bet is probably a g431 nucleo board like this one: NUCLEO-G431KB STMicroelectronics | Development Boards, Kits, Programmers | DigiKey
I noticed the b-g431b-esc1 board uses a slightly different processor, the CB variant instead of hte KB one, idk what the difference is but it’s usually minor. As you can see it’s the same price as an r4, however they aren’t licensed for use in actual products where with the r4 and rbpi pico you can use exactly the same board in your actual product.
Hi @Cazo ,
The support for the Renesas MCUs used on the UNO R4 is very new, and so far only on the dev branch of the library, not yet in any release.
So it can only work if you use the dev branch.
Also, it is working for me so far only on the UNO R4 Minima, but not yet on the UNO R4 Wifi.
On the R4 Wifi there is a crash which I am still trying to track down the cause of. Clearly the R4 WiFi is using the underlying Renesas framework a bit differently to the R4 Minima, and that is causing this crash.
So if you have a Minima and want to try out the new code, please use the dev branch. Otherwise, please wait until the next release, in which the Renesas support should hopefully be included.
Thanks for the reply. Interesting that the R4 Wifi and Minima would be so different. I will keep an eye out for the next release. Thanks for working these compatible issues for folks like me.
Actually the MCU used is the same one, but interestingly the pins mapped out to the Arduino headers are different in some cases.
Also, of course, there is considerable difference in the framework level, due to all the extra peripherals loaded onto the R4 Wifi…