Simple 3D-printed NRF remote - Arduino controlled

Yeah I tried ic2 scanner - I get unknown error and then 0x and few values … ic2 was connected correctly.

Well if the I2C scanner doesn’t work, I think you are right. The screen probably is defective :confused: I will try to run an I2C scanner on a spare OLED display I have, to see if it can find that :slight_smile:

EDIT: My spare works just fine, tried to use the I2C scanner and got the address: I2C device found at address 0x3C. Yours are probably defective :confused: ! How you used good wire, and checked if there a signal through all four cables (with a multimeter)?

1 Like

Ive check and had voltage on one out of two wires ( SDA I think) . I wasn’t to precise with multimeter there might have been voltage on second one but anyway I have up :wink: in couple of weeks I’ll get a new oleds :wink: no worries. Or might order one from eBay for double the price of China import :wink:

speedDevider = magnets / 2 * wheelPulley / motorPulley / (wheelSize * 3.14159265359 / 1000) * 60 / 3.6; distanceFactor = (wheelSizeInMM / 1000) * 3.14159265359 / (wheelPulley / motorPulley) / magnets / 3;

speedInKm = ERPM / speedDevider speedInMi = ERPM / (speedDevider * 1.609344) distanceInMeter = tachometerAbs * distanceFactor distanceInKm = tachometerAbs * distanceFactor / 1000 distanceInMiles = tachometerAbs * distanceFactor / 1609.344

Thanks @Ackmaniac! I am curious if you got all the parenthesis right? Could you write them in some kind of math program, to better visualize the equations? Where does the 3.6 come from? :smiley:

for calculation from meter per second to km per hour 1hour = 3600 seconds

Ohh okay, I think it’s a very nice, but however very complicated equation you got - how did you deduce it :stuck_out_tongue: ? I tried your equation, and it gives the exact same value as mine. So it seems that there are two solutions to the same problem - nice ;)! Good to have something to choose between.

Your method to calculate distance works great too, however, I think I prefer my own. Feels a little simpler to me.

Thanks for the input :slight_smile:

4 Likes

Did a Little bit of mathematical reformulation and can confirm that both Solutions are interchangable…except of the tens potency :wink:

Btw. take my application as a potential tester. Mechatronic Engineer from Germany with 3D Printer and programming experience.

1 Like

Another issue you will come across is that BLDC gives you correct tachoAbs and FOC not (10% - 15% off) with the standard 2.18 firmware. In my firmware mod 2.54 this issue is fixed.

I am going to post a few concept screens I did this morning. I have redesigned pretty much everything :slight_smile: So I hope you don’t mind.

2 Likes

I just had a look at your throttle calculation and it isn’t correct. Problem is that when the center position isn’t exactly in between the max and min analog readings it will overshoot the min or max and underestimate the other side. Means you will loose throttle range in one direction and wont be able to have full output in the other direction.

e.g. center is at 500, max at 600 and min at 300 then you calculate the offset as 50 ( 500 - ((600 + 300) / 2) ) when the throttle input is now 500 = center then you get 127.5 as output which is correct but when you have a throttle input of 600 = max you get 212.5 as output which isn’t 255 same for 300 = min as input which results in -42.5 and not 0

Long story short. If your analog readings detect bullshit only one time (for example when the remote passed another magnet) your remote becomes dangerous. And if you switch on the remote and have it at full brake while you switch it on your board will run off ones you release the brake because you detect the center position at startup.

I leave you with that homework

4 Likes

That’s some serious stuff :confused:

Ackmaniac has good feedback!

The quality of the throttle sent to the vesc is cruisal. I have learned it the hard way through the development phase of my board haha!

In my nunchuck design, I have added an accFactor to the analog readings from the throttle. I can thereby cycle through different accFactors while I’m driving… and thereby get different acceleration profiles. I find it more secure to be able to cruise around with low torque and only use the boards full potential in areas where I can handle it.

simple example of equation: Throttle sent to VESCs = 127 + (Y_axis - 127)/accFactor. (where Y_axis = 255 at full throttle)

Increasing the accFactor will decrease the amount of throttle that can be sent to the VESCs, still being able to use the whole throttle range of the nunchuck.

I also do not allow throttle unless the wheels are spinning for extra safety. This means no start from stand still but I always push away anyway.

Right now I try to figure out how to handle a situation of signal loss or corrupt data. Not sure how I want it yet… it all depends on how i ride the board when the data loss occurs. Sending zero throttle to the VESCs during a loss at constant speed is okay but NOT during acceleration… That is scary :O.

I will create a smooth ramp down of the throttle at that point… and if there is data again… not allow full power immediately since I wont be ready for it. It will be amazing :slight_smile:

3 Likes

Well, if you only allow throttle when the board is rolling then that will make it more dangerous. For example the remote want’s to go full throttle because of a problem you only will find out when you stand already on the board. Throttle ramping makes it on the one side safer but on the other side also less safe. Because if you need to make a full brake you loose meters until it ramped down. And i like a direct throttle instead of a softened throttle. But that is personal preference. And ramping is already included in the nunchuk software of the VESC. Mostly i disable it.

Actually that makes me think about to improve the failsafe of the VESC itself. There a slow ramping would make a lot of sense. But sadly the PPM users will not benefit from it because the receiver sends a default signal when the connection is lost. Only when the receiver also dies it would work. And a slow ramping back to the actual throttle if the connection is back after a timeout. Fuck that idea is great and it will prevent a couple of broken bones and brains.

Time to earn some more karma points :innocent:

I am not sure that I agree. When the remote boots, it gets an average reading for the Hall sensor in its center position. This value will always be the center. However, the placement of the Hall sensor and the quality of magnets will, of course, make the min and max value different from remote to remote. This means that the value from center to max isn’t necessarily the same as from center to minimum. Therefore I calculate the offset value, which is used to keep the throttle value at 127 (in neutral position) even though the max and min don’t span over the same.

Sure if you get a much higher max value than the minimum value, the braking resolution would be lower, however, you will still be able to do a full brake (<0) and release the throttle to the neutral position (127). The only thing affected would be the max throttle value (because I minus the offset). I have done this because I think it is more important to be able to do a full brake and get a neutral value of 127 in the center position. It’s not a perfect solution, however, if you got a better way I would love to hear it :slight_smile:

I agree that constantly updating the min and max value, could be problematic if you entered a very powerful magnetic field (however the max value would never be over 1023). Maybe I should instead make a calibration option, so the min and max are remembered in the settings - and doesn’t update while using the remote. Regarding the calibration at startup, what else would you propose? It isn’t that hard to not use the throttle while the remote is turning on :slight_smile:

The same issue is in your code for braking. So if the center is at 500 and the max 800 and min 400 then at 400 you only get a value of 63,75 and not 0. So the brake would be only roughly at half. And at switch on it is easy to accidentely touch the throttle and when you release it the board goes flying.

To gain some more karma points you should give this a try

if(hallMeasurement >= hallCenter){
    hallSpeed = constrain(map(hallMeasurement, hallCenter, hallTop, 127, 255), 127, 255);
}else{
    hallSpeed = constrain(map(hallMeasurement, hallBottom, hallCenter, 0, 127), 0, 127);
}

and set fixed values for center, max and min. And make them changable with a calibration via the menu

2 Likes

Hi! Awesome work! I’d like to be a beta tester too if possible. I have a spare VESC 4 you could loan if you still need one for testing (I’m in Sweden).

No worries, I’m able to test the board from standstill if I want. Just pulling the stick to the right during startup will allowing throttle at standstill ;). I just want to avoid the following scenarios:

  • Racing the board away into the traffic like a RC car without me.
  • Spinning the motors accidentally while carrying, destroying my jacket

Let’s say you have a loss at zero throttle (or a little brake), then it would be nice with a ramp. I already have it and it is smooth. It makes you first realize something is wrong and then more and more braking force is applied. You stop quick enough and if not, then you have lowered the speed enough to jump off without falling to the ground

I don’t mean the throttle to be softened like turbo delay. I just make the board weaker so that if I throttle to hard by accident, I won’t fly off :slight_smile:

In the scenario when you are throttling its harder to have a good fail safe. In earlier design I had lots of communication issues (bad soldering) so I increased the amount of time a loss could be allowed. I then kept the throttle at the last successful received data. This is not a good solution since tapping short on the throttle and having a loss at the same time would cause the board to fly away when you don’t expect it.

In a scenario with a loss at low speed and high throttle, I would make the positive throttle decrease before breaking. Too quick change of torque is what makes me flying

In a scenario with a loss at close to max speed, I think the throttle could decrease faster since less positive torque would be applied to hold the current speed. Better to slowly apply breaking force… its less likely you need to panic brake when running at full speed.

Thanks @Ackmaniac, and of course you are right! I just never had any issues, probably because my Hall Sensor sits firmly in the middle :slight_smile: ! I will try to implement your code as soon as I get it tested - and I am working on a calibration menu for fixed min, max and center values :slight_smile:

Thanks for the example!

@Norrmalm I think we got room for a couple more :stuck_out_tongue: ! I have added you to the list!

Is the part list up to date ? I know you have been looking into boost + overcharge board instead of boost only. have ordered most of the parts already, just making sure nothing has changed in the meantime.

I’m hardcore - I’ll wire it up and solder myself haha! :muscle:t2::rofl:no need for prototype :joy:

Would you have wiring schematics somewhere to share ? Otherwise I’ll be happy to trace wires on the pictures of the build. I rather keep same wiring as you so I don’t have to change pins in the code.

Btw are you making custom pcb to connect all parts together rather than using wires?