I just got EXACTLY the same email as 5 days ago. This would be hilarious if this wasn’t the thing blocking me from riding my board…
The deadband on the remote is out of bounds.To further prove my point, disconnect the receiver, does the noise go away?
1 Like
I will try that once I have the the chance.
I have been able to test this a little more, and I’ve found that the remote was indeed the issue, at least for one noise. I noticed that there were two distinct noises, one when sitting idle, and one when running on low speed. The first issue has since been resolved with a firmware update, thanks to the quick support of @Wajdi (take note Enertion) . You can hear (and see) the second issue here:
You can see the issue at the wheel visible, the other motor spins fine, but this one makes noise and barely moves till I ramp up the throttle. When I feel the motor it feels like there is a pulling it back in the other direction. I don’t know what’s causing this, it could be the remote or bad calibration or something else entirely. Does anyone know what could cause this? I’m running sensorless here to try an attempt to remove any variables. You can also see a difference in the motor voltages here:
That’s not exactly the source of the issue, the deadband on the remote is pretty minimal and response is accurate, the version of the remote you have was one of the very first iterations, latest version have gone through hundreds of changes and improvements.
After he sent me a support request email, we went through the problem and it was a compatibility issue with Unity. We fixed it using a firmware update on the receiver.
@atlasdev The remaining jittering issue is most likely due to your senseless setup, also when running a dual setup, both motors might not start at the exact time and position, this is usually noticeable on very low RPM.
1 Like
I’ve also tested the motors in sensored mode, but this didn’t change anything, see the video below. You can really see the motor not responding correctly at about 0:06. You hear the other motor spinning up, but the motor in view barely moves. As you can see I swapped the wires since last video, to just make sure again this was not an issue with the motor itself. It also shows again a huge difference in voltage shown in the telemetry data
I tried to attach my board to the VESC tool again, and I noticed again that the second motor shows as sensorless. When I change it to sensored and reconnect the board it switches back to sensorless. What could cause this? I tried swapping the wires of the two motors, but the issue stays at motor 2. This means there is nothing wrong with the sensors or the wires to them.
Not sure why the other motor is not receiving correct voltage. The receiver sends a command to the master vesc with the joystick value, master vesc then processes the command and sets appropriate current to the motor. The master motor spins fine, which means that up to this point the receiver has done its job and it is now up to the master vesc to forward the correct commands to the other vesc.
Synchronization problems in dual vesc setups have been around since the very first versions, not sure if anyone has ever looked into this or found a fix.
1 Like
I’m using a Unity here, so synchronisation issues should be minimal (it’s using a single SOC). The reason I might expect the receiver to be the issue here is that the previous issue (which has been fixed) also happens on one and the same motor. It’s not impossible that it is a synchronisation issue.
@CarlCollins could you weigh in on this?
You are correct, it seems like it’s only using one micro controller. After searching around I found that Unity has an extra argument to control the second motor separately, so instead of sending one command and apply it to both motors, they made it so you have to send command for each motor separately ( I don’t understand the reasoning behind this design ). Here is where it’s mentioned https://www.electric-skateboard.builders/t/focbox-unity-support-setup-troubleshooting/77861/371
That being said, I’m going to apply the changes and send you the update.
1 Like
I spoke too soon, some commands do indeed require both motors to be set in Unity like
case COMM_SET_CURRENT:
ind = 0;
cmd1 = (float)buffer_get_int32(data, &ind) / 1000.0;
cmd2 =(float)buffer_get_int32(data, &ind) / 1000.0;
mc_interface_set_current(cmd1,cmd2);
timeout_reset();
break;Where cmd1 is for motor 1 and cmd2 for motor 2,
However the nunchuck command, the one we are using, only requires one value, and Unity should handle controlling the other motor accordingly
case COMM_SET_CHUCK_DATA:
ind = 0;
chuck_d_tmp.js_x = data[ind++];
chuck_d_tmp.js_y = data[ind++];
chuck_d_tmp.bt_c = data[ind++];
chuck_d_tmp.bt_z = data[ind++];
chuck_d_tmp.acc_x = buffer_get_int16(data, &ind);
chuck_d_tmp.acc_y = buffer_get_int16(data, &ind);
chuck_d_tmp.acc_z = buffer_get_int16(data, &ind);
app_nunchuk_update_output(&chuck_d_tmp);
break;The command accepts a joystick value, and Unity should handle controlling both motors appropriately.
Is your other motor still not detected as sensored? Your R and R2 are 0, were you able to do the motor detection?
Yes, it’s still showing as sensorless. I am able to do the motor detection, but I’m not sure what you mean with R and R2 are 0?
On your screenshot, they are highlighted in red.
I suggest you disconnect the receiver, and try to get the motors detected properly with the sensors working.
I restarted the tool to get the values, which are not filled in by default. Here is a completely new detection.
I’m now having bigger issues, the connection to my Unity seems to cut out :(. This is both on usb and Bluetooth. I want to try to update the firmware but, well, my connection cuts out. I’ll try again tomorrow, but it doesn’t look great…
Hi, my unity keeps disconnecting and stops responding to commands. I’m trying to flash the firmware again in an attempt to resolve it, but this keeps timing out. When I start it up the error led flashes once. What could cause this?