Motivation: So I have finally gotten the Arduino to talk to the Orion and the Raspberry Pi. For a long time I was banging my head against a poor documentation issue. The Roboclaw examples all show a setup that only sends two parameters when configuring the comm to the controller. However an error throws when you match the example saying it expects 4 parameters. I couldn't figure out what the additional parameters were being used for going through the .h file so I tossed in a couple of values. Turns out the 3rd parameters was the timeout and setting it to 0 means the damn thing never has a chance to listen to any commands. It also looks like if you use the RoboClaw setup it only uses the UART Tx Rx pins (0 and 1) on the Arduino. Fun times. Right now I have a bastardized solution where the USB serial from the Pi and the RoboClaw comm is happening on these pins. This means I can sit on the terminal window (or serial monitor in the Arduino IDE) on the Pi and send commands to turn the treads. As I am connecting to the Pi via a VNC remote desktop session from my Mac this represents a remote control solution via wireless. Eventually I will probably ditch the VNC portion and build a mac (or possibly iPad) application that receives telemetry rather than using a full on desktop session.
I also have the camera streaming data directly to the mac via netcat that I finally got working (Thanks to This example). Back to motion. I built in a function that takes a power input and then steps to it based on an interval (currently 100 milliseconds) This makes for much smoother speed transitions. If the power number is higher than current it ramps up and down if it is lower. This is also setup doing a clock watch rather than delay so it does not interfere with doing other tasks. Right now I only have it doing forward so I still need to build in similar functions for reverse and the turns. If you are interested in doing the clock watch solution as opposed to using Delay then check out the Arduino multitasking lesson on adafruit.com. At heart it is just watching the return value from millis() and setting up a couple of variables to watch the gap since the last time you checked. When the delta is greater than your desired interval, do something. Pretty easy to do and I wish most of the examples out there for arduino used this methodology rather than the rampant delay usage you see out there. The end of that lesson also starts you down the path of classes which is also a good thing to learn here. It isn't that the Arduino is multi tasking, it is just that it can run through a LOT of instructions if you let it. 16Mhz is FAST. Each clock cycle is 1/16,000,000ths of a second. A 1000ms delay wastes 16,000,000 clock cycles that you could be doing something useful.
Anyway, If you saw my Facebook post (ITS ALIVE) you may have noticed the tracks were not in sync. Out of a valid range of 1-127 it was taking till 35 to get both treads moving, one started around 30. I had to take them apart and figured out one of the bogies was pretty gummed up from my RC track initial run. I ended up using some moly dry lube that I have for my road bike to lube up all the bogies, drive wheel and gearboxes. The result was that I can now get consistent tread rotation at around 12 and they now seem in sync.
In addition to motivation I also finally got my pan/tilt servos situated/calibrated to center and wrote a couple of routines for moving them through their respective 180 degree arcs of motion also from the serial connection from the pi. Next... need to figure out how to mount the camera, ping sensor and maybe the microphone as a pan/tiltable sensor head. The Arduino sketch is up to 10k of 32... well really 28k available (using a trinket from Adadfruit in the final build). Should be able to handle the rest of the movement and sensors in that.
Another bone head lesson (and why I am overloaded on serial comm via the 1,0 pins) was that BMSerial.h and softwareserial.h were conflicting.... because they do the same damn thing. If anyone else runs across this trying to setup a separate serial line than the one being used to communicate with the Orion Roboclaw motor controller then you just need to make a second serial setup with BMserial... the example is always myserial(tx,rx), just make myserial2(tx,rx) or whatever name you want to use. Or if you are using the roboclaw (tx,rx, timeout, ?) call you can do an independent BMserial creation, just don't use the 1,0 pins. Cleaning that up and implementing the multiple serial comm lines is probably the next thing on my to do list.
Power: I learned a lot about power on this thing recently... almost fried my UNO board in the process. I found a couple of projects online showing how to do a voltage divider circuit that let me monitor the cell voltages of the lipo battery I was using via the balancer connector. This way I could not just rely on the RoboClaw shutoff or a lipo monitor widget, I could actually send back the pack, and individual cell voltages via telemetry. Well this worked great for one lipo pack. I am planning to run this via two 2S 7.4 5000Mah packs wired in series (14-16v or so). So after I had it working for one pack I wrote the routines for monitoring two packs at once then wired (make that tried) the second pack in. Well I found out the hard way that when wiring the second ground from the balancer connection to the common ground I created a mismatched parallel configuration.... *sparks, pop, SHIT*. Basically this created a wiring equivalent of division by zero where infinite current tries to flow between the two batteries (and through anything they are wired through) to get them to match. This also blew a hole in my theory that the balancer wiring was protected from full current from the batteries... um NOT. Anyway it seems I only did some minor damage to the UNO board. It now reads a bit high on the analog inputs but so far so good.
So after getting a clean pair of shorts (2S 30C Lipo's on a mission to discharge are no joke) and doing some belated googling I learned a couple of important things. The first was that bit about the stupidity of the wiring I tried. The second is that RC LiPo's are more dangerous than I was already aware as they typically lack any kind of built in protections for the lipo cells. This lets them pack the punch they do for those little remote controlled rockets. But it also puts them at a much higher risk of a failure scenario where fire or worse happens. In the voice of Tom Hanks in Polar Express " Lesson.... Learned". I hadn't been planning to try and do this. I ordered a couple of voltage monitors that beep when the cells get low as plan A. However the great deal I got meant waiting on an order and I got bored waiting for them to show up ad thus plan B was born. Anyway, I do still want to try and figure out how to do this. I am sure I could do it with a relay but that is probably overkill. For now I will probably be happy with just figuring out how to get the pack voltage from the two way packet mode from the Orion RoboClaw controller.
Brains: Move over Raspberry Pi B+ and make room for Raspberry Pi 2. Got one through Adafruit for I think 40ish something + shipping. It will be nice once the launch fuss settles down and you can reliably get these for the advertised 35$ price. I may load up everything on the B+ once I button it all up. But the Pi 2 has really been able to speed up all the Arduino coding I am doing on board the Pi. I think my end configuration will be using one of the HAT prototyping boards from Adafruit with a pro trinket mounted. haven't decided yet if the trinket will be the 3.3v (direct comm to Pi) or the 5v version (will require a logic level shifter which I already have).
No comments:
Post a Comment