OpenSource Remote for VESC ArduBoardControl

hey s28400

thats a nice case, what are the dimensions (metric plesae)?

I can't explain it as I wan't with my english knowlage, they should be some positiv impulses to improve your case!

There are some points to consider: don't forget the wiring, the screw holes requires a lot of space and the biggest problem is a reliable and small spring mechanism for the trigger/slider.

I started a similar projet as you last year, but I don't have the time to develope it at the moment.
Check out my design, maybe we can work together to improve our designs.
https://endless-sphere.com/forums/viewtopic.php?f=35&t=71599

The Dimensions are as follows:
Height: 127mm
Width (Above trigger): 57mm
Width (Grip Area): 45mm
Depth: 14mm

Yeah I have left room for the wiring and have also planed out the screw holes and mounts, I just need to model them. Yes the spring mechanism, I am still working on. I have seen a few designs that might work, but I am not satisfied with, For now, I have left extra room around that leaver and I will continue to search for the best mechanism.

That's a cool project. Perhaps you could implement the electronics we are working on and the lever mechanism into your own design. I am personally not a big fan of the nunchuck design for a few reasons. One, it doesn't fit nicely in your pocket after you are done riding. Also, the screen location makes it so that your thumb is covering it when using the joystick/lever. Also I think it is a bit small in my hand. These are all things that I have addressed in my design.

Anyway, stay tuned for more updates!

wow, 14mm depth is nearly nothing! I cant believe that.

the biggest problem is the joystick which pushes the depth up to 23mm - it would be realy nice to see your trigger mechanism.
If this is done its realy easy to reshape my case (turn my PCB by 90° and use a slim battery) and the display is at the same position as yours (maybe its space for my bigger screen that consumes a lot more (30mA vs µA)

I definitely stay tuned for further updates

Alright, I went ahead and ordered the parts I need to begin testing everything. Here is the list of what I got:
Display: https://www.adafruit.com/products/938
Feather w/ BT: https://www.adafruit.com/products/2995
LiPo 1200mAh: https://www.adafruit.com/products/258

I also have an arduino joystick laying around so I'll be taking the flat low profile potentiometer from that. Once I verify the measurements of the parts, I will begin 3d printing the housings and testing stuff out. In the meantime, I will continue to refine the model. I have begun adding screw holes/mounts as well as spring mounts for the return mechanism and it is coming along quite nicely.

OK. Did some bugfixing and code reorganization. I also started with a versioning of the commits to the master branch.
So in ArduBoardControl we have the version 0.6.1: including OLED and bugfix/codeoptimization
In VescUartControl we have the version 0.1.3 including the bugfix with the compile problem and some code reorganiztation
Still struggling a bit how arduino use defines in the library hierarchic. How can I use a centralized config.h !?
I can compile both but not test on the Arduino because I don't have my VESC with me on holidays. Please try it out. USe the newest Versions of ArduBoardControl and VescUartControl.

I'm currently working on the VescUartLibrary to turn it to a class so it can be inherited to either a bluetooth or a nRF24 class. So I hope we will have soon a VescUartControl V 1.0.0.

@s28400: Can you send me the models of the feather and the OLED you use for Solidworks?

@RollingGecko: Sure thing, I made a grab cad project with all the files so we can easily share files and update them in real time. Just shoot me your grab cad email and I'll add you to the project.

Hi,

Just transfered the complete library of VescUartControl to a class library. I compiled it. But I have no possibility to test it with the VESC in the next 2 weeks. Is somebody out there who can test at least the VescUartSample in the examples folder? I uploaded it in the DEV branch as 1.0b Version:

https://github.com/RollingGecko/VescUartControl/tree/DEV

You can download it also as ZIP: https://github.com/RollingGecko/VescUartControl/archive/DEV.zip

The code now compiles without problems.
I also have to wait on my VESC to arrive, so I cant test it for you.

Is the program still going to be compatible with an arduino if you are going the use the feather? I know there is a feather with an atmega chip.

Keep up the good work!!

The feather is fully arduino compatible. Currently I will remain on the nano. But the class allows to transfer all communication to the TX site an in the current version it should be compatible to an bluetooth implementation. I currently work on the nRF24 implementation an than I will transfer the communication (packaging etc. to the TX site).

alright, I will keep using the nano for now, maybe I will buy sometime a feather. Still haven't got my vesc yet.....
One more question, is it possible to have this setup without an oled screen? I dont have enough room for a screen on my controller.

To work with the code, yeah I mean you'll just have to change the info output to work with your display. Everything else should be fine.

I did a bit of research on hall effect sensors and I think that is the way to go for the thumb wheel. Here is a great little post of a very crude setup.
http://simhq.com/forum/ubbthreads.php/topics/3225807/all/DIY_hall_sensor.html

I think I will refine this and integrate it into the remote design and once I am done with that, I will begin 3d printing and test fitting. Hopefully my vescs from enertion come in soon so I can start playing with those as well.

Hey there, some questions again.
If I'm going to try this out, do I have to change VESC firmware, or is there already everything merged in?
And can I simply just skip the oled and the vibration alarm without changing any code?
~e~ and sry but can also someone tell me all the connections I have to make (for example: nrf''CSN'' --to--> arduino''A3'' pin), or is that already documented somewhere. Then I could definitely build this myself, and many other too I think. That would be a grat tribute to the community.

To the pin setting for the last time: https://github.com/RollingGecko/ArduBoardControler/wiki/How-to-set-up-ArduBoardControl

Everything is merged to VESC. So you don't need to change anything.

You just can leave the OLED and the Vibrator away without changes.

I currently work on a new implementation for the communication library so that it can be used with a clean interface as well for the nRF24 as for the Serial/Bluetooth. That's why I did not post here for so long. This will still need some time because we have real major changes. The UART version should be releasable soon. I will put it on a separate branch as long as the nRF implementation is not finalized. But at least the UART implementation can be tested by someone. Any volunteers?

Thx I now remember you already linked it some time ago.. had a little break on this project.

The new one you are working on has rf24 and BT? (BT for jacobs app?)

Should also work on arduino pro mini, cause I have some laying around?

Alright so a little update from me, I made decent progress on the design. I have refined the mechanism and have found parts. Here is a video of the mechanism. Note there will be a spring to return the mechanism to center. [youtube]fJ5PC7hjBZw[/youtube]

Also I have found a hall effect sensor that is inexpensive and will provide highly accurate positioning for the thumb control. Here is that part: https://www.arrow.com/en/products/ss495b/honeywell
I have all the parts on order and will begin 3d printing and testing by next week. I will need assistance modifying the code to work with the bluetooth receiver before it can be used with the vesc.
Cheers!

Why does it use ''X'' and ''Y'' axis of the nunchuck, can I skip one?

The Nunchuck-App of the VESC uses both also for light etc. One can be skipped if you send instead a constant (128).

Thx
connect the upper button to pin 2 the lower to pin 3, and the third connection of the buttons to gnd?
what are pin 9 (CEPIN) and pin 10 (CSPIN) for?
VOLTAGE_PIN (A2) reads TX voltage? I plan to use an ubec would be nice cause I could connect in front of it
and sry for that stupid one: is X back and forward or Y?^^
...oh, and whats the size of the cap you have on the nrf module?

connect the upper button to pin 2 the lower to pin 3, and the third connection of the buttons to gnd?

Click to expand...

>>correct

what are pin 9 (CEPIN) and pin 10 (CSPIN) for?

Click to expand...

>>The Data Pins for the nRF-Module

VOLTAGE_PIN (A2) reads TX voltage? I plan to use an ubec would be nice cause I could connect in front of it

Click to expand...

>> I did not understand what you want to do with the UBEC. But this pin is for the TX-Voltage. You can measure any Voltage. Never the less you need to use an Voltage devisor in front of it. You can define the calculation ratio in the config file:

and sry for that stupid one: is X back and forward or Y?^^

Click to expand...

X is back and forward.

...oh, and whats the size of the cap you have on the nrf module?

Click to expand...

>>100µF

RollingGecko said:

>> I did not understand what you want to do with the UBEC. But this pin is for the TX-Voltage. You can measure any Voltage. Never the less you need to use an Voltage devisor in front of it. You can define the calculation ratio in the config file:

Click to expand...

I want use ''arduino pro mini'', and somewhere I read that 2S lipo is to much for that device so I wanted to use an ubec as 5V voltage regulator.

Thx for all you answers

W

Nordle said:

I want use ''arduino pro mini'', and somewhere I read that 2S lipo is to much for that device so I wanted to use an ubec as 5V voltage regulator.

Click to expand...

Why not just use a larger cap 1s lipo? I'd be silly to use a 2s and a voltage regulator especially since space is a premium,

I'm going to use nanos, ordered right now.

I just ordered some nanos for this project as well. Going to use a 1s lipo with an adafuit power boost 500. I wass going to order an oled to play around with, Do i need i2c or spi?

Hi,

The Nano is a good solution and for around 3€ available on Ebay. But it needs 7-12V. So you must take a stepup regulator to use it with 1s. The mini has also a version for 3.3V. But I have no experience with it. I use a capacitor of 100 µF for the nrf module. That is only needed because of the weak 3.3V regulator on the micro (100mA). Maybe it is not needed if a 3.3V mini is used. But take care: the module is sensitive to overvoltage. I killed a couple of these modules with overvoltage.

For the OLED SPI or I2C can be used. The U8glib can support both. For compatibly see https://github.com/olikraus/u8glib/wiki/device.

I currently try to redesign the VescUArtControl Library to combine UART and nRF compatibility with the same interface (class model with a interface design pattern) . At the moment I work on the UART implementation. That is required for the bluetooth Version. But it is not meant to use both in parallel! It will support different deploys (bluetooth or nRF). Currently I'm struggling with the problem, that the VESC does not react on a Nunchuck message with the new implementation. Telemetry works. At the moment I have no idea where the problem is.

In the next step I will implement the nRF communication. Therefore I will also use a new protocol I designed. It is a master/slave design. The RX side is only allowed to send messages when the master allows it. That is necessary because you have to switch between sending and receiving mode. Priority have the control messages. Secondarily are telemetry etc. At the moment I use for the telemetry the acknowledgement messages. But that would be not sufficient enough for configuration messages.
But there is also another work place. The nRF Modules can only handle payloads of 32 Byte. But the VESC has only handlers for much bigger messages. So also some additional handlers in the VESC are needed.

As background: In the current implementation for the communication between the TX and RX simple structs are used. The nRF library I use can handle them. The RX arduino then creates the UART messages that the VESC understands. I leave some values away that I become from the VESC and I think they are not necessary for telemetry.
Because we want also to be able to use Bluetooth without a arduino on the receiving site, we must encode and decode the messages for the VESC already on the TX site. And because of the limitations of the nRF (32 Byte) we need adapted messages.

So far you can use the FW you can find on the master branch. I work on a DEV branch. Also bugfixes etc. can be done on the master.

And there are still the issues with the not correct calculated velocity and distances. And there are still a lot of ideas I want to implement...And...And...And...

So there is still a lot of work to do. If there is somebody with Arduino/C++/C skills who wants to participate: YOU ARE WELCOME!!!

Or should I say: HELP WANTED.