Feature not a bug haha. Coded that up.
1 Like
Don’t get me wrong the unity is really pretty. Super easy and smooth setup. These are details. You are doing really well. Am I using the later firmware? 23.41?
Think so but I’m uploading a release tonight or tomorrow morning early so I’d recommend jsut updating FW then.
3 Likes
Setting up my unity now but I’m very dumb when it comes to settings I should set. No discredit to you, the UI is wonderful. I just have no frame of reference as this is my first vesc based product. Anyone free to help?
pm me or ask here my friend.
Think we could post specs and you give us an idea of what to set? 
How to get a video imported here ? dropbox link?
there are mono burn marks, Ive checked . still searching how to import the video .https://www.dropbox.com/s/9e3yz3vb5dubi97/IMG_1812.MOV?dl=0
The behavior you are seeing is perfectly normal, one motor takes slight more current to turn than the other. Do too many factors, friction in chain, bearings, slightly different motor parameters etc. Once passed the 4-5A mark, both wheels spin freely.
You can also see that the wheel that stops first is the one that requires more power to turn.
Could this be you heel side?
To show video, you simply need to paste the youtube link it will embed itself in the post
What is the difference in baud rate settings for the unity in regards to the nano-x remote? My only knowledge of baud is information throughput yet both seem to work with the nano remote.
Usually baud rate refers to the UART port and therefore like metr module or HM10 bluetooth module. Nano-X use PPM signal which is another thing.
1 Like
Got it, thank you. I thought it was odd under remote config but that makes more sense now.
yeh also in vesc tool is under remote configuration. There are several types of remote. Like firefly ask the uart port to get the telemetry data from the vesc. If you only have the nano-x you can disable the uart port.
Thanks for your help . But it can’t be the motor with bearings and parameters. Because same thing happen with my 5035 motors. Also I switched both 6374 motors with motor#1 and motor#2 output from the unity, and same thing is happen with what ever motor I connect to unity outlet #2. I loosened up the chain also. It is not really good to see in the video but final RPM’s from both wheels are really different ,visible with my eyes for sure. So it seams to me its has not much to do with the motors or the chain . And yes , its my heel side correct . Another test Ive done - trying to simulate a brake on both wheels with a glove - the available torque on motor #1 is incredible high. motor#2 is so weak that it doesn’t take much effort to stop the spinning
prob not the best approach lol, be carefull
only other thing i can think of is maybe a flaky solder joint on the bullet connector of the phases Unity side… that’s just a shot in the dark, maybe worth checking
can you show your motor detection results? a bad joint would show there
yeah, the glove test is not really a reliable scientific test, lol but I looking for more clues.
actually I was thinking building two rollers with a adjustable measurable brake - to test under resistance ( not sure the right term , me ESL)
I checked optic and measured the bullet connectors , all good . All JST connections are very clean ,nothing bend
any other tests I could do ? The FocboxUI is limited and basic, so I can not change settings for each motor . But the Focbox_tool allows this. what parameter should I work or play with for motor#2 ?
Just in case it’s more logical to ask this here.
I already shipped the unity back for replacement per your helpdesk team today.
1 Like