Hi John, You risk a short out if they touch which could potentially damage one or both the boards. I got mine low enough so there was a half to one mm between them and was going to tape some hard plastic insulation between them. For the moment, I'm using a PI Zero, (for lower power), and do not have the issue. Good Luck D L

Hi John The RP3 does hit the Nyboard because the pins are too high. Here is a discussion and fix. https://www.petoi.com/forum/clinic/placement-of-raspberry-pi-3b The motor wiring was a bit confusing, so I wrote my own. Here is the description. Consider the table to be looking from top, left and right to the Nyboard, with Nybble facing as per the picture. Good luck/ D L

Hi Rongzhong, I am doing a test and have commented out the #define GYRO in OpenCat.h, disabling the use of the MPU6050. So far all abnormal jerking is gone, include quite aggressive movements in some Postures. In many ways this is a superior execution for the movements I need Nybble to be able to complete (I won't be asking the robot to walk up stairs of any significant incline movements in the short term). Two questions. - Now that the MPU is disabled, the walking, trot and crawl gaits are quite fast. Is there a location to define these to slow down. - Is there any plan to re-write the GYRO routines to address the post transform movement jerkiness. Overall I like your work. Well done. I do recommend though, as a general comment, if you are considering a faster CPU, then a re-write/clean-up of the code is possibly in order, especially to remove compiler directives intermixed within the code lines. These, and the use of interrupt processing mixed in with the general procedural nature in the code, makes the code difficult to read and troubleshoot. Once again, well done so far. I hope the project succeeds to your best wishes. Best regards D L

Hi Rongzhong, Thanks for that. Is this the code in Nybble.ino lines 725-741 that implements the +m in B => B + m. if (jointIdx < firstMotionJoint && motion.period > 1) { calibratedPWM(jointIdx, (jointIdx != 1 ? offsetLR : 0) //look left or right + 10 * sin(timer * (jointIdx + 2) * M_PI / motion.period) //look around # ifdef GYRO + (checkGyro ? adjust(jointIdx) : 0)# endif ); } else if (jointIdx >= firstMotionJoint) { int dutyIdx = timer * WALKING_DOF + jointIdx - firstMotionJoint; calibratedPWM(jointIdx, motion.dutyAngles[dutyIdx] # ifdef GYRO + adjust(jointIdx)# endif ); } jointIdx++; If it is, what happens if the line in red is removed? Could it be replaced with a series of steps calling calibratedPWM() in a loop? Best regards D L

Thanks guys, much appreciated.

Hi Steve, Can you please let me know the make/model LiPo are you using, and also where you got it from? Best regards D L

Hi Rongzhong, Leukipp, I written some basic automation into the Raspberry Pi and find I've run into a really basic problem. There is no feed back/error codes as to if a command has completed successfully. I know that the Nybble.ino Arduino code does not support them, but they will more than likely be necessary for any serious attempt at autonomous operation. I was thinking for Postures, the final joint indices could be verified they match to the posture joint definition and for Gaits, there could be some bounds check for the ongoing joint indices with the Gait joint definition. It would be better to do this in the Arduino and use the command set to read a true/false condition if the command was in spec. What do you think from the separate Arduino and API perspectives? Best regards D L

Out of pure interest I grabbed the standard Firmata sketch https://github.com/firmata/arduino/blob/master/examples/StandardFirmata/StandardFirmata.ino and compiled it to get an indication of how big it was. Sketch uses 12492 bytes (40%) of program storage space. Maximum is 30720 bytes. Global variables use 1053 bytes (51%) of dynamic memory, leaving 995 bytes for local variables. Maximum is 2048 bytes. My Nybble.ino (v0.2 plus the extra lines to implement voltage) uses the following: Sketch uses 30396 bytes (98%) of program storage space. Maximum is 30720 bytes. Global variables use 1195 bytes (58%) of dynamic memory, leaving 853 bytes for local variables. Maximum is 2048 bytes. Need a bigger boat! D L

Hi Leukipp, Great work on the API. I have extended the Flask code to include a route to read the battery voltage. It does need changes to Nybble.ino, app.py and bus.py, but neither are complex. Hopefully this will make it into the mainline code. The updates are at https://www.petoi.com/forum/hardware/reading-battery-and-rp-voltage-from-nybble-v0-2 Best regards D L

Hi Franke, I love your work. It's on my to-do list. I have implement Battery voltage detection. You can read how easy it was at https://www.petoi.com/forum/hardware/reading-battery-and-rp-voltage-from-nybble-v0-2. Using the RP Serial or Web API it will be easy to implement a low voltage subroutine to initiate the need to charge. For self-charging, I have considered the same problem. What charging mechanism were you considering?. I was thinking about a phone wireless charge element but will need to test it to see if it can provide enough power. Will need to get a camera and recognition going first so I can find the charge station (kitty bed). Keep up the good work. D L

Thanks Rongzhong, I set the low voltage 'meow' warning to 6.5v, (2 * 3.2v min Li Ion level) by changing the 300 to 450 I have also created a new command to read the voltage dirrectly from the Nybble_v0.2 board. in Nybble.ino at line561 after the case 'a': { PTLF("abort calibration"); for (byte i = 0; i < DOF; i++) { servoCalibs[i] = servoCalib( i); } break; } I inserted: case 'v': { float voltage = analogRead(BATT); Serial.println(voltage/1024 * 5 * 3); break; } Additionally, So I could get access to the voltage while Nybble is operating, I updated the Flask API code https://github.com/leukipp/OpenCatWeb with the two following updates: Update 1: in app.py after line 154, @app.route('/api/status/j/') def api_status_j(): return jsonify({'status': {'j': serial.write(SerialCommand('j'))}}) I inserted: @app.route('/api/status/v/') def api_status_v(): return jsonify({'status': {'v': serial.write(SerialCommand('v'))}}) Update 2: in bus.py after line 33, if '\t' in line: print(line) return line.split('\t') I inserted: if '.' in line: print(line) return line Works like a treat. Meows when the voltage is getting low, and I can use the web API to measure the voltage usage as Nybble bounds around. D L

Thanks for the suggestions. I ended up considering all options and finally used option B. Using a fine pair of long nose pliers, I carefully straightened each pin. Then I measured how low I could go against the SW3 jumper, and pin by pin bent each pins slowly down, ensuring for each pin the bend commenced at the same height. I saved about 5mm and now have about 1-2 mm gap. I did consider putting an insulated plastic strip between the Nybble_v0.2 and RP boards (just in case) but have not needed to do so. D L

Hi Rongzhong, What is the expected peak current draw with all servos operating? I'm currently using a set of Samsung 18650 25R with a spec of 20A output current and an output voltage spec as shown. For these batteries should I see an significant drop in voltage when servos are running. Best regards D L

I was wondering if there is any reason why the 14500 form factor is specified. In many batteries I have seen on the market I find that the cell capacity is limited to 800mA and in my case 2.3A (which is not enough for all motors, Ultrasonic sensor and RP, not to mention a future camera and IR light). I would be interested to know if the Li Ion 18650 can be used. Specifically, the Samsung 25R (model INR18650-25R) is a 2500mA battery with a maximum continuous drain current of 20A. From the specs it can provide 5A for 30 minutes (Using 97% available capacity to residual voltage of 3.3V) (http://dalincom.ru/datasheet/SAMSUNG%20INR18650-25R.pdf). Any comments or suggestions? Best regards D L

Hi Florian I had a similar feeling, but I was able to piece together how the Nyboard v0.2 is to be cabled (with Rongzhong's help). I put together a single page with the servo locations, the Nyboard v0.2 pin number to servo number wiring (top, left and right views) and a labeling system I used (plus picture of labels).

In Australia the hobbyist shop, Jaycar has these that appear to work. Battery https://www.jaycar.com.au/14500-rechargeable-li-ion-battery-800mah-3-7v-nipple/p/SB2300 Charger https://www.jaycar.com.au/dual-channel-li-ion-ni-mh-battery-charger/p/MB3635 Update: 14th July. I've been using these batteries for a few weeks now. It appears they can supply about 2.3A each and are suitable for setup, calibration, to drive all the motors and I'm certain additional software development. I have found that as soon as I connect the Ultrasonic sensor or a Raspberry PI, there is not sufficient current to drive the total load, and Nybble motors start to misbehave making any further use impossible. Charger works well Showing each cell voltage and charge rate individually.

Hi Rongzhong, Thank you for the feedback. Yes it made all the difference. All basic movements are now working, although somewhat jerky in the movements. I have the servo voltage set to 5.5V. Will I get a more smooth movement with a higher voltage. Best regards D L

Hi All Following on from the discussions above on the difference between servo usage in Nyboard_V02, I have re-connected all servos as recommended above. Updated WrtieInstincts.ino and entered ‘Y’ for all the prompts. I re-calibrated, save the calibration and verified it on a second run through. I uploaded Nybbe.ino. The initial load servo movements finished and Nybble meowed. -- All good!. As soon as I attempt any operation, I get unexpected results: unexpected - Half way though the operation KFR and KHL will rotate fully and lock up - Head Pad will spin through 180 degrees - other variations of unexpected servo movements. - Nybble becomes unresponsive I re-upload WrtieInstincts.ino and the calibration looks ok. Looking for the any suggestion that can point me where to look. Thanks and regards D L

Thank you Rongzhong, I uploaded WriteInstinct.ino, selected Y to all options resetting the Joint calibration, Updating Instincts and re-calibrating the MPU. I then entered c to enter callibrate mode. The nybble set the servo to calibrate position (and were out as expected). Then staring with the HEAD PAN connected to servo 0; I entered c0,10 to see where it moves to; to my surprise the FL Knee moved. It seems the servo mapping is different?. Any suggestions on what to do next? Best regards DL

I have further observations regarding this issue I hope someone may provide some further insight into. Like Pavel above I completed calibration using WriteInstict.ino but had NyBoard_V0_1 instead of NyBoard_V0_2 in Instinct.h. All calibrations appeared to be look correct in WriteInstinct.ino, but later I got the &#39;cry&#39; buzz when I loaded Nybble.ino. After realised the mistake, I set NyBoard_V0_2 in Instinct.h, re-complied and uploaded Nybble.ino but had significant issues from that point on. - All calibrations appeared to be out and looked like it needed a complete re-calibration - Using c was selecting the incorrect servos. Eg Knees were now 0,1,2 3, Shoulders 4,5,6,7 and the remainder were 12,13,14 instead of the mapping in the instruction manual. - m e.g. m0 10 cause many servos to operate and then tripped a servo overload One last comment is that as per the guide, I have set the servo voltage to 5.5V. Any thoughts on what is going on here would be most welcome. Should I reload WriteInstict.ino and re-calibrate using the altered servo numbers or is something else wrong here? Best regards DL PS I put togther my view of how the servos and joints were attached in the attached image.