The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
I have made references to my buggy/tank in the past, but never published anything - mostly its because I have not had anything resembling a complete project until now. (I find I need a few hours at a time to get any serious development done.)
Netduino:
I am using a Netduino Plus v1 (with all the original non-updated firmware).
Chassis:
The chassis is a DFROBOT ROB0003 buggy which came with four geared DC motors, wheels, battery box, pre-drilled metal work, and all nuts bolts and stand offs. (Current 2013 price is around £35 on ebay). The wheels cope well with carpet and rugs, but the rear wheels can lose traction trying to get a grip when climbing onto a deep pile rug.
The kit of parts came with several extra bits for mounting sensors and I supplemented these with some hand cut and folded aluminium brackets. Once I had a good design for the front of the buggy, I marked out a complete mounting plate in 0.5mm aluminium. This is thin enough that you can cut it with tin snips, but thick enough that it can be drilled without tearing. Everything has been cut and drilled etc., with basic hand tools (no lathes or milling machines required).
Motor control and signal connection:
I have an Ardumoto shield to drive the motors on the buggy. I hav listed this in the Wiki before. This shield can't be connected directly to the Netduino due to the PWM inputs being on the pins that the Netduino does not support as PWM. (I have not checked if the V2 now supports this shield).
I originally designed my "fixit" shield to connect the Netduino to this shield. The fixit shield has now grown with some SFH618-2 opto-isolators and a whole array of three pin connectors for sensors to be attached. In the end, I actually chose not to use it for its original purpose (directly joining incompatible shields), and instead placed the Ardumoto shield inside the chassis. If I had put the Ardumoto shield on top of the fixit shield, it made the assembly too high to fit under the top mounting plate of the buggy. The fixit shield just becoming a ready great way to break out the Netduino pins and add odd bits of extra circuitry.
The Buggy has four motors, whilst the Ardumoto shield only has two channels, so I am driving two motors on each channel.
The opto-isolators on the PWM are not driven ON when the Netduino resets or powers up, so the buggy does not run across the floor during the 2 second boot sequence.
Outputs:
I have added an array of LEDs to help me debug the operation of the buggy. The LEDs tell me what the software has chosen to do: forward (slow/med/fast + veer left/right), back, turn (left/right). The LEDs are driven by a 74HC595 shift register from the SPI pins. I wrote my own SPI driver that allows me to stack multiple SPI devices into a chain, and the hardware of the LED board allows he signals to be routed out to another device in the chain.
Sensors:
I have bought six Sharp distance sensors - three 10cm digital (about £5 each) and three 10 to 80cm analogue (about £11 each). I use one analogue sensor to see what is ahead, and two of them to see what is to either side. Since the buggy is fairly wide, the front sensor will miss obstacles that the wheels can hit. To help prevent these collisions, I tried to use the digital sensors, but they were not very reliable with chair legs. Hence I made my own bumper with two micro switches. This arrangement works fairly well, but there are always obstacles that beat it: glancing objects are not detected, objects that are just above the centre of the wheel, and chair legs that slope towards the buggy.
I now use two of the digital sensors to spot objects when reversing. These are needed less often and so the reliability is less of a problem.
Software:
I found that I could easily write drivers for each of the sensors and actuators, but it was quite hard to come up with a simple program to test them all out together in a convincing buggy program. After some experimentation I have come up with the following which works quite well, but obviously lacks any intelligence.
With the front sensor, I have setup a virtual bumper at about 30cm in front. If an object is too close, the buggy will back off. If an object is further away than the bumper, the buggy will drive forward (the further away the faster it goes) until the object reaches the virtual bumper, then the buggy turns to he left or right.
The side sensors are used to make the buggy veer away from objects to the side - the idea was the buggy would eventually drive parallel to a wall. (Its not quite correct yet).
I made the bumper sensors event driven so that they latch ON as soon as an object strikes them, this prevents obstacles being missed when just polling inputs. The forward speed is filtered so that the buggy builds up speed slowly. This change was made after I found the buggy would ram a chair, move back and then ram it again at full speed.
Current control logic:
if (front wheel bump sensor activated){ // Collision If (clear behind) { reverse away from bump (if both active then back straight, other wise turn away from obstacle) } else { turn on spot (use side ranges to turn away from near objects to left or right) }} else if (very close to object ahead){ // Object too close in front if (clear behind) { reverse away from object } else { turn on spot (use side ranges to turn away from near objects) }}else if (near object ahead "virtual bumper"){ // Reached the edge of the room, turn away turn on spot (use side ranges to turn away from near objects)}else{ // Keep going ahead, but watch for walls to the side go forward use side sensors to gently steer away from side objects speed dependant on range to object ahead limit acceleration }
Future work:
I would like to add a compass module so the buggy can have an objective to move in a particular direction.
I got a surprise Christmas present of a Raspberry Pi, this has a Wifi dongle. I am currently thinking about using it to be the brains of the buggy (generate a map of the room, etc.) and be the link to the outside world. I will probably use the UART or UDP over Ethernet. (UDP will not cost me any GPIOs - I am running out of these!)
Conclusions:
If you want to make a buggy - I recommend the DFROBOT ROB0003 chassis. Thanks go to a good friend who donated a spare one!
The analogue Sharp sensors have worked well, but the digital ones were not very good when used for collision detection.
Its really hard to make a bumper that works with all obstacles!
Coming up with intelligent behaviour is tricky.
Paul
(Please PM me with any spelling/grammar mistakes - post is too big to proof read in one go)
Sorry Chris, I've only got the two videos I linked at the top of the post
The second one shows it negotiating a room full of obstacles.
Paul
EDIT:3 mins of video took 70 mins to upload to youtube - groan.
Doh! I jumped right into the text Thanks for pointing those out!
Watching now...
Chris
This is fantastic Paul! I've fancied making a similar robot for a long time now. It was actually the primary reason for me getting into this hobby, however for some reason it's been placed on the back burner. I wish there were more projects in our community showcasing robotics, and something I hope changes in the future as more and more people jump into the wonderful world of Netduino. I have most of what I need aside from some good distance sensors. Perhaps I should look into getting some soon.
Please post more updates as your project grows as I'll be following it intently. I also have a Raspberry Pi and would be interested to see how you integrate the two.
One of the first things I did with the Pi was to setup SSH. This has allowed me to remotly log in to the Pi from a windows laptop. I can bring up a text only terminal, a gui terminal or a file manager thingy that lets me drag, drop and edit files on the Pi.
So far so good. The Pi now lives in a cupboard with just a power supply and wifi dongle.
Next I wrote a pair of simple Python scripts that send or receive UDP packets. These work on the Pi.
Next I tried to do the same on a Netduino. I wanted to use UDP rather than tcp/ip since I thought it would be easier not to have a connection; but it is really hard to find simple to follow examples of UDP ethernet comms. Trying to work out which commands I need and which are for tcp/ip is difficult. At about this time I got two 2nd hand Netduino plus revB's. So the obvious thing was to plug them together with an ethernet cable and have one send button press messages to the other.
A lot easier said than done. I have been defeated by the need to have the ethernet live when powering up bug in the v4.1 firmware. So I am now upgrading to v4.2.2 - glad to see that there is lots of help for this on the forum.
This problem caused quite a lot of confusion when I tried to decide if I needed an Ethernet cross over cable or a normal straight through one. I think that the Netduino auto-detects, but Iam not 100% sure yet.
In parallel wih this though, I have discovered a fatal flaw in my design. The idea was that the Pi would use both Wifi (to the world) and Ethernet (to the Netduino). Now I find that as soon as I plug in the Pi Ethernet cable, the SSH (over wifi) stops working. After a search on google I find that other users have also found that you can only have one - not both:
All you needs it a WiFi access point (that has some spare ethernet ports) or an ethernet switch. Each device connects to your common switch via cable or WiFi. As long as each device has a discreet MAC and IP address, each Netduino and rPi can 'see' and communicate with each other. I assume the rPi is not able to handle having Ethernet port and Wifi USB dongle at the same time.
As for UDP, I choose to use it specifically because it >was< so simple. Using a N+ at 4.2, (with fixed IP address and MAC set) it was easy to communicate via UDP with my PC on the same network. I also have a rPi that I hope to use as a 'controller' using a visual studio application running under Mono (right now Mono only runs under soft float Debian, not Raspbian).
My strategy for using UDP was to use 2 queue's, 2 threads and 2 UDP ports, one for sending, one for receiving.
Private Sub sendUDP() 'looks to contents of dataQ and cmdQ and sends. Priority given to cmdQ items Try sendQ.commands.Clear() sendQ.sensorData.Clear() Dim ep As New IPEndPoint(IPAddress.Parse("192.168.0.9"), 11000) Dim xmitUDP As New Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp) Do SyncLock (sendQ) If sendQ.commands.Count > 0 Then xmitUDP.SendTo(Encoding.UTF8.GetBytes(sendQ.commands.Dequeue.ToString), ep) ElseIf sendQ.sensorData.Count > 0 Then xmitUDP.SendTo(Encoding.UTF8.GetBytes(sendQ.sensorData.Dequeue.ToString), ep) End If 'keep queues to 15/5 If sendQ.commands.Count > 15 Then sendQ.commands.Dequeue() End If If sendQ.sensorData.Count > 5 Then sendQ.sensorData.Dequeue() End If End SyncLock Thread.Sleep(500) Loop Catch ex As Exception rebootNetduino(True, False) End Try End Sub
So in the above example I de-queue and send a string of text that is either parsed out as sensor data or commands.
To Receive:
Private Sub RECVctrl() Try Dim anyEP As New IPEndPoint(IPAddress.Any, 11001) Dim recvUDP As New Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp) Dim recvbuf() As Byte = New [Byte](200) {} 'was 255 Dim sender As New IPEndPoint(IPAddress.Any, 0) Dim senderRemote As EndPoint = CType(sender, EndPoint) recvUDP.Bind(anyEP) Do recvUDP.ReceiveFrom(recvbuf, senderRemote) runCommand(New String(Encoding.UTF8.GetChars(recvbuf, 0, recvbuf.Length))) Array.Clear(recvbuf, 0, 200) Loop Catch ex As Exception sendMSG(MC.ERR, MP.Sub_RECVctrl, MT.REBOOT, ex.Message.ToString) Thread.Sleep(1000) rebootNetduino(True, True) End TryEnd Sub
In the above receive example, I have a 200 byte array as a receive buffer and the received 'commands' are parsed and acted on in another Sub (runCommand).
So in my configuration, I am sending text strings via UDP to IP 192.168.0.9 on port 11000 and I am listening for text string sent from any IP on port 11001. This is done this way as the N+ is sending sensor data to my PC (or rPi eventually when they get HF Mono sorted) and can be commanded from any other device on the same 192.168.0.x network by listening on port 11001. The N+ is used to drive a DHW circulating pump in my house and collect temp readings and pump status.
Now I am really confused; I don't know whether to call you "emg" or "HTH"
EDIT: HTH = Hope This Helps?
I agree about using a Wifi access point, I could do it that way, but I have a Raspberry Pi with a Wifi dongle and an Ethernet port and I assumed that would save me any extra hardware. Alas the WIfi turns off when the Ethernet is plugged in.
Also agree about static IP addresses; I thought that would make everything more simple - but it means remembering which Netduino has which IP address!
Two good reasons (in my mind) for using a wired Ethernet connection between Netduino and Pi (with or without an Ethernet Switch/access point):
- I will be able to easily test the UDP software against a PC by writing emulations of the Pi or Netduino functions
- I don't need to use any more of my GPIO pins - I am running out of those!
I currently have a pair of programs, one that sends a UDP packet every 500ms (and toggles its LED each time so I know it is sending), and one that receives a UDP packet and toggles its LED if it gets one. I will not be sure I have is correct until I get my Netduinos updated and talking to each other (chicken and egg situation - which came first "the debugged software" or "the perfect design"?). What I should do is write the PC app to test against!
This Visual Basic stuff looks a bit different to C# I wrote.
Reading your basic version, the first thing that confuses me is [font="'courier new', courier, monospace;"]sendQ[/font], is that a variable? Where did it come from?
I presume SyncLock prevents multiple threads accessing sendQ concurrently, but I don't see any other code using sendQ.
I guess there is some more program missing...
I see you are using a "receive from" command, I chose to use just "receive" thinking it would avoid me having to specify the remote address. Was that a mistake?
Yes, it looks like you are correct with the rPi running multiple network interfaces. I don't know enough about the rPi to say if the limitation is specific to the rPi hardware or the OS just needs tweaking. I've plugged nothing else except a keyboard/mouse during initial setup (now just use puTTY and VNC) into mine.
My day job is servers, networks, routers, etc I'm used to fixed IP addressing so it's no big deal for me. As for WiFi, I prefer cabled Ethernet over WiFi as it will always be faster and more reliable (less to break/configure), assuming it is convenient to run a cable.
One point though, you mentioned wanting to direct cable devices without using a switch. This requires a crossover cable or NIC's that Auto-MDIX. I would stay away from this configuration and always use an Ethernet switch (4-8 port white box brand 10/100Mbit switch is £10-15). Your home broadband router may already have a few spare open ports. Ethernet switches provide some buffering and seem to work better vs direct cable with modern NIC's. If you have a BT Home hub (or similar WiFi ADSL router that has a few Ethernet ports) you can still run the rPi via WiFi and cable the N+ devices to the same network. You should probably set a DHCP range exclusion so the router DHCP does not hand out an IP you have configured with a fixed IP address. Let me know if you have specific questions on networking and I can be of help.
For testing, I found it very easy to test on my PC to either itself (running 2 copies of the 'client' application) or using the client to talk to the N+. I can test with 2 clients on the same PC as I am using 2 separate ports to send/receive.
As for my examples, sorry it was confusing - I tried to strip out all the non-essential code not directly related to UDP. SendQ is a simple class:
Public Class sendingQ Public sensorData As New Queue Public commands As New QueueEnd Class
I stripped out all of the rest of the code that writes to SendQ - sensor threads, a command thread, etc so it was not shown. SyncLock (sendQ) locks the object while data is being de-queued. BTW, you can run the code though a C#/VB converter and I assume it will be OK.
It has been a while since I wrote the code, but I do remember having issues with Receive vs ReceiveFrom. The MSDN help states that ReceiveFrom is intended for connectionless protocols (UDP) and in the end found it easier to work with. I used IPEndPoint(IPAddress.Any, 0) to specify any sender.
Like I mentioned above, you can write and test all of this on your PC, pointing back to itself. I remember writing a small testing application with 2 threads when developing the example code and just copied/pasted into my N+ project when done. Run the above code though a VB/C# converter and adjust port, IP address to suit your local PC and queue/dequeue your text to each thread and you should be GTG.
Edit Add: If testing on your PC and if it has a fairly modern OS (Windows 7/8, Server 2008) you will probably need to open the specific ports you using on your firewall or they will get blocked!
I'm GTS (getting there slowly).
The reason I want to steer away from an extra switch/router is that the buggy is quite small and I can't fit much more on to it.
Especially don't have more room for batteries!
At the moment I'm still between firmwares: v4.2 installed on PC, Netduinos TBD.
I agree on your suggestions for testing. Using UDP makes it easy to drop in test code to check behaviour.
Ahh, I see. I did not read your previous posts up-thread about the vehicle.You are short of GPIO on the N+, that's why you want to try Ethernet between the rPi and N+? That really is a shame about the rPi unable to use 2 network interfaces at the same time - this would have been perfect.
Paul, if you get time, some more code examples or sharing the whole project for your buggy would be much appreciated! I am already underway making something similar even with the sharp IR sensors. For the buggy platform I went to Wal-Mart and threw 20 bucks into a cheap RC truck with some nice big wheels. I have already modified the steering with a servo and have the H-bridge board to run the rear wheels. I just need to print some brackets to mount the IR sensors and start coding!
I have been talking to fileark offline.
He now has a copy of my v4.1 code.
The code has classes for the drives - I am using skid steering.
However, I control the steering using an interface that lets the program specify speed and direction - so it should be possible to drop in a new class that controls a servo for steering and single pwm for speed.
Paul
Hi Paul, nice work!
As for me, I've still not really taken the leap over to things that move besides for servos and stepper motors.
My dad recently got himself a robo mower and that came to mind when I saw your buggy. Is that perhaps what you had in mind or is it just for plain old fun?
Maybe you saw my CD player and having 12+ CD/DVD drives on my desk, I'm thinking of maybe making a x/y plotter with the laser sleighs from a couple. Those are actually 4 wire stepper motors in case you didn't know - in fact, a CD drive contains no less than 3 motors of which one is a stepper driving the laser sleigh using a worm screw to move along the guides in a very precise manner.
Anyway, good luck with the buggy!
Finally I have a working system (apart from a few battery issues).
The Netduino Plus (v1) is connected to a Raspberry Pi using a wired ethernet connection.
The Pi is conneted to my home Wifi using a USB dongle.
I have written some classes in c# that allow me to send status to UDP (for testing I can also send it to debug-print or my SPI LED array).
I have also written a UDP receive class (currently very very simple) that has a thread which listens for UDP commands (stop and start).
On the Pi, I have a Python program configured to run a start up which listens for status from the Netduino over UDP and records the current buggy status (Forward/reverse/turn etc).
The Python script also accepts a TCP connection that can request the current status - the status is returned to the caller as text and an image filename in html.
The TCP message can also send a command (currently just start/stop/shutdown), all three are passed on to the Netduino, but the shutdown command actually makes the Pi turn off - this is really handy as the Pi can't just be shut down by pulling power (rather - it should not).
The Pi has been set up with a web server and PHP (a language that runs on the server). It has two simple web pages and some image files. The first web page uses a tiny bit of PHP to send a TCP request to the Python and it gets back some text and HTML that causes the current status image to be shown.
The first page also has some buttons that launch the second page, whose PHP sends a different TCP message to trigger the sart/stop/shutdown actions.
It has taken a really long time to get all this working, so what I want to do next is cut it all right down to a tutorial/template that can be re-used for other applications.
A video of the working demo would be surely appreciated, as many previous media were as well.
The connection system sounds a bit cumbersome, but -yes, it's TCP/IP- should work fine in any context.
As far you write in the previous post, the hardest point was the PI. I don't know anything about it, so I'd be happy to read how to setup one of these boards. Although, I'd rather love to test a BeagleBoard running the regular .Net (Mono).
Congrats again, and please go further.
Cheers
Biggest fault of Netduino? It runs by electricity.
DFROBOT_NETDUINO_BUGGY.jpg 41.7KB
41 downloads
Thanks for pointing those out!
Watching now...
Chris
