When you’re stacking add-on boards, I assume there can be conflict between shared pins. I’ve looked at the Wifi board schematic and can see which pins are connected, but am not sure how they’re used in the software and if those pins are totally out of commission for any other use if that board is attached.
In particular, I want to use the three PWM pins (p7-p9), the ADC pin (p6) and ideally four digital pins (high/low, p2-p4) to set motor direction on H-bridge motor driver. Does using the WIfi board take those pins out of commission?
(apols if there’s a pin conflict matrix table somewhere that I’ve missed)
Looking more at this, it looks like the WiFi board does nuke most of those other pins. It would be a bummer if it actually does disable two of the three PWMs (P7 and P8) and the ADC (P6) in operation. Am I reading that right?
Got it. That (serial to an Arduino to control motors and servos) was the way I had it before, but I was seduced by the extra PWM pin in the M7 and thought I could now do it all with one board. So be it – back to Plan A while I wait for the next board. If I have to have a second board, I’d rather have video over Wifi with the official board than just basic text debugging with a serial radio.
(I think this may explain why I was getting funky PWM before with the Wifi board on. Might be worth noting this conflict in the Wifi board listing/notes)
To send a compressed image. The “Open Terminal” window will automatically decode and display the image.
…
What compressed_for_ide() does is to send the binary data in 6-bit chunks. This makes the data to send larger but maps everything into a safe non-display character area 128-191. This allows for data transport over serial without the possibility of data being confused for printable characters.
If you were to just try to send JPEG compressed data otherwise it would work out horribly. The state machine in OpenMV IDE for parsing the data is robust so images can be but off mid stream and they won’t break anything. You should literally be able to connect to a camera streaming image data at any point in time and everything should just work. No syncing required.
…
Finally, run your serial link faster than 1 Megabaud. Images are large… firmware.zip (756 KB)
Sweet! I’ve got to spin a custom shield for the cam one way or another to do both wifi and robot control. Given what you’ve now done, which of these two makes more sense?
Custom Arduino shield that communicates with the OpenMV via UART 3 and adds a bunch of I/O (downside: need to program the Arduino as well as the OpenMV)
Custom WIfi shield based on something like the ESP286 that just uses UART 1 and doesn’t block all the other pins like the official shield (downside: can’t control web server natively with OpenMV)
I’d use some serial to wireless solution that has a high baud rate. Like, you’ll want to drive the uart on the OpenMV Cam at 2-3 megabuad. So, maybe the EPS32 or a bluetooth wireless chip.
Edit:
Upon examination on the market for high speed wireless stuff everything is slow except our wireless shield we already sell…
It looks like the zigbee wifi module using the AT command set is the best serial wifi solution. But, you’d have to spend some effort setting up the wifi module then.
…
Yeah, option 1 basically. I’d just buy a motor controller board you can talk serial to to drive the motors. This way you don’t have to write any of that software. Then use the WiFi shield for high speed communication so you can stream images. Using a motor controller board makes sense too given the OpenMV Cam might not be driving the I/O perfectly.
Get a motor controller that talks serial… or i2c if you can’t find one that does serial.
The tricky bit will be how to handle the 3.3v vs 5v issue between the Cam and the Arduino. The Arduino Mini comes in a 3.3v variant, which is probably the way to go, but I’m slightly worried about plugging 5v ESCs/BECs into that servo rail to power the servos. Alternatively, I can use the 5v Arduino Mini, which is very happy with 5v servos, but then I’ve got 3.3v Arduino serial logic talking to 5v serial logic on the Cam, which is a probably no-no.
On balance, I’m guessing the 3.3v Arduino is the better of the two options. What do you think?
You probably want to power the servos and ESCs from the VIN pin, and not from the 3.3V pin on the OpenMV anyways, and you can have 5V there. I’m doing a similar thing in my hexapod robot for controlling the servos – I’m using a 3.3V Pro Mini, which I power through the RAW pin with 5V, together with the OpenMV and the servos. The servos don’t mind getting 3.3V control signal.
If you try to power the servos from the 3.3V regulator on the OpenMV or the Pro Mini, you are going to burn those regulators – they can’t handle more than maybe 200mA.
Nice looking board! The reason I’m using an Arduino is that I’m also using the OpenMV Wifi board, which conflicts with almost all the pins but UART3, so I only output serial. Also I need to have some ADCs in for sensor reading. And I only need 2-3 servos.
I’m guessing that your board isn’t designed to work alongside the Wifi board?
As you suggested, I’ve tweaked the design to power the PWM rail from the shared VIN/Raw of both OpenMV and the Arduino, rather than VCC, to avoid stressing the power regulators.
I’m confused at the pinout of the shield. It looks like you’re connecting to pins used by the SPI bus for data transfer. Please double check the pin layout. http://docs.openmv.io/_images/pinout.png. It looks like you’re connecting to UART 1 which is in use by the SPI bus. You want UART 3.