Your picture his the plug going into the debug header, but shouldn’t it be going into the uart header?
I have yet to play with @Ackmaniac’s firmware and an HM10 module, but I think using the UART port will make users choose one or the other. Can this firmware simply sniff the green Tx line for state changes if a bluetooth module is installed?
/edit
How could I add a second strip - one on each side of the board - that have duplicate functionality?
Ah… You right, the picture was wrong! Shame on me) I corrected this. Thank you.
The best option to work with bluetooth module and arduino on the same VESC uart is take arduino with two uarts. And connect arduino to VESC uart and bluetooth module to second uart of arduino, but this will need some code rework.
To add second APA102 led strip just connect it in parallel with first one to the d11 and d12 and gnd arduino pins(You, also, will need second LM2596HVS converter for second strip because one of this can take only 3A current.)
OK! So I got this up and running last night. Works great!
Some notes:
I went and zipped up the sketch and libraries. Simply upload this zip file to the on-line arduino IDE, Arduino Create. Should compile right away and the FASTGPIO and APA102 libraries are already available. Works great and web access is nice!
My arduino pro mini would not upload when connected to the TxRx of the VESC, even with the VESC powered down. I had to break these connections to get it to upload. Not the end of the world, just something to be mindful of.
I had trouble getting the police_pallete to work. My LED strip is 29 modules long, so I changed
‘static const uint16_t CURRENT_PALLETE_WIDTH =29;’ I modified police_pallete too.
Also, I had a thought about how to avoid using UART entirely. Could we attach the output of two of the motor hall sensors to INT0/1 to get the motor position? This might mess with FOC, but I’d bet that it wouldn’t.
Hmm, interesting, because I was able to upload firmware when VESC is powered down… Thanks for info, man, I must add these instructions to Github readme.
You don’t need to set CURRENT_PALLETE_WIDTH to LED_COUNT.
CURRENT_PALLETE_WIDTH must be equal to pallete elements, for example, if you want to create new pallete with 3 elements:
const hsv_color pallete_name[3] PROGMEM = { 0, 240, 0 };
or
const hsv_color another_pallete_name[6] PROGMEM = { 0, 240, 0, 240, 0, 240, };
so CURRENT_PALLETE_WIDTH must be equal to number in [ ] brackets and count of values in { } brackets.
Instead of this set #define LED_COUNT to number of leds on your strip(in led_strip_apa102.h file). And don’t forget change #define LED_STRIP_BRIGHTNESS to 31 in the same file.
That’s interesting idea, man, I think it’s possible, but only for sensored motors
Do you have single motor board?
Also, are you using old firmware on your VESC?
I’m asking, because I tried to use HM-10 bluetooth module(with many apps at google play) and can’t get any data back, because of outdated protocol I think…
p.s. Could you, please, record a video? I have too many snow on the streets in my country now, so I can’t get joy of this.
Yeah, i get around. Problem is the CNC is stuck at work and i have a few hours at night to kill when I’m home. i got the G-code sorted for your cuts, but had to tweak some operations for the trucks mount. Geometry is unchanged, but i need to pocket a large area to prevent a rouge piece from coming free and breaking the bit which has happened before. I’m going in a few hours early tomorrow to try and bang out your parts.
Got it up and running on a couple Arduinos, it’s rather sweet. A thought, would it be possible intercept brake signal(from ppm maybe) and flash red
Will try to grab a video over the weekend
Btw, I’m using the 144led/m strip
I already have a script running that reads a button press on channel 3. Hoping to use a button press to turn the lights on and off as I don’t want them on during the day.
I bet we could attach channel 2 to to INT1 and get throttle position, but that would eat up all the hardware interrupts and I’m thinking that reading hall sensors is the way to go to get around UART.
I was actually just thinking, why not use ppm for everything? And/or why not put a sensor on the Arduino to sense the road moving by or motor/wheel spin? Can be vesc/ESC independent then
Essentially yes. We want to see what the motor or wheels are doing so that the lights are synched to the actual motion of the board. Polling the VESC via UART gives that, but there are other ways of getting that info.
I think that reading a hall sensor is most likely the easiest way as the motors have the hardware built-in and the VESC is simply reading the values. If we can sniff a single hall line we should be able to determine the RPM of the motor without interfering with FOC.
I’m thinking of making a PCB to knit all these ideas together for testing.
Wouldn’t reading the ppm be kind of easier. Just use a y servo cable to split the signal to vesc and arduino. Maybe drop an optocoupler before getting to the arduino to be safe. Arduino already has libraries to read the servo signal
That’s what I was planning on doing on the future at least
The only thing with ppm to take into consideration I think are the calibration values used by the vesc, there should be a way to input them , min, max, deadband