OpenSource Remote for VESC ArduBoardControl

[RollingGecko]

Questions I get by PN but that can be interesting for everybody:

can you tell me if it is possible to use nrf for telemetry or do i have to use bluetooth? If so, what bluetooth module do you recommend?

Nrf is possible but I will stop developing on this hardware with the release 0.7 I will release it the next days. It has full telemetry and all bugs as far as known were fixed.
I still don't know which bluetooth module to take. Will start this topic the next days.

Hi, can you tell me if there is a specific oled display that I should use? I saw some on ebay, but some of that have a lot more connections that other.

That is not so easy to answer. I had also trouble with some found on ebay. I would recommend I2c Version. The easiest answer I can give you, that they should be compatible to ug8-lib. They should have a SSD1306 chipset.

[RollingGecko]

Is already somebody else out there with a running remote? Than give us please some feedback.

[Pedrodemio]

I'm using it with a few modifications for leds(was using, my board is down for a few months so far)

Try using the abs tachometer, any situation that makes the wheels go backwards? this would add negative distance if the abs is not used

[RollingGecko]

Hi,

Now here we are with the official release V0.7.0 with the following features and bogfixes:

- Bugfix: Average calculation for current and rpm added. No more nervous values displayed
- Different Screens implemented and switch between them
- Bugfix: calculation of Distance and speed
- Bugfix: mAh used now displayed correctly
- Speed and current maxima detection and displayed
- Small cleanuop in config.h

This Version is tested and stabile.

With this Version currently ends the development for nRF24 hardware. We switch to bluetooth.
Maybe nRF24 will be supported in future if other developer enter the project.

Here you can download it: https://github.com/RollingGecko/ArduBoa ... sedVersion

[RollingGecko]

Try using the abs tachometer, any situation that makes the wheels go backwards? this would add negative distance if the abs is not used[/quote]

You can use the reverse or simply roll the board backwards. But that should not influence the result that much because the reverse should not be standard on an eboard.

[buzztiaan]

I wrote my own arduino-nrf24 code , without a display.

I'm not so happy with it and need to clean it up some, but will share. Also need to look at your code, maybe it can run on my hardware.



Mostly looking for insight in making the throttle behave non-linear and maybe have some fake 'shifting' or something.

Love the springed magnet/hall effect setup! Really slick, gotta try printing that some day What material did you use for it?

[WTech]

With this Version currently ends the development for nRF24 hardware. We switch to bluetooth.
Maybe nRF24 will be supported in future if other developer enter the project.

Here you can download it: https://github.com/RollingGecko/ArduBoa ... sedVersion

Any reason why you switched from nrf24 to Bluetooth?

[Pedrodemio]

[*]Funny thing, when everything seems to be going, something have to screw up

Was on the verge of finishing the board again, testing on 10S for the first time, BLDC working, FOC working, and then on one of the accelerations on the bench the motor just made a high pitched sound and after rebooting it i get no response from UART, anyone experienced something like this? controlling via BLDC tool works just fine, no faults and the Arduíno serial is ok

Edit:

Started working again, reason? no ideia

I guess my VESC has some power issues, i use a RC filter to supply the Arduino, without it doesn't boot, maybe on 10S i got more noise on the 5V rail or something like that

I will take it easy on the first rides to see if the problem repeat, if positive i will find someone with a oscilloscope and take a more scientifically aproach

[RollingGecko]

Please make these test really careful. It sounds dangerous.

@WTech: Please read a bit through the thread. In general it was more a community decision. One the one site is there the feather board with bluetooth and on the other hand we would not need anymore an Arduino on the board site. I already prepared an interface design, that would allow also the use of nRF24L01. But we need a new and reliable protocol for a bidirectional communication. If somebody can take over that part he is welcome. I can sketch him the design of a possible protocol.

Allso on the VESC meanwhile an direct nRF implementation is realized. I lost the focus a bit on that. But the issue is, that I've no idea how the protocol is defined and hoe to handle it on the arduino site. If anybody has here more information he is also welcome. Maybe that is also a good approach.

I still have to try to establish a bluetooth serial connection with this new chip. At the moment I'm a bit blocked by other projects as well.

Andy

[RollingGecko]

I was digging now a bit deeper into the bluefruite topic. It has a nRF51822 chip from Nordic. At the moment it does not support central mode.

Here the statement from the Adafruit faq site: https://learn.adafruit.com/introducing- ... friend/faq

Can my Bluefruit LE module connect to other Bluefruit LE peripherals

No, the Bluefruit LE firmware from Adafruit is currently peripheral only, and doesn't run in Central mode, which would cause the module to behave similar to your mobile phone or BLE enabled laptop.

At some point we might consider a new firmware image offering this, but since 98% of the uses cases for BLE involved running as a peripheral we've concentrated all of our development effort there for now.

So at the moment a complete show stopper. We can hope for the future.

Another chance would be, that the nRF51.. can also handle shockburst mode of the nRF24L01 with some handling in the SDK of the nRF51. So deeper digging is necessary to implement this. That is nothing I can handle short term. Maybe somebody of you know somebody...?

As an alternative we can go on the Feather MO board without bluefruit and use the nRFL01 module. The switch to the feather is longterm necessary because we run out of memory on the 328 chip. I already use 86% the flash for the V0.7.1.

At the moment we have a stable release that is practical for the daily use and allows still some features. But no configuration capabilities. I#m sure the magnet sensor implementation should fit in. That is a strict requirement either it is a great invention! On a Dev branch of the UartControl Library is already a first version on a general communication interface parked, that still need the implementation of either nRF24L01 bidirectional communication.

So if you guys can live without VESC configuration capabilities at the moment and nobody with strong wireless communication skills will join the development, we can keep version 1.xx in the development branch for an unplanned future date and go on with V0.7.1? Only transfer it to a hardware with more resources (Feather M0 is preferred because it has plenty of resources and already build in lipo charging capabilities).

[Dude]

Bummer - too bad. I currently ordered the Feather-M0 BLE and wanted to join in. I'm not sure if I missed the core of the problem, but can't we use the HM-10 BLE Module at the VESC side and configure this one as the master to set up the connection with the Feather which can be used only as a slave?
http://www.ebay.de/itm/like/30197073544 ... noapp=true

[RollingGecko]

From the technical site this is possible but I don't see it as a good solution to set the board as a master. Once we have a bluetooth module on the VESC we should also be able to use it with the mobile phone. There are already projects that realize that. But they need the VESC site as slave. I know that it is bad if the hardware (feather) was already bought. But I have at the moment also no further solutions than posted before.

[Dude]

Ok, true. I don't mind having having some spare gadgets to play with.
I like the idea of using a BLE module on the VESC side, it's just a lot more elegant than using an arduino plus nrf for RX. How about the following thoughts. I suppose that if the wish for an firmware update using the feather as a master is seriously adressed to adafruit it will be solved after some time. In the meanwhile, we can just use two HM-10 BLE (they are really cheap) - one configured as a master, one as a slave. Just use the appropriate HM-10 for your current purpose. Should be possible, since even with a feather configured as master you won't be able to use the ArduController and a mobile phone in parallel. Do you think this is feasible?

[s28400]

Wow, this is really a bummer. I really think we should stay way from RF though due to the possibility of interference and if multiple remotes are in close proximity.
Adafruit states that it is a firmware limitation. Perhaps we could load a different firmware on it or request an update from adafruit? If not, another option would be WIFI direct. I was told It has similar pairing to bluetooth but the protocols are much easier to work with. Also adafruit has a feather with a built in wifi module that has soft AP support so it would be fairly seamless if we could get that to work. Although the phone app would be complicated with that as you would have to switch wifi to connect your phone to the board.

Since it seems to be a limitation of firmware, I will try contacting adafruit to see if they would help us out. If not, I will also look into flashing the firmware to a non adafruit version that supports central mode.

Cheers!

[Jeefberky]

Great progress on the remote, it looks great!!
I hope you will find a solution for the RF.

I finally got my vesc and tried your program but unfortunately I can't get it to work. I changed some pin numbers in the TX side since I solderd the wires on my arduino board and used some other pins for my program.
The pins I had to change are:
upper_button from pin 2 to 4
LED_PIN from pin 4 to 2
Potmeter to A3
vibrator_pin from A3 to A0

The NRF pins are still the same.

If I turn on debuging, it does not show anything (the baud rate is correct).
Did I change something crucial?

The vesc however works with my simple ppm program.

[RollingGecko]

On the quick: Debugging only worked up to now on a 2560 with more than one serial port. Don't forget that we use the serial0 to communicate with the VESC.

For the first test it would be the best to read the stream on the serial from the RX arduino.

[s28400]

I have reached out to adafruit and one of their support guys said that this has been requested before and that their developers will look into it at some point. Perhaps in the meantime a good balance of tradeoffs for everyone would be to continue using the feather in the remote side and have it as a slave device. I know that vedder stated the VESC has lost of leftover processor power for custom code. Would it be possible to use the Bluetooth module over UART and have some custom code running to set it as master/central mode? This would eliminate the need for an arduino VESC side. Although we would not be able to use the phone app, we could at least continue moving forward with what we already have and if/when adafruit releases a flashing utility for their BLE, we can switch back to having the remote as master.

Also, once we have the hardware figured out, I am planning on designing and manufacturing a custom PCB for the remote. If adafruit hasn't released their firmware by that point, I could use a different BLE module on the PCB that could be set to central mode.

Let me know what you guys think,
Cheers!

[RollingGecko]

I hope also that adafruite releases a new firmware soon. The used framework in the VESC makes it to complex for me to implement the required code to bring the ble module in central mode.

At the moment I'm not sure if it makes sense to create an own PCB as long as the feather module fulfills all the requirements (or will hopefully fulfill)...

[s28400]

Ok so some more bad news. The site admin of Adafruit replied to my request and stated "the chipset in the current Bluefruit BLE does not support central mode. a completely new design would be required, there is no ETA on a new design."
So that sucks, I was under the impression that the issue was a firmware one and not hardware based on the faq.

So at this point we have two routes I think we should consider. Either stick with the feather and work on making the VESC side master, or look at other bluetooth modules and do some breadboard testing so that I can make a custom solution once we have something that works. If we go with the first route, we may be able to use two bluetooth modules on vesc side (one master and one slave) so that a phone could be connected in addition to the remote. If we go the second route, we might even be able to desolder and replace the ble module on the feather. I have the re flow equipment to do so on my end and I could do this for you guys if you needed it.

On a side note, my VESCs are scheduled for delivery today so I can finally join in on the testing!!!!

Let me know what you think,
Cheers!

[RollingGecko]

We have not enough interfaces on the VESC site to consider 2 bluetooth modules. Maybe we should not stick to the bluetooth solution. As already said the nRF is already implemented on the VESC so that we can easily communicate to the VESC with some research effort to communicate directly to the VESC without the requirement of an arduino on the board site. I'm not sure if a bidirectional communication is considered on this implementation. But it could be worth to adapt it.
The desoldering of the bluetooth module on the feather is not really required because there are also feathers without them. Another possibility to use the remote as a bridge between phone and a nRF connected VESC.

[s28400]

Ok, would it be possible to use the feather with the built in radio? Like this one here: https://learn.adafruit.com/adafruit-fea ... e/overview Or is that a different kind of radio?

Also would there be concerns with safety (ie another rider in proximity sending packets to your motor controller or vise versa)? I know you can define a unique address on some of the RF modules and some will even scan for radios on the same channel and switch to a new one mid use. Would we be able to have some kind of system like this to ensure no interference/hijacking?

[s28400]

I have been researching bluetooth module alternatives and have found a few that we should consider.

A fairly new ble module with central support is the bl620 series. Here is a link to it: http://www.digikey.com/catalog/en/partg ... vendor=776
These have excellent power usage and they even have some kind of basic language for protocols. It would be fairly easy to work with these because of this. However, they are surface mount so a pcb of at least a breakout board would be necessary).

Another one I found was actually the same module used in the boosted board remote and motor controller. It's the br-le4.0-s2a module and here is a link for it: http://www.blueradios.com/hardware_LE4.0-S2.htm
This module supports several different modes including central so it could be used in both the remote and vesc side. This module is also surface mount so a breakout board would be necessary as well.

We might just have to end up using nRF but I think we should look at all the options first.

Cheers

[Jeefberky]

RX and TX are communicating with each other. On the VESC side I have tried UART and nunchuck in the app configuration tab in BLDC tool and set control mode to current. But still no response from the VESC. I'm going to check the connections I'm clearly doing something wrong

Serialmonitor says f. I have connected the TX from the VESC to RX of the arduino and vice versa.

EDIT:

I did had a bad connection between the vesc and RX arduino. The arduino is now getting data from the VESC (RX light is blinking and serial monitor does not say "failed to get data from UART") but the VESC still does not respond. The baud rate is set at 115200. Aslo when reading the RX arduino over usb, only the y-value of the thumbstick changes, even if I swap the pins used for x and y, the same problem occurs.

EDIT2:

I tested the VESC UART output with the VESCUARTcontrol example, loaded on a arduino, and I do see data comming in from the VESC (No problems on the VESC side).
I now soldered the wires TX side as mentioned in the config.h and tested if the data from the TX side is arriving at the RX side. All buttons work and only JOY-Y works, even If I swap pin A0 for A1 in the config.h (still the same problem as mentioned above. I did not change the TX sketch this time).

The configuration for the VESC is still a bit unclear. What do I use? UART or Nunchuk? Because the VESC does not respond on any input.

EDIT3:

Got it almost working. I had an older VescUARTcontrol library installed . In BLDC tool I can now see the position of the thumbstick in the nunchuk tab.

I now have a problem with the controls. I have to keep the Z button pressed to make the motor spin. If I release the Z button, the motor keeps going on. If I press the Z button again, the motor stops spinning but the next time I throttle it up it spins in the other direction.

Cruise control also has some problems. If I spin the motor and press the cruise control (C) button then the motor will maintain the speed. If I release the C button, the motor keeps on spinning. I can not change the speed of the motor with the thumbstick.

I don't think the motor/VESC should behave as discribed above.

If I power off the TX, the motor stops (as it should do ).

I think my buttons are reversed somehow.

EDIT4
I reversed the behaviour of the c and z buttons in the sketch and changed some nrf24l01 settings because I had some connection issues. Now the controller works great!

[Nordle]

I have a problem too
Tried it out today, but doesn't work for me. I can't read anything from the RX side in the serial monitor, just some chinese/russian dialekt regardless the baud rate i choose?

[RollingGecko]

@Jeefberky: Great job!

@Nordle: That must definetly be an issue with the serial configuration. You should use 115200 Baurdrate to read the information coming from the RX as this is set by default.