Moonbots Contest Winners by Xander 1 person liked this The winners for the Moonbots Contest have been announced! 1. Landroids 2. The Shadowed Craters 3. Moonwalk Congratulations to all teams who took part. All teams got a special recognition award for their efforts, some of which are very funny! Anyway, be sure to check out the teams‘ web sites for more information on what they did and how they did it. Add starLikeShareShare with noteEmailEdit tags: Lego and Robotics Aug 3, 2010 2:23 PM NXT-G Blocks For HiTechnic SMUX Are Here! by Xander 3 people liked this At last, the long anticipated NXT-G blocks for the HiTechnic Sensor MUX have arrived. Gus from HiTechnic has written a nice in-depth article about them on the HiTechnic blog which you can find here: [LINK]. It looks like using them is not a whole lot different from using them without the SMUX. Hurray for transparency. Anyway, hurry on down to the HiTechnic website and start downloading the new blocks right here: [LINK] or here [LINK]. Add starLikeShareShare with noteEmailEdit tags: Lego and Robotics Jul 30, 2010 11:14 AM Hispabrick Magazine 008 is out! by Xander Hispabrick Magazine 008 is out now! The Mindstorms NXT is featured quite a bit in this issue. Some of the highlights: Article about what the Mindstorms Community Partner programme (MCP) is all about; Interviews with some of the people in the MCP programme; A great tutorial on PID and how to apply that to line following; Actuators for the NXT (motors, things that move). Other highlights include: Another installment in the LDraw tutorial; How to build trees (these look awesome); A great article about the classic Super Car 8860; And much, much more! Go download your copy today here: [LINK]. Add starLikeShareShare with noteEmailEdit tags: Lego and Robotics Jul 23, 2010 2:06 AM Holit Data Systems News by Xander 1 person liked this The Ukrainian company Holit Data Systems, makers of the 3 port NXT motor MUX, asked me to let people know that they‘ve changed their domain name at the request of TLG. You can now reach their website at edu.holit.ua. They‘re busy working getting PayPal payments sorted out. It should all be up and running by next month (August 2010). You‘ll be able to get your hands on one of these without any trouble, no matter where in the world you are. I will keep you posted of any updates. Until PayPal is fully implemented, you can use the LiqPay system which is available to registered users atedu.holit.ua. Add starLikeShareShare with noteEmailEdit tags: Lego and Robotics Jun 12, 2010 2:07 AM Introducing The HTWay by Xander 3 people liked this If you want to build a balancing robot, there is no shortage of options to chose from. There‘s the original LegWay, NXTWay, SegWay with Rider and more recently theAnyWay. If you thought that wasn‘t enough, Gus from HiTechnic has made another, called the HTWay. The HTWay is a remotely controllable SegWay robot. It uses the HiTechnic IR Receiver to allow you to steer it any which way you‘d like using a Power Functions remote control and aHT Gyro to figure out which way it‘s falling. Gus has written up a nice article that goes a little bit into the theory behind the act of balancing with some accompanying NXC code. It‘s well worth the read if you‘re curious about how this stuff actually works. Don‘t worry, if you‘re only interested in building a cool looking robot, all the things you need and a nice video to watch are right at the top of the article, (you‘ll be missing out on some great stuff, though). Go check out it out: [LINK] Add starLikeShareShare with noteEmailEdit tags: Lego and Robotics Jun 3, 2010 5:24 PM Your chance to win a dFlex! by Xander 1 person liked this Dexter Industries are giving you the chance to win one of their newly launched dFlex sensor. There are no less than two ways to win one. Click on the link to find out how you can become one of the lucky winners! Add starLikeShareShare with noteEmailEdit tags: Lego and Robotics May 20, 2010 3:24 AM Book recommendation by claude 1 person liked this Add starLikeShareShare with noteEmailEdit tags: Lego and Robotics May 2, 2010 7:53 AM Dexter Industries – DI Thermal Series Sensor Roundup by dave 1 person liked this Add starLikeShareShare with noteEmailEdit tags: Lego and Robotics May 2, 2010 12:07 AM Debugging NXT-Programs by Linus Atorf 3 people liked this Sooner or later all users writing programs to be executed on the NXT brick find themselves in the following situation: Your program compiles fine, is transferred to the NXT, it starts running — but it doesn‘t do what you want it to! Sometimes the mistake you made is obvious, but often it‘s hard to spot the flaw. Well, now it‘s time for debugging: the art of finding what went wrong, and especially where. Usually during debugging, you begin to understand how your program really works, and that is what helps you fix the problem. In this post, I‘d like to give some general ideas and examples for debugging NXT programs. Independent from the language you use (NXT-G, NXC, LeJOS or whatever), you have these options to get information from a running program back to you, the debugger: The LCD display. This is obviously your first line of attack. Use the NXT‘s display to show contents of variables, status messages, checkpoints, or anything you need. Often printing text is enough, but if you have more complex things or contents with greater volume, consider displaying graphics (pixels, graphs, symbols, etc.). The speaker. Don‘t underestimate the NXT‘s capability to play sounds or tones. I call this ―acoustic debugging‖. Make the NXT play signal tones or sound files when certain conditions are met, procedures are executed or a special sensor value is detected. Lights. Yes, that‘s right. If you want to monitor a boolean value, maybe whether a certain task is running, you can use lights to show this information. There‘s the red LED light of the classic NXT light sensor, the old LEGO lamps for motor ports (e.g. from the NXT Education Kit), or of course the LEDs of the new NXT 2.0 color sensor. Motors. If you have no space left on the display and a free motor port, why not use a motor to help you visualize a variable? You can set the motor‘s power to the variable if it‘s confined to a range of -100 to 100. Some of the TryMe programs utilize this method (not for debugging purpose though). Files. You can start generating log-files for later analysis. While this is a bit more effort initially to get yourself some helper-functions, you can re-use these routines later on in your other projects. This can be very powerful as you can include valuable information like timestamps or the calling procedure. You are however limited in available file size, and writing data to flash can sometimes take a fairly long time. A computer. Once you have your PC connected to the NXT via Bluetooth or USB, you can retrieve valuable information from the brick. There are many methods of different complexity. BricxCC has a nice ―Watching the brick‖ feature, there is an NXT debug monitor which can receive string messages from your programs via mailbox queues, or you can play around with direct commands yourself. The main reason you should think of other ways than the display during debugging: There is limited space on the LCD, and there can be problems with updating speed. It can either influence your programs performance (and certain time critical bugs might magically disappear — a Heisenbug) or your eyes aren‘t fast enough to identify a flashy change. While it‘s easy to overlook a certain value / text for a split of a second, you‘ll usually notice a beep! Apart from that: If your program crashes, text on the LCD display is lost, while messages stored in logfiles or sent to a computer will still be readable. Having said all this, two things are important: Most of the time, you don‘t need all the different ways at once. And it‘s about the right combination of methods, which depend on your actual problem. If you‘re interested in more specific details and some examples for NXC, read on. In the remaing article I‘ll focus on text-based languages and use NXC for the examples. Handling debug statements. Most of the time you have to manually insert debug statements into your program code. Unfortunately, those statements don‘t do anything ―useful‖ apart from helping you to debug, so those commands are often considered annoying. It‘s common practice to start with inserting simple TextOutcommands where needed, and commenting them out later on once everything works. The more statements you‘ve got, the more annoying it gets to enable them once a new bug occurs, and to disable them again eventually. I suggest wrapping your debug code in between compiler directives, i.e. #define DEBUG_LCD #ifdef DEBUG_LCD TextOut(...); #endif This makes frequent debugging very easy: Simply comment out the statement where DEBUG_LCD is defined at the top of your progam, and debug mode is turned off. You can even have multiple define- ‖switches‖ for various debug options, like DEBUG_LCD, DEBUG_ACOUSTIC, DEBUG_LIGHTS and so on.